You can use Semy to validate semantic versions, extract version identifiers, check if two versions are equal, and check if a version is newer or older than another.

Why?#

I wrote Semy because I have multiple projects that require a semantic version parser. Semy was purpose built for those needs.

Technical Tidbits#

I developed Semy as a single header/source implementation so it’s easily vendored into my own (and your own) projects. It also includes CMake and Autotools build scripts for traditional compilation and installation.

According to the SemVer specification, there is no length limit on the number of pre-release and build identifiers a semantic version can have. I wrote Semy without dynamic memory allocation, so the implementation does assume a maximum size, however, that limit will never be realistically hit in practice.

Semy is extensively tested:

• Unit tests with 100% code coverage
• Fuzz tests (libFuzzer and AFL++)
• Code sanitizers (UBSAN, ASAN, and MSAN)
• Extensive run-time checks

The SemVer specification is published at https://semver.org/.

The Initial Release#

I released Semy at version 0.9.0 because it’s well tested and “stable,” but I’d like its API to bake in the wild before I commit (pun intended) to a 1.0.0 release.

Semy is available under the MIT License. Its code is published at https://github.com/hgs3/semy.

The quote is widely attributed to the Roman Stoic philosopher Seneca. Well, sorry Mr. Seneca, but I’m going to disagree.

It Assumes Preparation is a Prerequisite#

Not all luck requires preparation. A baby born into a billionaire family didn’t do “pre-birth preparatory work” to secure their inheritance. If you find a $100 bill on the sidewalk during your routine walk to the grocer, your “readiness” didn’t put it there.

The quote implies that luck is earned, but it’s often unearned, unasked for, and unexpected.

It Ignores Bad Luck#

The adage implicitly assumes luck is a positive force, but in reality it’s a spectrum.

A cancer diagnosis, a house destroyed by a tornado, or a freak accident aren’t the result of “bad preparation.” They are instances of randomness. You can be the most prepared person in the world and still be sidelined by a black swan event. To use Seneca’s logic, we would have to imply that victims of misfortune simply weren’t “ready” for a better outcome.

It Glosses Over Systemic Inequality#

There is a hidden assumption that everyone is eventually presented with a “big break.” Unfortunately, opportunity is not distributed equally. While technically anyone born in the U.S. could become President, the statistical reality is tied heavily to one’s starting point.

The Math of Failure#

If success were truly a matter of “preparation meeting opportunity,” we would see a much higher correlation between hard work and success. Instead, the data tells a story of attrition.

Business Failure#

According to the U.S. Bureau of Labor Statistics, roughly 20% of businesses fail in their first year, and a staggering 65% are gone by year ten. Are we to believe that 65% of people who put their life savings and years of effort into a business simply “weren’t prepared”?

Or is it more likely they were met with a “bad luck” event they couldn’t control. When we use Seneca’s logic, we are forced to tell these millions of people that their failure was a personal lack of readiness, rather than the statistical reality of a volatile market.

Creative Failure#

We call creative industries ‘hit-driven’ for a reason. ‘Hits’ are the intersection of talent and timing, and timing is just another word for luck.

• Art: 75% of independent visual artists make less than $10,000 a year. ^[1]
• Music: Only 0.4% of artists earn a living wage from streaming royalties. ^[2]
• Games: Over 50% of indie games released on Steam earned less than $1,000 in total lifetime revenue. The top 0.5% account for 80% of all revenue! ^[3]

To suggest these passionate people “weren’t prepared” is an insult to their craft.

The Real Definition of Luck#

Luck is randomness that affects you. It is a neutral force. It can be a tailwind or a headwind.

Why Does The Quote Persist?#

If the logic of the adage is so flawed, why do we keep repeating it? I think the answer is simple: it gives us the illusion of agency. We want to believe we are the pilots of our lives. It’s comforting to think that if we work hard enough and stay ready we can manifest success. It turns a chaotic, unfair world into a meritocracy.

Why This Matters#

I felt compelled to write this because, while the quote is intended to be inspirational, it has a dark side: it shifts blame.

When we define luck as “preparation meeting opportunity,” the inverse becomes a weapon. It becomes a silencer for those raising their hands about systemic barriers. It creates guilt and shame in the minds of founders and creatives, like a form of gaslighting. It tells us to look at the successful and say they deserved it, and look at the struggling and say they missed it.

Preparation is Still Necessary (But Not a Guarantee)#

Despite my misgivings, this is not a call to nihilism. Success is like a lottery: years of preparatory work are the price of the ticket. If you don’t prepare, you aren’t even in the drawing.

You should absolutely hone your craft and work your hardest, not because it guarantees a win, but because it’s the only way to be eligible if lightning strikes. But we need to stop lying to the people standing in line, telling them that the harder they grip their ticket, the more likely the universe is to pick their number.

Closing Thoughts#

Seneca’s intent was to encourage perseverance. Unfortunately, his adage has morphed into a tool for survivor bias and contributes to the just-world fallacy. ^[4]

For many, “opportunity” is actually a safety net provided by a wealthy family or benefactor, allowing for years of “preparation” that others cannot afford. For others, luck is lightning in a bottle, and it is doubtful that even the “survivors” could repeat their success if they had to restart from zero.

It is far more honest and empathetic to acknowledge luck for what it is: a random force of nature. We can control our effort, but we can’t control the wind.

I enrolled in an introductory Photoshop and Illustrator course at my local university. It’s been at least a decade since I used them (I prefer the free alternatives, i.e. Inkscape, Krita).

Photoshop was about as good (and buggy) as I remember it, but now with AI tools. Illustrator I’d barely used in the past, but it functioned similarly enough to Inkscape so I picked it up quickly.

Alien Lo-fi Animation#

The most interesting assignment in the course was the final assignment: to make a lo-fi animation.

I’m no expert in animation. Most of the animations I’ve produced were for simple video games I programmed as a teenager and those on the landing page of Railgun Labs, but that’s precisely what made the assignment so much fun!

The animation I created is a looping lo-fi animation of an alien in their spaceship passing by our solar system.

It’s not perfect by any means (there’s lots of visual artifacts), but it’s something I’m proud of. I missed one class day due to being out sick, but if that hadn’t happened, I’m sure I could have taken it to the next level.

I drew the entire animation by hand with a Wacom drawing tablet. I’d never used a drawing tablet prior to the course. For the most part, it was like drawing with pencil and paper except more forgiving as I could easily undo my mistakes.

Closing Thoughts#

I don’t have the opportunity to make many animations, so I very much enjoyed the final assignment. And, based on the experience, I think I will invest in my own drawing tablet.

When I first heard there was such a thing as “caramel root beer” I was immediately apprehensive. I like caramel, and I like root beer, but there’s no way those flavors mix... or so I thought. When I finally tried one, I found myself enjoying it! There are several caramel root beers out there, but in this post I wanted to highlight my favorite which is Cicero’s.

The problem with many caramel root beers is the flavor ratio is asymmetric — either too much caramel or too much root beer. Cicero, however, strikes the perfect balance, I’d say about 50/50 even. You can easily distinguish the caramel and root beer flavors when you drink it.

The soda has a mild bite and decent froth when poured. The root beer flavor, even on its own, is very solid with vanilla and mild spiciness. The caramel is great too with a touch of saltiness further elevating it. There’s a great amount of carbonation; you can feel it bubbling on your tongue.

The color is a perfect caramel-to-dark amber hue, similar to a traditional root beer but with more of a golden, caramel-toned glow. The smell of the beverage is strongly dominated by the caramel, but that’s not a bad thing. And although the root beer-to-caramel flavoring is balanced when drinking, the aftertaste does lean caramel. My final verdict is if you like caramel and Root Beer, then I’d strongly recommend it.

Rating: A Tier

Little did I know what I got myself into. These bars are incredibly addictive. You can’t eat just one.

My copycat recipe attempts to reproduce the bars using only five ingredients found at your local grocery store. And they can be prepared in less than 10 minutes!

The general idea behind my recipe is to create a melted chocolate-peanut butter mixture, then add graham crackers and Rice Krispies for crunch.

I recommend melting the chocolate on its own, without adding butter, cream, or condensed milk. I’ve observed that those extra ingredients introduce moisture, which can soften the Rice Krispies and graham crackers, taking away their satisfying crunch.

While I like to melt the chocolate in a wok, you can also use a double boiler or even the microwave if you prefer.

Ingredients#

• 2 cups semi-sweet chocolate chips
• 1 tablespoon creamy peanut butter
• 1 teaspoon brown sugar (light or dark, depending on your tastes)
• 1 cup Rice Krispies
• 1 cup Chocolate Teddy Grahams ^[1]

^[1] If you cannot find Chocolate Teddy Grahams you can use chopped-up Honey Maid Chocolate Graham Crackers as a substitute.

Steps#

1. Melt 2 cups semi-sweet chocolate chips over low heat in a non-stick pan or wok until smooth. Constantly stir the chocolate so it doesn’t burn.
2. Add 1 tablespoon creamy peanut butter and 1 teaspoon brown sugar to the melted chocolate and mix together until blended.
3. Remove the mixture from the heat and add 1 cup Rice Krispies and 1 cup Chocolate Teddy Grahams. Stir until these dry ingredients are coated by the chocolate mixture.
4. Transfer to an 8x8 baking dish lined with parchment paper and store in the fridge until solid (2 to 3 hours).
5. Remove the solid chocolate mixture from the fridge, cut into candy bars, and store in an airtight container in a cool, dark place.

The ECS Design Pattern#

Let’s begin with a quick refresher on what ECS is, conceptually:

Entity

It represents a “thing” in a game (e.g. a player, a tree, a bullet). Think of it as an empty container.

Component

This is pure data. It describes a specific attribute of an entity (e.g. Position{ x, y, z } or Health{ value }). An entity gains capabilities by having components attached to it.

System

This is pure logic. It processes entities with a specific set of components and performs operations on that component data. For example, a “movement system” might process all entities that have both a Position and a Velocity component.

Design Patterns as Missing Language Features#

A design pattern is a general, reusable solution to a common problem that occurs within a given context in software design. There have been many books published about design patterns, one of the most famous being the “Gang of Four” book.

One of the criticisms of design patterns is that many of them appear to be workarounds for missing language features. Peter Norvig demonstrated that 16 of the 23 classic design patterns in the “Gang of Four” book are either simplified or eliminated by more powerful language constructs. This is further reinforced by various academic papers like "On the Interaction of Object‑Oriented Design Patterns and Programming Languages" by Gerald Baumgartner, Konstantin Läufer, and Vincent F. Russo.

This makes me wonder: What underlying language features is the ECS design pattern effectively a workaround or implementation of?

Mixins#

Mixins are an object-oriented concept that allows a programmer to inject some code into a class. Instead of reusing code through inheritance, you “mix in” the code into the class instead.

Mixins were introduced by the Flavors programming language, an early object-oriented extension to Lisp. Its creator, Howard Cannon, was inspired by a local Ice Cream Parlor shop which offered basic flavors of ice cream (vanilla, chocolate, etc.) and blended them into a combination of extra items (nuts, chocolate chips, fudge, etc.). These extra items were called “mix-ins".

Bringing this back to ECS: The Entity is the ice cream and the Component is the “mix-in". The idea is you take your ice cream (the entity) and mix-in the nuts and chocolate chips (the components). More technically, you take a Player entity and mix-in a Position and Health components.

Reflection#

Reflection is the ability for a programming language to examine and modify its own structure and behavior at runtime. In object-oriented programming languages, reflection might allow the inspection and modification of classes, interfaces, fields, and methods.

In languages with mixins, reflection could allow the addition or removal of mixins from objects at runtime. Reflection could also be used to check which mixins an object has before passing them off to a function that operates on them.

Connecting the Features#

Suppose we have a multi-paradigm programming language that has objects, free functions, and supports both mixins and reflection. In such a hypothetical language, we could reproduce the ECS pattern using native features:

Entity

This is an “empty” object (e.g. a Player object).

Component

This is an object with state (your “mix-ins,” like a Position or Health object).

System

This is a free-function that uses reflection to check if the entity has the required mixins (components) and then operates on them.

To reproduce ECS:

1. Instantiate an empty object (the Entity).
2. Instantiate the stateful objects (the Components).
3. Use reflection to mix-in the components into the entity object.
4. Pass the entity object to free functions that can operate on objects possessing the mixins (the System).

This is, in effect, ECS but represented entirely by native language features.

Mixins Aren’t Strictly Required#

It’s important to clarify that mixins are not strictly required to achieve this. You might prefer not to use mixins if, depending on the programming language, their members occupy the same namespace as the entity object and risk naming conflicts with other component members or existing object fields. In this case, you could rely solely on reflection:

To reproduce ECS without mixins:

1. Instantiate an empty object (the Entity).
2. Instantiate the stateful objects (the Components).
3. Use reflection to inject the components as distinct fields onto the entity object.
4. Pass the entity object to free functions that can operate on objects possessing the fields (the System).

The “Rediscovery” by Game Developers#

If mixins and reflection have existed for decades, why is ECS often presented as an innovation, popularized by game developers?

In my opinion, the answer lies in the constraints of statically typed languages, which dominate the game industry. While incredibly powerful for performance, languages like C++ inherently lack the built-in runtime dynamism, flexible reflection, and mixin capabilities found in languages like Ruby or Lua.

Thus, ECS emerged as a pragmatic and highly effective design pattern to mimic these dynamic, compositional capabilities within a more rigid, compiled environment. It’s an architectural solution that allows C++ programmers to achieve the same kind of runtime flexibility that is often a native feature in other languages, while simultaneously offering superior control over data layout for performance.

Closing Thoughts#

I sometimes see “ECS frameworks” being announced for programming languages that already possess the inherent dynamism and reflective capabilities that ECS simulates. Hopefully, this exploration of ECS offers a new perspective. It’s a testament to clever design and engineering that a pattern can effectively bring the benefits of one paradigm into the ecosystem of another, proving that sometimes, the “new” is simply a brilliant re-invention of the familiar.

Most of the art I create on my own is digital, especially vector art. I enjoy vector art because I can create shapes exactly the way I imagine them. While I don’t do much hand drawing, I believe improving that skill strengthens my overall artistic ability.

Early Semester Work#

At the beginning of the semester, we worked with hard and compressed charcoal sticks. Charcoal creates much deeper, bolder shades than pencil does.

This was my first time using charcoal. They feel less precise than a pencil, but that might be due to my inexperience.

Mid-Semester Work#

Mid-semester we explored cross contouring. Cross contouring is a technique focused on drawing wireframe-like lines that wrap around forms to express three-dimensionality. The goal is to capture the shape and volume of the object, not just its outline.

I had never heard of cross contouring before this course, but it quickly became my favorite exercise. Emphasizing structure and spatial depth helped me make a noticeable leap forward in my skills.

Final Project#

For the final project, we combined everything we had learned into one complete still life drawing.

Everybody Can Draw#

One of the most quietly discouraging things I encountered growing up was hearing people say things like, “I’m a so and so and therefore I can’t draw” where so and so could be math instructor, accountant, doctor, etc. These kinds of statements, especially from authority figures, made me falsely believe that drawing required some kind of innate talent.

But that’s simply not true.

Drawing is a learned skill, like playing a musical instrument. It takes study, repetition, and practice just like anything else.

Closing Thoughts#

If you’re considering a drawing course, I highly recommend choosing one with longer class sessions rather than one that meets more frequently but for shorter periods. When you’re drawing, time flies and those extended hours help you settle into the work and produce something consistent.

I’m not a big soda drinker. If I’m presented with a choice of generic sodas, I usually prefer water, but root beer is the one soda I never pass up.

Origins#

Root Beer has its roots (pun intended) in pre-colonial Indigenous American and early settler traditions. Indigenous peoples of North America brewed medicinal and ceremonial teas from roots, barks, and herbs. These mixtures were used to treat ailments, promote health, or for ritual purposes. While they weren’t carbonated or sweetened like modern soda, they laid the botanical foundation for what would become Root Beer.

In the 17th and 18th centuries, European settlers adopted these traditions, brewing low-alcohol fermented drinks flavored with local roots and herbs. These beverages were often safer than water and considered nutritious. Over time, these homemade tonics evolved—especially with the rise of American patent medicines and soft drinks in the 19th century. What began as herbal brews turned into sweetened, carbonated, commercially bottled Root Beer.

A Natural Soda#

Root Beer is one of the oldest sodas, second only to Ginger Ale and Sarsaparilla. It can be brewed entirely from naturally occuring ingredents. Its distinctive flavor comes from the combination of natural herbs and spices, such as:

• Sassafras root
• Sarsaparilla
• Birch bark
• Wintergreen
• Licorice root
• Spices like cloves or anise

Its one of the few sodas that can be produced in your home kitchen!

An Open Source Soda#

Root Beer isn’t “owned” by anyone, unlike brand-name sodas like Pepsi, Dr Pepper, or Sprite. There’s no single recipe, like there is for Coca-Cola. Anyone can make their own version.

This freedom has given rise to many variations, from home brews to commercial brands. In North America, you’re probably familiar with the mainstream A&W, Mug, and Barq’s.

Each variation of Root Beer gets its unique flavor from the specific mix of herbs and spices. The method of carbonation, whether by machine or natural fermentation, affects the texture and “head” of the drink.

My Collection#

As of this writing, I have 64 bottles in my Root Beer bottle collection.

Whenever I try a new Root Beer, I record my impressions. I plan to post reviews of each one in future blog entries. Stay tuned!

Initial Reception#

The initial feedback on Reddit was largely positive. Responses came in quickly and continued for several days.

Hacker News, however, was silent: no comments, no votes, nothing. I figured maybe I posted at an off time or there just wasn’t interest. But — a few days later — I woke up to find my post on the front page!

It turns out Hacker News has a second-chance pool where moderators can manually boost promising projects that did not receive enough initial attention. I have no insight into this process or who the moderator was who surfaced Confetti, but if you’re reading this: thank you.

Since sharing the project on social media, Confetti’s GitHub repository has seen a surprising amount of traffic, suggesting ongoing interest.

Comparisons with JSON#

Several users compared Confetti to JSON. The comparison mainly revolved around typing: JSON has it, Confetti doesn’t.

JSON offers five built-in types: booleans, numbers, strings, arrays, and objects — plus the special value null. Confetti, by contrast, is typeless: it operates using strings and directives.

Types vs Typeless#

I find the comparison with JSON interesting because, in practice, JSON’s typing doesn’t do as much as often implied:

Firstly, JSON lacks a schema language. Schema validation is the responsibility of the user application. Whether you expect an array, object, or a particular element type, you still have to validate it manually — just as you would with Confetti.

Secondly, when validating strings, you sometimes need to go further. For example, checking if a string is a valid ISO 8601 or RFC 3339 timestamp requires manual validation — just as it would with Confetti.

Lastly, when dealing with numbers, checking if a value is a number in Confetti is as easy as comparing it against a simple regular expression. And for booleans and null, these are just strings — “true”, “false”, and “null” — and can be verified with a simple string comparison.

So, in my view, JSON’s minimal typing doesn’t add much in real-world use cases. If you are looking for real, schema-enforced types, then you might consider languages like Pkl that support user-defined types and structural validation.

Feature Suggestions#

Alongside the initial feedback, I received some thoughtful feature suggestions. Here are a few that stood out:

Bracket Syntax#

One suggestion was to use brackets to denote multi-line directives.

Right now, you’d use a trailing backslash:

foo bar \
  baz qux

The proposed alternative uses brackets:

foo [bar
  baz qux]

I found this suggestion interesting because the syntax resembles an array (minus the commas) as written in various programming languages. It might even feel more intuitive for long directives that represent list-like concepts. However, as interesting as the suggestion is, subdirectives can also be used to represent list-likes:

foo { bar
  baz qux }

Here, an application would treat the subdirectives and their arguments as entries in the “list”. So, while the “array”-like syntax is interesting, I don’t feel the need to implement it.

Execution Model#

Another suggestion was to give Confetti an execution model — essentially turning it into a programming language. While intriguing, this is beyond the scope of what I intended for the language.

Confetti is, and will remain, a configuration language. Its syntax is flexible enough to support domain-specific languages (as shown on the examples page), but embedding an execution model would go beyond its design goals.

Discovering Prior Art#

On the Confetti homepage, I compared Confetti to well-known configuration and data-interchange formats like XML, JSON, INI, and TOML. After launching, several users pointed out other configuration languages that resemble Confetti syntax. I’ll briefly discuss them:

SDLang#

Simple Declarative Language, or SDLang, has some syntactic overlap with Confetti, but goes further than Confetti by adding types for strings, numbers, boolean and null, data/time formats, and binary data. While they might share some syntactic similarity, SDLang is clearly closer to JSON or TOML than it is to Confetti.

KDL#

KDL also has a surface-level similarity with Confetti, but again, it supports types and even allows type annotations. It, too, is closer to JSON or TOML.

Tcl#

Tcl is a dynamic programming language with a syntax that vaguely resembles Confetti. However, it’s a full-fledged language with dynamic typing and an execution model. If you like Confetti but need built-in types and evaluation, Tcl — or Lua — might be worth exploring.

Tentative Plans#

As of this writing, Confetti is “done.” Both the C implementation and the specification are in 1.0 beta status.

My plan is to let the language “bake” in real-world usage for a while. Depending on how things go, I might increment the version to 1.0 release candidate in the coming weeks or months, and eventually tag a stable 1.0.

Language Ports#

The current, canonical implementation of Confetti is implemented in C11. I originally intended to write a Python and Go port of Confetti, but I don’t personally have a need for them right now. Authoring them would be mostly for the benefit of others.

With that said, the specification is complete and simple enough that anyone could write a port fairly easily. If you do, I’d love to hear about it!

Closing Thoughts#

The positive reception to Confetti has exceeded what I imagined. I’ll continue to support Confetti for the foreseeable future. If you find bugs in the specification or implementation, please report them on the project’s issue tracker.

Why?#

Formats like XML and JSON are data-interchange formats. They are not great as configuration file formats as the signal to noise ratio is too high. A missing comma or missing colon can throw everything off. JSON, in particular, doesn’t even allow comments!

The biggest downside of these formats is they aren’t localization friendly. Formats, like JSON, require the English words null, true, and false, and Western digits 0 through 9.

Confetti is different. Confetti lets you write configuration files in your native language. It’s typeless and doesn’t make assumptions. For example, you can decide whether true, yes, or on makes the most sense for your application.

Minimalistic Design#

Confetti syntax is loosely inspired by Unix configuration files, the shell word splitting algorithm, and JSON. I wanted the format to remain typeless and support hierarchical structures.

I designed Confetti to be extensible. Just like how John Grubber defined Common Markdown and others have created their own Markdown flavors, I encourage others to create their own Confetti flavors.

Reference Implementation#

I’ve written an implementation of a Confetti parser in C and its source code is hosted on GitHub. This implementation parses Confetti source incrementally. It does not build an in-memory tree-representation like most XML and JSON parsers.

Closing Thoughts#

I have zero expectations for Confetti. Existing formats, even with their faults, are entrenched in the software ecosystem. Nonetheless, I created Confetti because I believe it addresses real problems and I hope others will see that too.

Products First, Business Second#

I’m a passion-driven software developer so I pick projects that I think are “interesting” rather than what will maximize profits. Put another way, I’m a product guy first and foremost. I love to build things. To me, money is a tool at best and an obstacle at worst.

My business strategy is to create products that I think are interesting because if I have a use for them, then I believe others will too. I understand this approach might yield fewer sales, so I keep my expenditures low. I view it as an acceptable tradeoff as it allows me to feel more connected to my work.

Naming the Company#

I named the company “Railgun” after my favorite gun from Quake II. I grew up playing old-school first person shooters and the railgun always stood out as a unique weapon to me.

I added “Labs” after my love of early Hollywood Mad Scientist tropes (see the original Dr. Frankenstein in the 1931 movie “Frankenstein”).

As a name, I think “Railgun Labs” is fun! It conveys high velocity with experimentation which, I think, is perfect for a small scrappy tech startup.

Designing the Website#

When designing the company website, I wanted to balance fun with professionalism. I opted for a minimalistic, flat art style to give that professional feel. I injected “fun” by choosing vibrant colors.

Early Designs#

I was initially conflicted on how to create the balance I was looking for. My early designs, I think, went a touch too far:

In this early design, I had mostly finalized the home page layout and logo design, but the colors scheme was completely different from the final version. In the final design, the colors are vibrant and professional and there’s a bit more humor injected. For example, the “goto” in “GOTO Products” is a reference to the goto statement.

Websites are always an ongoing project. I anticipate that I will refresh the design from time-to-time.

Designing a Mascot#

Not too many tech companies have a mascot. The choice to have one was motivated by my desire to create a strong brand identity as well as a sense of playfulness.

The mascot was initially based on the appearance of Doctor Tomoe from the anime Sailor Moon. I wasn’t too big of an anime fan when I was younger. My viewing was limited to Pokémon and whatever aired on Toonami, but the design of Doctor Tomoe always stuck with me.

My initial design of the mascot was very reminiscent of Doctor Tomoe. I think the influence is fairly obvious, once pointed out.

As I iterated on the design, I toned it down, along with the website, to present the more professional look I was after. As I approached the final design, I gave the mascot a name: Dr. Chip Codewell. He represents my commitment to innovation.

Like the website, I expect Chip to continue to undergo refreshes from time-to-time.

Product Pricing#

When it comes to pricing my products and services, I wish I could say there was some master strategy or scientific equation I used, but I mostly just reviewed what competitors in the same space were offering and based my prices on theirs. I also gauged how “expensive” it would be to replicate my work and set my prices lower to make my offerings more appealing.

Marketing#

I’m not a big social media person, but for marketing I’m relying on it. I am tentatively planning to attend various, in-person venues in the future. And my direct outreach to various tech companies has begun.

My post announcing Unicorn reached the front page of Hacker News. I attribute the success to when I posted: I made the announcement early-mid December when, I think, a non-negligible amount of people were out on vacation for the Holidays and new content was slow thereby making it “easier” for me to get noticed.

An Ongoing Adventure#

Railgun Labs is an ongoing venture for me. I’m not sure where it will lead, but I don’t regret the decision to quit my job to pursue it. I plan to continue posting meta updates here as well as other insights as I continue this journey.

Goals for this Website#

My intentions are to write about my personal projects, thoughts on technology, and my other hobbies (movies, games, music, etc). I started my own independent software company not too long ago so I intend to share my experience as a budding technopreneur.

Subscribe for Updates#

I’m not a fan of centralization, much less so when it comes to online communication. You won’t find me on X or Bluesky. If you’re interested in following my progress, you can subscribe with your RSS or Atom reader of choice.

Closing Thoughts#

I am not a chronically online person and I avoid traditional social media. I don’t consume news or much media outside of my interests. As a result, you might find my perspectives a bit outside the norm. Nonetheless, I hope you’ll find my writings, at the very least, amusing.