Forem: Kevin Burns

The Large Language Centipede

Kevin Burns — Thu, 28 Aug 2025 15:10:09 +0000

First gather a corpus of text. Let's call it the entire public internet.

Next train a Large Language Model (LLM) against this corpus and you will get a system like Grok, Gemini or ChatGPT which approximates Artificial Intelligence (AI).

Now sell this LLM to people who use it to generate content they later post to the internet.

The moment you make available the first generation of your LLM, you will immediately begin developing the second generation of your LLM in order to remain competitive in the AI arms race.

Gather a new corpus of text. A fresh snapshot of the entire public internet.

Train your new LLM against this new corpus, knowing that it contains some non-zero percentage of LLM generated content produced by users of the first generation of your product.

Now sell v2 of your LLM to more people who use it to generate more content they later post to the internet.

You can see where this is going.

Each new generation of your LLM is trained on a higher percentage of LLM generated inputs as the last.

This leads to Macro self-training where large language models are inadvertently affecting the quality of successive generations by feeding their own outputs (and the outputs of other models) into the inputs of the newer generation of models.

However inaccurate LLMs are today, we should expect them to become more deranged and hallucinatory over time. Not less.

When developing the nuclear bomb, some scientists worried it might ignite the atmosphere and end the human race.

This concern did not stop them from detonating the most destructive device ever constructed.

If you think legitimate concerns regarding the safety of AI will be heeded, you don't understand the macroeconomics. These multi-billion dollar models are going to choke on their own excrement spraying trash across the entire internet and crash the global economy full speed into the brick wall that is The Ouroboros Problem.

Skipfilter

Kevin Burns — Sat, 26 Mar 2022 22:56:27 +0000

A skipfilter is a skip list of arbitrary elements that can be efficiently filtered using roaring bitmaps stored in an LRU cache.

https://github.com/kevburnsjr/skipfilter

We will use this data structure to make an open source pub/sub messaging system 20,000x more efficient.

Use Case

Mercure is a pub/sub message protocol for Server Sent Events.

Topics are identified by their URI
Subscriptions are expressed as URI Templates (topic selectors)

Problem

Each time a message is published to the hub, every topic selector in every subscription must be tested against every one of the message's topics. So if you have 5000 subscribers with 3 topic selectors and each message is published to 2 topics, that's 30,000 topic selector comparisons per message.

The Mercure Hub originally dealt with this issue using an in memory cache to eliminate duplicate regular expression evaluations.

Key (string): ${uri_template}-${topic_uri}
Value (boolean): regexp.Match(uri_template, topic_uri)

While this worked well initially to improve latency, it still required 30,000 hash table lookups per message which did not scale well to large numbers of subscribers.

[leak] High CPU usage with a lot of subscribers #558

divine posted on Sep 03, 2021

Hello,

This issue has been created to track down the problem that I'm having with Mercure:

Mercure uses almost %100 CPU, doesn't matter what specs you've.

The reason is probably a lot of subscribers and updates published to them:

# TYPE mercure_subscribers gauge
mercure_subscribers 4299
# HELP mercure_subscribers_total Total number of handled subscribers
# TYPE mercure_subscribers_total counter
mercure_subscribers_total 2.939146e+06
# HELP mercure_updates_total Total number of handled updates
# TYPE mercure_updates_total counter
mercure_updates_total 7.891176e+06

This is just for 2 days, this is a reduced amount, normally it's up to x4 of updates that are currently disabled.

Here is debug profile of CPU:

File: caddy
Type: cpu
Time: Aug 26, 2021 at 6:53am
Duration: 300.16s, Total samples = 461.92s (153.89%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 231.78s, 50.18% of 461.92s total
Dropped 1620 nodes (cum <= 2.31s)
Showing top 10 nodes out of 141
      flat  flat%   sum%        cum   cum%
    55.77s 12.07% 12.07%    191.39s 41.43%  runtime.selectgo
    41.19s  8.92% 20.99%     52.73s 11.42%  runtime.sellock
    24.36s  5.27% 26.26%     24.40s  5.28%  runtime.(*waitq).dequeue (inline)
    22.55s  4.88% 31.15%    114.28s 24.74%  github.com/dunglas/mercure.(*Subscriber).CanDispatch
    18.83s  4.08% 35.22%     18.83s  4.08%  go.uber.org/zap.(*Logger).check
    16.90s  3.66% 38.88%     17.25s  3.73%  runtime.unlock2
    14.31s  3.10% 41.98%     32.20s  6.97%  github.com/dunglas/mercure.canReceive
    13.21s  2.86% 44.84%     13.21s  2.86%  runtime.empty
    12.48s  2.70% 47.54%     44.65s  9.67%  runtime.schedule
    12.18s  2.64% 50.18%     12.64s  2.74%  runtime.gopark

pprof.caddy.samples.cpu.006.pb.gz

Here is the image of it:

The problematic lines are:

https://github.com/dunglas/mercure/blob/ca2df66f27356aa2511ef4f959fc4156a0f69a94/subscriber.go#L68-L102

At first, we thought the problem is with Zap(*Logger) check but PR https://github.com/dunglas/mercure/pull/554 should fix it.

Anyways, completely removing Zap logging, the situation didn't improve but instead showed more problems with runtime.selectgo

Here is debug profile of CPU:

File: caddy
Type: cpu
Time: Aug 31, 2021 at 12:27pm
Duration: 300.10s, Total samples = 568.67s (189.49%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 347.87s, 61.17% of 568.67s total
Dropped 1614 nodes (cum <= 2.84s)
Showing top 10 nodes out of 116
      flat  flat%   sum%        cum   cum%
    76.58s 13.47% 13.47%    263.92s 46.41%  runtime.selectgo
    50.10s  8.81% 22.28%     50.28s  8.84%  runtime.(*waitq).dequeue (inline)
    47.13s  8.29% 30.56%     59.44s 10.45%  runtime.sellock
    29.29s  5.15% 35.71%     29.29s  5.15%  memeqbody
    29.05s  5.11% 40.82%     86.37s 15.19%  github.com/dunglas/mercure.(*Subscriber).CanDispatch
    28.25s  4.97% 45.79%    166.05s 29.20%  github.com/dunglas/mercure.(*Subscriber).Dispatch
    25.76s  4.53% 50.32%     57.32s 10.08%  github.com/dunglas/mercure.canReceive
    25.14s  4.42% 54.74%     25.14s  4.42%  runtime.empty (inline)
    18.58s  3.27% 58.01%     19.21s  3.38%  runtime.gopark
    17.99s  3.16% 61.17%     17.99s  3.16%  runtime.(*gQueue).pop

Here is the image of it:

Sorry, I can't write a benchmark for it but ready to test what changes is needed.

Data posted to Mercure is always to different topics.

Posted to topics: /users/613193cee6be0e1016042334

Private: true

Data:

{
    "@context": "/contexts/User",
    "@id": "/users/613193cee6be0e1016042334",
    "@type": "User",
    "id": "613193cee6be0e1016042334",
    "quota": 40000,
    "used": 7186,
    "isDisabled": false,
    "isDeleted": false,
    "createdAt": "2021-09-03T05:17:34+02:00",
    "updatedAt": "2021-09-03T05:18:29+02:00"
}

Thanks!

View on GitHub

The O(n) growth in topic selector comparisons for each message meant that the computational complexity grows as a product of the number of subscribers and the volume of messages. Highly concurrent access to these caches caused a lot of lock contention which made the Go scheduler a bottleneck.

Solution

The subscriber list is represented as a skipfilter. The test function uses the subscriber's topic selectors (compiled to RegExp) to match the topic.
For each message, the list of subscribers that will receive the message is retrieved from the skipfilter.

Implementation

Each subscriber is stored in a skip list. As subscribers are added, they are assigned an autoincrementing ID and the skip list grows. Skip lists are preferred over slices here due to their discontinuous nature. Subscribers can be added and removed at random and the memory usage will remain bounded.

Each topic has a roaring bitmap. Each bit corresponds to a subscriber in the skip list. For each topic, a cursor is maintained to ensure that newly added subscriptions are always tested. Deleted subscriptions are lazily evicted from the topic bitmaps on lookup. Roaring bitmaps are compressed and discontinuous so memory usage again remains bounded as subscribers come and go.

Finding the complete list of subscribers to which any message must be delivered thus requires only taking the logical And of a set of bitmaps. This sort of operation has been made exceptionally efficient by leveraging SIMD instructions on modern CPUs.

Result

A multidimensional benchmark test shows a 20,000x improvement in throughput for certain highly concurrent and highly selective workloads.

An efficiency improvement of 4 orders of magnitude.

Conclusion

This technique has existed since at least 1980. ZeroMQ refers to it as inverted bitmaps.

The whitepaper was not discovered until after the implementation was complete. As with most computer algorithms, the creation of skipfilter turns out to be a rediscovery of a technique that predates the birth of its author.

kevburnsjr / skipfilter

An inverted bitmap index written in Go.

Skipfilter

This package provides a data structure that combines a skiplist with a roaring bitmap cache.

This library was created to efficiently filter a multi-topic message input stream against a set of subscribers, each having a list of topic subscriptions expressed as regular expressions. Idealy, each subscriber should test each topic at most once to determine whether it wants to receive messages from the topic.

In this case, the skip list provides an efficient discontinuous slice of subscribers and the roaring bitmap for each topic provides an efficient ordered discontinuous set of all subscribers that have indicated that they wish to receive messages on the topic.

Filter bitmaps are stored in an LRU cache of variable size (default 100,000).

This package is theadsafe.

View on GitHub

WebSockets vs Long Polling

Kevin Burns — Thu, 22 Jul 2021 20:48:37 +0000

This article contrasts the operational complexity of WebSockets and Long Polling using real world examples to promote Long Polling as a simpler alternative to Websockets in systems where a half-duplex message channel will suffice.

WebSockets

A WebSocket is a long lived persistent TCP connection (often utilizing TLS) between a client and a server which provides a real-time full-duplex communication channel. These are often seen in chat applications and real-time dashboards.

Long Polling

Long Polling is a near-real-time data access pattern that predates WebSockets. A client initiates a TCP connection (usually an HTTP request) with a maximum duration (ie. 20 seconds). If the server has data to return, it returns the data immediately, usually in batch up to a specified limit. If not, the server pauses the request thread until data becomes available at which point it returns the data to the client.

Analysis

WebSockets are Full-Duplex meaning both the client and the server can send and receive messages across the channel. Long Polling is Half-Duplex meaning that a new request-response cycle is required each time the client wants to communicate something to the server.

Long Polling usually produces slightly higher average latency and significantly higher latency variability compared to WebSockets.

WebSockets do support compression, but usually per-message. Long Polling typically operates in batch which can significantly improve message compression efficiency.

Scaling Up

We’ll now contrast the systemic behavior of server-side scalability for applications using primarily WebSockets vs Long Polling.

WebSockets

Suppose we have 4 app servers in a scaling group with 10,000 connected clients.

Now suppose we scale up the group by adding a new app server and wait for 60 seconds.

We find that all of the existing clients are still connected to the original 4 app servers. The Load Balancer may be intelligent enough to route new connections to the new app server in order to balance the number of concurrent connections so that this effect will diminish over time. However, the amount of time required for this system to return to equilibrium is unknown and theoretically infinite.

These effects could be mitigated by the application using a system to intelligently preempt web socket connections in response to changes in the scaling group's capacity but this would require the application to have special real-time knowledge about the state of its external environment which crosses a boundary that is typically best left uncrossed without ample justification.

Long Polling

Suppose we have the same 4 app servers in a scaling group with 10,000 connected clients using Long Polling.

Now suppose we scale up the group by adding a new app server and wait for 60 seconds.

We observe that the number of open connections has automatically rebalanced with no intervention. We can even state declaratively that if the long poll duration is set to 60 seconds or less, then any autoscaling group will automatically regain equilibrium within 60 seconds of any membership change. This trait can be reflected in the application’s Service Level Objectives. These numbers are important because they are used by operators to correctly tune the app’s autoscaling mechanisms.

Analysis

Service Level Objectives are an important aspect of system management since they ultimately serve as the contractual interface between dev and ops. If an application’s ability to return to equilibrium after scaling is unbounded, a change in application behavior is likely warranted.

Scaling Down

The following example illustrates difficulties encountered by a real world device management software company operating thousands of 24/7 concurrent WebSocket connections from thousands of data collection agents placed inside corporate networks.

The System

A Data Collection Agent, written in Go, is distributed as an executable binary that runs as a service on a customer's machine scanning local networks for SNMP devices and reporting SNMP data periodically to the application in the cloud.

One key feature of the product was the ability for a customer to interact with any of their devices in real time from anywhere in the world using a single page web application hosted in the cloud. Because each agent resides on a customer network behind a firewall, the agents would need to initiate and maintain a WebSocket connection to the application in the cloud as a secure full-duplex tunnel. The web service sends commands to agents and agents send data to the web service all through a single persistent TCP connection.

The Problem

There was one big unexpected technical challenge faced by the team when deploying this system that made deployments risky. Whenever a new version of the app server was deployed to production, the system would be shocked by high impulse reconnect storms originating from the data collection agents.

If a server has 2500 active connections and you take it out of service, those 2500 connections will be closed simultaneously and all the agents will reopen new connections simultaneously. This can overwhelm some systems, especially if the socket initialization code touches the database for anything important (ie. authorization). If an agent can’t establish a connection before the read deadline, it will retry the connection again which will drown the app servers even further, causing an unrecoverable negative feedback loop.

This proclivity toward failure caused management to change their policies regarding deployments to reduce the number of deployments as much as possible to avoid disruption.

The Solution

The problem was partially solved by implementing strict exponential retry policies on their clients. This solution was effective enough at reducing the severity of retry storms on app deployment to be considered a good temporary solution. However, deployments were still infrequent by design and the high impulse load spikes weren’t gone, they just no longer produced undesirable secondary effects.

Analysis

This temporary solution is only possible in situations where the server has complete control over all of its clients. In many scenarios this may not be the case.

If the agents were modeled to receive commands from the server by Long Poll and push data to the server through a normal API, the load would be evenly spread.

If using a Long Poll architecture, the deployment system would replace a node by notifying the load balancer that the node is going out of service to ensure the node doesn’t receive any new connections, then wait 60 seconds for existing connections to drain in accordance with the service’s shutdown grace period SLO, then take the node offline with confidence. The resulting load increase on other nodes in the group would be gradual and roughly linear.

When it comes to distributed systems and their scalability, people often focus on creating efficient systems. Efficiency is important but usually not as important as stability. High impulse events like reconnect storms can produce complex systemic effects. Left unattended, they often amplify the severity of similar effects in different parts of the system in ways that are both unexpected and difficult to predict.

If you fail to solve enough of these types of problems, you may soon find yourself a situation where so many components are failing so simultaneously that it’s exceptionally difficult to discern the underlying cause(s) empirically from logs and dashboards. An application’s architecture must be designed primarily in accordance with principle and remain open to modification in response to statistical performance analysis.

Conclusion

WebSockets are appropriate for many applications which require consistent low latency full duplex high frequency communication such as chat applications. However, any WebSocket architecture that can be reduced to a half-duplex problem can probably be remodeled to use Long Polling to improve the application’s runtime performance variability, reducing operational complexity and promoting total systemic stability.

Data Constraints: From Imperative to Declarative

Kevin Burns — Thu, 22 Jul 2021 07:23:54 +0000

There once was a client who wanted to port a Lambda from Typescript to Go. Thousands of lines of code spread across dozens of Typescript files, many of them automatically generated database models copy/pasted from other repositories.

The initiative was sound: To consolidate the business logic spread across various independent lambdas into a single application and in so doing unify a set of often inconsistent data structure definitions.

You see, the database was MongoDB which meant that the data model was whatever the developer decided the data model was when any given document was inserted into the database by any particular application. Some call this a “schemaless” database but I prefer the term “schema-on-read”.

Although MongoDB supports json schema validation on write as a functional equivalent to a database schema, this project used none. This is not surprising given that MongoDB’s marketing strategy consists primarily of incessantly trumpeting the advantages of unstructured data to unwitting javascript developers in the most obnoxious and damaging way possible.

I successfully avoided MongoDB for my entire career until one day came a client with an interesting set of problems. Despite my aversion to MongoDB on principle, the strongest advice I could give was to not have used MongoDB in the first place which is sometimes not an option given the unreliable state of present day time travel technology.

In order to provide meaningful advice to clients on how to use MongoDB well and prevent existing implementations from degrading, I would need an expert knowledge of MongoDB and that could only come from falling neck deep for months into a real world system with truckloads of dynamic unstructured data feeding the needs of real world customers.

I captured the opportunity and took on many tasks solving complex, elusive problems which often lead to the discovery of undefined behavior. We will focus on one such task:

The lambda migration

This lambda wasn’t ready yet. The lambda was known to have bugs and edge cases and the company’s leadership (CEO, COO, CTO) would need to look at it from every conceivable angle to ensure that the business logic was consistent with their expectations before it could be ported to Go. Leadership worked together intensively behind closed doors for a week until they produced a version of the lambda that they felt met the needs of their customers.

It was my job as a contractor to port the logic from Typescript to Go. I examined the logic. Studied it judiciously. Then I began porting it to Go in such a way that I could run an integration test suite against both my new version in Go and the existing lambda in Typescript to ensure that the output and database effects were identical in all conceivable scenarios.

Once I was satisfied that the battery of tests proved that my implementation matched the intended logic, a growing suspicion arose that the internally consistent and complete nature of the business logic might indicate that it could be reduced to a set of unique database constraints.

Raising this concern with the client, I received the following response verbatim which I will treasure with all my heart until the day that I die:

“Our business logic is too complex to be expressed as database constraints.”

Naturally, I took this as a challenge. After a few hours learning how indexes work in MongoDB, I produced a pair of compound unique indices (one sparse and one full) that would impose the exact same constraints enforced by the business logic on all new and existing data.

Extending the new integration test suite to support a third side-by-side implementation quickly proved that the pair of indices did in fact produce identical behavior to the 50 or so lines of business logic (which were now safe to delete) under all conceivable scenarios.

Leadership was stunned. I had accurately transformed a set of critical business rules from imperative logic to declarative constraints. Management no longer had to reference a spreadsheet with dozens of combinatorial expected outcomes. A description of the expected behavior could be reduced to two statements in plain English.

However, collections in MongoDB are not the tidy containers of data you expect coming from a decade of experience with schema-on-write databases like MySQL and Postgres.

When applying the new unique indexes to the collection, the migration failed. The reason it failed is because there existed data in the collection which didn’t match the constraints. This data was inserted into the database at a time when the logic for the lambda(s) was different. The errant data would need to be altered or deleted in order for the constraints to be applied.

Analysis of this data showed that it drifted from the constraints in a number of different ways. These hundreds of records were reduced to a handful of ways in which they departed from the expected schema. Laid on a spreadsheet was each type of data problem, it’s first occurrence, its last occurrence, the number of occurrences, and a column to track what ought to be done about it (DELETE, FIX, or TBD) along with relevant notes.

Most of the errant rows could be discarded as complete trash with no discernable value. In some cases the problems could be fixed with a migration. However, there also existed a class of problems where the data was incorrect in a way that could be corrected, except that to do so would produce unexpected behavior for end users.

There were enough instances of data problems that would adversely affect customers if fixed that it presented a significant challenge to the business. How would they communicate to their B2B customers that they'd been overcharged as a result of a bug in the system? Would they need to issue refunds to those business customers and would those business customers need to issue refunds to their customers?

Had the imperative logic not been converted to declarative data constraints, these accounting errors would have continued unnoticed.

Issues like this are important because left unaddressed they often lead to a culture where it is generally understood (and too often accepted) that customers having longer patronage are more likely to encounter systemic defects than newer customers. This can lead to churn, damaging customer retention and brand reputation.

This pattern is interesting as it reflects the history of MongoDB itself when users left in droves after the industry became wise to the misleading durability and consistency guarantees used to achieve their early benchmarketing results. MongoDB has come a long way since then and it is now a lot better than it was at not losing data.

If there is hope for MongoDB, I believe there is hope for humanity.

Conclusion

Modeling business logic as declarative constraints from the outset is likely to save loads of time and significantly improve the quality of your software product. If you can push the line from imperative logic toward declarative constraints you will impress your peers by discovering unknown unknowns.

Five Card Draw for Gophers

Kevin Burns — Mon, 24 Jun 2019 05:46:42 +0000

So, I'm on this airplane.

It's an 8 hour flight from LAX to Lima with an entertainment system to keep me ... entertained. Before starting a movie, I check out the games section and come across this poker game.

It's five card draw. One player. In Spanish. Buy in is $200 fake dollars and my balance after 30 minutes is $1,585. Ya, this is not a hard game.

In fact, this game is too easy. Annoyingly easy. Like it's letting me win. Is it possible that this game is actually random and I'm just some genius poker god? Or is the game feeding me cards to let me win?

This question bothers me. Deeply.

Hey, wait a minute. I'm a software engineer. I can just clone the game and fiddle with the internals to determine why this implementation seems so unbalanced.

Let's do it!

Here's the game: https://github.com/KevBurnsJr/stupid-poker

It starts with a deck

package poker

type deck [52]string

var suits = []string{"S", "H", "D", "C"}
var cards = []string{"A", "2", "3", "4", "5", "6", "7", "8", "9", "T", "J", "Q", "K"}

func newDeck() *deck {
    d := &deck{}
    for i, s := range suits {
        for j, c := range cards {
            d[i*13+j] = c + s
        }
    }
    return d
}

An ordered deck isn't very useful, so let's make it shuffle.

// shuffles the deck in place
func (d *deck) shuffle() {
    for i := len(d) - 1; i > 0; i-- {
        j := rand.Intn(i + 1)
        d[i], d[j] = d[j], d[i]
    }
}

Now that we have a deck, let's create the game

const (
    stateReady = iota
    stateDealt
)

type Game interface {
    // Deal initializes the game, returning the player's initial hand and new balance
    Deal() (Hand, int, error)

    // Exchange accepts a slice of integers corresponding to indicies for cards in the given hand
    // It discards those cards from the hand and replaces them with new cards from the deck
    // It returns the final hand and the new balance
    Exchange([]int) (Hand, int)
}

The game only has 2 states. Either you are dealing a hand, or you are drawing cards and the hand is over.

type game struct {
    deck    *deck
    state   int
    anty    int
    balance int
    hand    Hand
    mutex   *sync.Mutex
}

func NewGame(anty int, balance int) Game {
    return &game{
        deck:    newDeck(),
        state:   stateReady,
        anty:    anty,
        balance: balance,
        mutex:   &sync.Mutex{},
    }
}

func (g *game) Deal() (Hand, int, error) {
    g.mutex.Lock()
    defer g.mutex.Unlock()
    if g.balance < g.anty {
        return Hand{}, g.balance, ErrNoBalance
    }
    g.deck.shuffle()
    g.balance -= g.anty
    g.hand = newHand(g.deck[0:5])
    g.state = stateDealt
    return g.hand, g.balance, nil
}

func (g *game) Exchange(cards []int) (Hand, int) {
    g.mutex.Lock()
    defer g.mutex.Unlock()
    if g.state != stateDealt {
        return g.hand, g.balance
    }
    hand := g.hand
    for i, n := range cards {
        if n >= len(hand) {
            continue
        }
        hand[n] = g.deck[i+5]
    }
    res := hand.Score()
    g.balance += payout[res]
    if payout[res] > 0 {
        g.balance += g.anty
    }
    g.state = stateReady
    return hand, g.balance
}

The hand is also an array of strings.

const (
    Hand_RoyalFlush    = "Royal Flush"
    Hand_StraightFlush = "Straight Flush"
    Hand_Quads         = "Four of a Kind"
    Hand_FullHouse     = "Full House"
    Hand_Flush         = "Flush"
    Hand_Straight      = "Straight"
    Hand_Trips         = "Three of a Kind"
    Hand_TwoPair       = "Two Pair"
    Hand_Jacks         = "Jacks or Higher"
    Hand_Nothing       = "Nothing"
)

type Hand [5]string

// Score scores the hand
func (h Hand) Score() string {
    if len(h[0]) < 1 {
        return Hand_Nothing
    }
    if h.isFlush() {
        if h.isRoyal() {
            return Hand_RoyalFlush
        }
        if h.isStraight() {
            return Hand_StraightFlush
        }
        return Hand_Flush
    }
    if h.isStraight() {
        return Hand_Straight
    }
    pairs, trips, quads, highPair := h.detectDupes()
    if quads > 0 {
        return Hand_Quads
    }
    if trips > 0 {
        if pairs > 0 {
            return Hand_FullHouse
        }
        return Hand_Trips
    }
    if pairs > 1 {
        return Hand_TwoPair
    }
    if pairs == 1 && highPair {
        return Hand_Jacks
    }
    return Hand_Nothing
}

We'll need some tests to ensure the hand scoring method continues to work as expected.

// Table based test to ensure correct scoring of hands
func TestScoreHand(t *testing.T) {
    var tests = map[string]string{
        "AS KS QS JS TS": Hand_RoyalFlush,
        "JD TD AD QD KD": Hand_RoyalFlush,
        "KS QS JS TS 9S": Hand_StraightFlush,
        "KS KH KD KC 9S": Hand_Quads,
        "KS 9S KH KD KC": Hand_Quads,
        "KS 9S KH KD 9C": Hand_FullHouse,
        "TS 8S QS JS 4S": Hand_Flush,
        "AS KD QS JS TS": Hand_Straight,
        "AS AH AD JS TS": Hand_Trips,
        "AS AH JS AD 4S": Hand_Trips,
        "AS AH JS JD 4S": Hand_TwoPair,
        "AS JD 4S AH JS": Hand_TwoPair,
        "AS JD AH JS 4S": Hand_TwoPair,
        "AS AD 8H JS 4S": Hand_Jacks,
        "JS JD 8H 9S 4S": Hand_Jacks,
        "TS TD 8H 9S 4S": Hand_Nothing,
    }
    for c, exp := range tests {
        h := newHand(strings.Split(c, " "))
        res := h.Score()
        if exp != res {
            t.Log("Unexpected Result", h, res, "!=", exp)
            t.Fail()
        }
    }
}

After that we just slap an interface on it and call it a game :)
http://stupid-poker.kevburnsjr.com

You can find the full code on Github
https://github.com/KevBurnsJr/stupid-poker/tree/master/internal/poker

So... The end result?

It's still pretty easy to win. That probably means the balance issue has nothing to do with the random number generator and has more to do with the payouts being too high in relation to the the odds.

We had fun and we built a game. It's not likely to earn us the Turing Award.

Hi, I'm Kevin Burns

Kevin Burns — Sun, 23 Jul 2017 18:32:05 +0000

I have been coding for 20 years.

You can find me on GitHub as KevBurnsJr

I live in Menlo Park.

I work for Dry Roasted Peanuts

I mostly program in these languages: Go, PHP, Javascript, HTML, CSS.

I am currently learning more about twice a day.

Nice to meet you.