I don't write often about anything that is deeply personal despite this website being my personal blog. On February 16th, 2025, I asked Madeline to marry me. The proposal was a surprise I decided to spring on her while spending the weekend in Denver. You might think as a Texan why we were in Denver in February, during a particularly harsh blizzard. We were exploring the option of possibly living there given we both had jobs we could work remotely, and we wanted to see Denver at what we felt would be the harshest weather, given the relatively mild winters in Texas.

I remember each of Madeline's reactions as we approached what I not so delicately placed on our itinerary as a surprise. Given our plans of potentially moving, it made sense that we would spend time walking in the cold snow, looking at potential houses and picturing what a life in Denver might look like. Maybe we would fill our houses with the latest outdoor fashion and live our new lives as another one of those couples that spends all of their weekends hiking, possibly even trail running, leaving all of our friends in awe as we stay fit and brag about the number of miles and steps we get each day. We could have a catio where the cats would paw desperately for attention from passing neighbors. We could take a bus to Union Station and check out the latest hip new coffee shop in downtown Denver, or walk down ___ street and grab some new antiques to decorate the house. Attend book clubs and meet new friends.

However, this neighborhood in particular did not inspire much confidence for us, especially Madeline. As we walked around our surprise destination, waiting for a specific moment in time she tried to guess the surprise. One guess was "you take me to an air bnb you own, and that's where you strangle and murder me. I always knew it was too good to be true." We passed a junvenile detention center and pondered what we might do as parents if our kids ever ended up in "juvi."

The clock hit 6:30, and it was time. I navigated us to our destination we had passed several times, feeling anxious. She had no clue, and I was worried that I may have to change my plans that evening, despite quietly announcing to her Dad before he dropped us off at the airport what I was planning to do this weekend. Something Madeline had announced that weekend, which wasn't entirely a shock, was that she "did not like the taste of beer, and maybe it's time to stop trying to like it". Knowing her parents were awaiting news of our proposal, yet also her new disgust towards beer, I was rapidly pondering ways to back out of proposing at the Oakwell Beer Spa in Denver. Despite getting the Valentines Day lovers special, the surroundings gave little confidence that the "spa" far exceeded the "beer" part of that experience.

I was in luck as we passed through the door and were greeted with both a well put interior and an exceptionally warm staff. They explained the experience to her, and she was immediately giddy with excitement. One thing I'll always love about Madeline is her enthusiam towards things, and despite her statements about beer, she was really excited about getting to take a dip in what was effectively a hot bath loaded with beer hops. That and there were samples of wine and cider for her to choose from.

We got to our private spa room as it filled with hot water, sampled with our chosen set of minerals and hops, and dined on a basket full of chocolate covered strawberries, and made mimosas out of champagne and orange/cranberry juice. After some time in a thermal spa, and a shower, we moved to the tub, where I would give her a hand crafted valentines day note. As she finished reading, that's when I popped the question. Madeline claims she blacked out several times that evening unable to process everything. I'll never forget her expression as we entered the spa, when she got to see a giant dispenser full of different wines and ciders, when she saw the strawberries and champagne, and when she saw the temporary ring I used to propose to her from James Avery. Her expression through all of it was full of the same infectious enthusiasm I fell in love with.

I'm writing this on April 13th, 2026, two days after our wedding. Madeline did all of the planning for the honeymoon, including buying the plane tickets to our location, Japan. It's worth noting that her Dad, Ted, retired working at American Airlines. I was totally unaware of what was going to happen when we went to the Admiral Lounge at the DFW airport. "My dad got us into the lounge" she said, correct in that I would assume this was his gift to us for our honeymoon. I had wondered why he only gave us access to the lounge this time and never before, but I was touched by the idea.

After enjoying a full breakfast buffet with french toast bread pudding, we left for our gate uncharacteristically early. Apparently, Ted had also got us priority boarding, a suspicious perk.

Now, to my surprise, I am sitting here in a massive adjustable seat, that can fold down into a full bed, in the first class cabin of AA0175 in a first class seat. A type of seat going extinct as they create room for more business class seats. It's always been a dream of ours to fly first class on a bed in the sky as we approach a faraway country, and now we're both living it. Stuffed with wine and the 100th anniversary beef wellington, I couldn't be happier.

As it turns out, these were all purchased by Madeline, as part of a wonderful planned surprise. A full year later, my surprise Oakwell Spa visit has been outdone.

I've always had these small pockets of the internet where I would choose to reside. I publish ideas in these corners but I never try too hard to make them seen by others. In the case of this blog, not worrying about who reads it has been very freeing. It's a kind of "social media" if you will where the "social" part is prioritized last. By being social last, I've always felt more comfortable being my full introspective self. Alas, this sense of comfort is false as I focus more on the technical details of my profession, and none of the personal details of my own life. This has been a personal flaw that I've slowly been correcting for the last 6 years.

I've been hesitant to post openly about being engaged because I didn't know where this fit. Of course, there are the normal socials, IG and Facebook. But should I write about it, what about my bluesky? To be fair, I never know what to post on bluesky.

As I reflect on an amazing wedding, and our wonderful relationship, in this surprise first class seat, it dawned on me that being married means sharing everything. In celebration of living the rest of our lives together, as we embark on what bodes to be a wonderful honeymoon (here's hoping your throat is getting better!), I wanted to welcome you, Madeline, to my little corner on the internet where I write about weird techy things and my life sometimes.

Back in 2021, event sourcing was a concept I had read about but never put into practice. I was looking for an opportunity to try it out and at kaizen.io I got my chance in the construction domain for an erosion control company.

My first event sourced system tried to test the boundaries of storage and time by storing all events in a single stream. Don't ever do this. At the time I thought the number of events for a single division would never be big enough for it to matter. The problem is if all the events are tangled together, then you have to read about year-old events to understand what's happening right now. Both fortunately, and unfortunately for me, this system still proved to be very useful, and I was stuck supporting this very awkward model.

I had thought for some time I was stuck in this reality, but after some deliberation (perhaps years of deliberation) I saw a way out. To understand the answer, I have to explain lifetimes. An event by itself can live on indefinitely, and that's fine. What may not live on is the thing that event happened to. A work order may have been completed a year ago, and it's separate from today's work order, so I don't need to look at both to understand today's work order. If I take this further, I may not care about year-old work orders altogether, and can safely delete or archive them away to some other form of persistence altogether, like a PDF of the final state sitting in cold storage.

A lifetime is the answer to the question, "how long do I want to keep this thing around?", or "how long is this relevant?" These are questions you should always be asking when you're choosing events. Before we can ask this question, another more important question needs to be asked. "What is this happening to?" Is it a work order, a cart, a residential subdivision? In the all-stream case, there was no "what", or perhaps the "what" could be the entire world, which is its biggest drawback. In truth, every event did have some kind of identifier associated with it, which was key in digging out of my hole.

Individual lots had identifiers, so I knew how to look up the material counts for particular addresses. These lots each have bids tied to them so that identifier is very important! Lots belong to a community which has an identifier. When a crew was assigned to visit that subdivision, that assignment had its own identifier.

I've had the fortune of learning from this mistake in future projects and created event models where every event has a distinct StreamId to identify the "what" it belongs to. In the examples I listed above, this "what" already gets tricky even if I had known this from the start. Domain-driven design has terminology for this, but I find it simpler to think of entities that can have children, and those children can have children.

My approach to modeling this relationship in the identifier is to simply make the id reflect it in a straightforward way. So if I wanted to know about lot 212 in community 2 for customer 12, then I would get all the events for community/12-2/lot/212. A nice little resourceful name. This gives us the benefit of being able to query the events for a specific lot, or all of those events for the subdivision. There are cases where we want to follow the lot, but we are also providing analytics at a community level, so it's important we can do both.

So from here, my solution finally reveals itself. I don't need to do a big migration or modify my event schema, or at least not the events directly. I simply need to add some metadata based on the event data that helps me identify the "what" for each event. I'm lucky those identifiers already exist. Here's how I do that:

return @event switch
{
    // Lot-related events
    LotServiced e => $"community/{e.CustomerId}-{e.CommunityId}/lot/{e.LotId}",
    InstallmentBilled e => $"community/{e.CustomerId}-{e.CommunityId}/lot/{e.LotId}",

    // Assignment-related events (use assignment ID as stream)
    CrewAssigned e => $"assignment/{e.AssignmentId}",
    CrewAssignmentRemoved e => $"assignment/{e.AssignmentId}",
    WorklogSubmitted e => $"assignment/{e.AssignmentId}",

    // Community-level events
    CrewDispatchedToCommunity e => $"community/{e.CustomerId}-{e.CommunityId}",

    // Purchase Order events (EPO is a type of purchase order, so they share the same stream)
    PurchaseOrderReceived e => $"purchase-order/{e.Id}",
    EpoCompleted e => $"purchase-order/{e.Id}",

    _ => throw new ArgumentException($"Unknown event type: {@event.GetType().Name}")
};

Using this to add a StreamId to new events, plus an additional batch update to existing events to include this new field was fairly straightforward. That is because nothing about the system changes aside from some extra storage. I still depend on reading the full history of events to build my views today, but this provides the mechanism to get away from that.

Even before adding new view builders that use the StreamId, this had a unique operational benefit. If I knew anything about a community that was having problems, it was easy for me to query all the events for a community. Beforehand, it was surprisingly difficult and often required me having to write a throwaway application just to see the events.

These events live in a Postgres database as a single table. It's straightforward to get all the events for a lot or an assignment, but what about a community? I do consider lot serviced to be events on the community and that is probably one of the most important use cases. It turns out a LIKE query here works very well given the predictable nature of our StreamId. By itself, a query like community/2-12/% can take seconds if there are over 2 million events in the table! Luckily, a cheap index brings this down to milliseconds.

CREATE INDEX idx_community_maintenance_events_stream_pattern
ON community_maintenance_events(stream_id varchar_pattern_ops);

This index treats the StreamId as a set of raw byte values. By doing this, it can use a b-tree lookup to find the exact range of values, or entities in this case, that fall between community/2-11/ and community/2-13/ rather than scanning the entire table and checking for every entry that matches the pattern.

I still depend on the all-stream today, but I have pulled pieces of functionality away from it that now leverage these "baby streams" and I'm much happier with how these re-writes are working. Maybe in the next year, I'll be done with the all-stream altogether.

What Vim is not

I think it's important to point out that nothing I'm going to write about here is going to sell nvim as this tool that made me magically more efficient. It could have made me a faster developer, but it also could have made me slower. Nothing here 10x'd my speed as a developer and I get just as giddy when I see VS Code open in the wild as I do nvim. You can use whatever editor or methodology to create software. This is about my personal experience with nvim and what I believe my motivations to be.

Any idle glance at programming content on YouTube is often very annoyingly stuffed with videos about developers 10x, 40x, 100x'ing some thing that I assume has to do with their productivity. At best, this means they are writing 10x the code, which != more efficient. Lines of code are a liability not an asset. There is no metric I know of to measure a software developer's speed, and I think that's also true for the people creating this kind of content.

Motivation

I have wanted to try out neovim for years, solely out of curiosity, and maybe even a little insecurity. I've only ever used vim a few times when on the server, and when occasionally committing a file. I've never tried it as an editor for writing code. Vim has a reputation as a tool that makes you fast, and I'll admit that I wanted to see if there was something to the hype.

I didn't get speed, but instead I got something else. A massive change to the way I write code and edit text, that shakes up what I've been doing for the last decade of programming. I could write the same function in nvim that I wrote a year prior and it would suddenly end up being so much more fun, simply because the interface I'm using to write the code is different. It makes coding feel as novel as it did when I first began web development back in late 2013. I acquired a dopamine hit that made writing code more enjoyable.

Transition

I started the move in August last year while waiting on a flight to Philly where I planned to work remote for that month. I wanted a break from my current side project and decided to run nvim. I went through :Tutor from beginning to end, then I went through it again and stopped at each chapter to try and apply each lesson in my own code. I took to trying to add features to my side project very slowly with the raw distribution, then began watching videos on how people customize vim. I found typecraft's channel to be really helpful here, and much of my current configuration borrows from some of the stuff he shows, namely how nvim and tmux can be configured to work together. I still use <leader>-r to cargo run my current bevy project.

In Philly while I was getting the hang of my own configuration, I chanced upon a meetup where Graham Vasquez was giving a presentation on how to use vim. Honestly it was perfectly timed because I was just getting the hang of my own personal configuration. The presentation was great, and I highly recommend it if you're in the area and he feels like giving it again!

I know there are distros out there that give you a nice pre-configured nvim experience, but I wanted to really think about how vim and modal editing could change the way I work. I was worried that using a distribution would get me too close to VS Code with vim motions, which is already achievable in VS Code.

I still try to be somewhat minimal in my configuration. I only recently added nvim-notify to address the idiosyncratic way that vim shows error messages. I don't do anything special with my status bar yet, but I have customized the status bar with tmux so I haven't had to worry about that.

That being said, if you're reading this and considering the transition, I would recommend looking at TJ DeVries's getting started guide which walks through using kickstart to get to where I got a little bit quicker.

How it feels and why that's important

Multi-modal editing is a joy. We're used to thinking the arrow keys are the only way to get around a text document, so it's easy to think the mouse is the best option to navigate a screen. When you're in "Normal" mode in vim, you can navigate using what are called vim motions. These allow you to navigate the document efficiently without your hands leaving the keyboard. Many have struggled to capture how this works, and the only way to really "get it" is to try it.

For me personally, as someone who has invested over 10 years of playing fighting games, it makes the editor feel like training mode in a game like Street Fighter 6 or Tekken 7. It's comforting to me to bring something in my professional life to a personal place of familiarity.

Example of motions I use commonly: 2f" to jump the end of an html attribute, from here I can hit hci" to replace the value of that attribute with whatever I want to type. If I have multiple attributes on the same line, I'll usually hit 2f" again and again until I get to the attribute. I can hit these characters fast, it's almost second nature to me at this point. It feels like in Tekken when doing a korean backdash to create space between me and my opponent.

dap, and more importantly, dat are great for cleaning up code by selecting continuous blocks of text. If you have a big commented out method you were trying to replace, dap will delete around the "paragraph". Paragraph in this case meaning several lines of text uninterrupted. dat will delete around an html/xml tag which includes the tag and its contents. cit will replace the content of an html tag.

Much like in fighting games which sometimes require practice to literally move around, I still struggle with navigating vertically in vim. I periodically look for better strategies than my own, which relies heavily on C-u/d to scroll up and down 50% of the file I'm viewing.

The movement in vim feels like a game now, and the dopamine hit from that is real.

A new git experience

Before nvim I used a combination of VS Code and Rider. I was an early adopter of VS Code. I enjoyed Sublime text, but the draw for me to use VS Code was the integrated git experience. At the time, being someone who went between Visual Studio and Sublime text, I wasn't a fan of managing git in the editor, often opting to use the command line. I never liked the experience that Visual Studio tried to offer. VS Code changed my mind, and became not only an editor, but my new interface into git.

One struggle I had with nvim was giving up this experience. It took me a few tries to find something that actually worked for me. I tried to get by with just git signs and git fugitive, which appears to be the most popular approach to git in nvim. These just weren't landing for me, and I can't say why exactly. There was another plugin out there called vgit, that worked okay, but had bugs and felt like a step back from VS Code. I tried lazygit, which was an impressive tool, but I struggled with the out of editor git experience. It's nice seeing a diff of something you forgot about or didn't expect, and being able to navigate directly to it in your code editor.

Enter Neogit. Neogit has become my go to tool for interacting with git. By default, it operates very similar to how VS Code does in showing you quickly what files have changed and what's staged. It's easy to open up a diff and navigate to the exact line, hit enter then be right in the file where you can make edits.

However, the killer Neogit feature for me is the documentation. It decrypts and teaches you the git command line almost automatically. Every time I hit c to commit, it presents me with a helpful list of options and keyboard shortcuts to activate them. It shows a list of keyboard shortcuts, as well as the command line equivalent of each shortcut. However, because it's navigated with the keyboard, it's not annoying. If I just want to commit, I can quickly hit cc without having to read the dialog. If I want to amend my last commit, then I can hit ca.

Because Neogit makes it easier to see what's possible, it has made rebasing and cleaning previous commits so simple that I do it much more often. I've tried experimenting with different git flows last year, including stacked diffs. Now if I'm working off a branch off of main, I'm far more comfortable going back to a previous commit and adding to it if I realize there was something I missed that I came to depend on in a later commit in that branch. As a result, my PRs are much easier to follow.

Helix is another modal editor out there that is designed to introduce common text objects out of the box that are more aligned with code syntax. So it's easier to use vim motions to navigate a function signature out of the box. I want to try it but I actually like Neogit so much that it's hard to imagine the transition.

Wrapping up

This turned out longer than I had planned, and there is probably way more that I can write. I'm not sure how to wrap this up. Learning vim has been fun, but it's also been useful even if it hasn't made me 10x faster at editing code. Creating my own nvim config from scratch has been a project of its own, which serves as a kind of practice of its own in making software. I'm in what may be a neverending process of building my own editor and finding what I like. I think the real value here is having another place to practice my craft.

So, here I am in 2026, writing my first "blog" post in about 9 years. It's fascinating how so much has happened in 9 years, but one thing that I still see is software engineers keeping personal sites with a blog. Blogging appears to still be in fashion.

Side note, and maybe a large part of what brought me here, is the domain name zachrburke.com. Sometime back in 2018 or 2019, a combination of an expired credit card and total lack of due diligence on my part lead to me losing this domain. I perhaps thought at the time that no one would want zachrburke.com so there was no hurry to renew it. I thought wrong. Someone decided to grab zachrburke.com and use it as a piece of disposable infrastructure to peddle unlicensed sports betting.

So I was delighted to find out this week that zachrburke.com was back up for sale. Although there might be a strong argument that I may not want it anymore. Time will tell.

Anyway, I had to do some work to bring this thing back to life.

Rather than waste time building a new blog "engine", I decided to just fix the rough edges of this one that I wrote 9 years ago. I really wanted to know how hard that would be. Given news of various compromised npm packages in 2025, with the Sha1-Hulud Supply Chain attack and the general churn of javascript libraries and frameworks that happens in the nodejs ecosystem (or should I say deno, or should I say bun?), I expected this to be kind of a pain.

So I wasn't shocked at all when running npm audit revealed over 100+ critical vulnerabilities. Fortunately, past me decided that I didn't actually need to use webpack to generate a static site. There were still references to it though. Deleting them, and updating the actual packages I used, like showdown and cheerio got me to 0 known vulnerabilities pretty quickly.

After that, I decided to clean up a bit. node has native typescript support now, so I converted everything to typescript, added a simple type for a post so I get better feedback when build.ts fails, and now we're golden. I'm keeping the tradition of having a very strange approach to a blogging "engine", that is essentially a handcrafted static site generator. I think it's fun and gives me a space to experiment with web standards.

In the past I think I used to try various product analytics tools so I know if people are reading. I'm trying Post Hog for a product I'm working on right now and it's pretty solid. In theory I could use Post Hog here, but I've decided that it's best to not obsess over whether or not people are actually reading anything here and instead to write for the sake of it. That will at least help with the likely fact that no one is finding this blog organically any time soon, given all the flags it has for illegal gambling on the world cup in Qatar in 2022.

So what next? I want to write some more, and I have some other ideas that I want to include on my site, like my collection of vinyls inspired by Andy Bell's music collection.

Some topics that I've had rattling around in my head that I want to get down, maybe somewhat rapidly so I can push down those dreaded posts from 2017..

• Switching to nvim last year and my thoughts so far (this post is being written in nvim).
• Covering some of the lessons learned in my year-and-a-half pickleball simulator project (Maybe even start a devlog to show progress as it happens).
• My on and off again relationship with journaling and obsidian.md
• Intersections between software engineering and construction.

Recently, I've found myself running an EC2 instance in a hybrid cloud environment, for software where the private and public IP of a machine matter and must remain static. This was a lift and shift effort, and we didn't want to lose the 99.9% uptime guaranteed from running inside of a data center. While EC2 offers 99.99% uptime, this is only the case when paired with other tools AWS offers, like EC2 Auto Recovery and AutoScale Groups.

In our case, we could have created single instances, in multiple availability zones, without the need of an autoscale group. The design of this application goes against the design of a typical AutoScale application, as the IP's, as well as the machine name, are very important.

So to avoid using an Autoscale group to guarantee HA, we looked at EC2 Auto Recovery as a simple answer to situations like Hardware, or OS failures within EC2.

The problem with EC2 Auto Recovery

Auto Recovery only triggers when AWS detects a hardware failure. There is no way to simulate this type of event, so there is no way to tell if auto recovery works, and if it will bring the instance back up in the state you want it.

Getting by with an AutoScale Group

So the next solution was to put our single instance inside of an autoscale group. The challenge here is that a Launch Configuration won't accept a network interface as a parameter. This makes sense, an autoscale group needs to be able to make n number of instances to match load. This means it would need a way to accept an unknown number of network interfaces in order to create a new EC2 instance.

To get around this, we added a command for cfn-init to attach an Elastic Network Interface (eni) to our newly created instance. This eni is created in a Cloudformation template along with the instance in the autoscale group. The template also creates an Elastic IP (eip) and attaches that to the eni.

To be on the safe side, we dismount the eni from any instance it might be attached to, then attach it.

This means that we now have two interfaces running on the instance. This can cause other problems if your software assumes there is only one network interface. Because we are running on Windows, to work around this, we set the interface priority to prioritize our newly attached interface over the default one that gets attached.

Set-NetIPInterface -InterfaceIndex 2 -InterfaceMetrix 30

With that, we can now terminate our instance and watch our autoscale group spin up a new instance, with it's private/public IP in tact.

Are you working on a single page application that needs to be embedded in an iframe? Did you have to give control of that iframe back to the parent because it too was a single page application?

You can use window.parent.postMessage to send messages up to any pages embedding your application. The parent page can subscribe to that message and take whatever action it needs to take after a user has completed something in your embedded application.

The nice thing about this is it makes our application more generic, meaning it won't need to change because a new client wants to consume it using an iframe!

Here's an example:

// framed code
window.parent.postMessage("finished!", '*');

// parent code
window.addEventListener('message', function(event) {

    // make sure the message is coming from where you expect!
    if (event.origin.includes('my-own.domain.com') {
        document.querySelector('iframe').remove();

        // do things now that the user is done
    }
});

Gotchas

First off, if you're in React, don't forget to keep track of your listener id so you can remove it when your component unmounts. If you don't do this, you run the risk of your message getting handled multiple times for each time your component mounts.

class MyFrame extends Component {
    constructor(props) {
        super(props);
        this.state.finished = false;
    }

    componentDidMount() {
        this.listenerId = window.addEventListener('message', (event) => {
            if (event.origin.includes('my-own.domain.com') {
                this.setState({ finished: true });

                // do things now that the user is done
            }
        }
    }

    componentWillUnmount() {
        window.removeEventListener(this.listenerId);
    }

    render() {
        return !this.state.finished ?
            <iframe src="https://my-own.domain.com/app" /> :
            <div />
    }
}

Secondly, if you want to hide the frame right after your message is published, you may see that your iframe has this flicker effect if it still has content inside of it. As the maintainer of the framed application, assuming you can't just get rid of the content, you can get around this problem by using css transitions.

.finished {
    animation: 400ms fade-in;
}

@keyframes fade-in {
    0% { opacity: 0%; }
    100% { opacity: 100%; }
}

This will actually cause the message to be published and processed first, and transition to come second. Meaning your client can hide your iframe before you get a chance to change state, eliminating the flicker.

I recently stumbled across this video of "someone" (would love to know more about the author of the video) live coding in common lisp. In about 15 minutes, he "codes" a song and visually outputs what notes are being played on the screen as he is writing. What impressed me is that he could do this without having to refresh or rebuild anything. At most, you will occassionally see him highlight a method and run it through a REPL.

This video piqued my interest in functional programming languages. In .NET, I've come to enjoy using lambda expressions and LINQ statements, which are a means to write functionally in C#. One thing I can't do in C# is start up a program and actively modify it while it's running. I decided to start sifting through the functional languages that were at my disposal.

Before doing that though, I wanted a concrete problem to solve. When someone asks me what to write when learning a new language, I say start with "Hello World." After pointing out they already thought of that, I suggest writing a twitter bot. Doing this allows you to see, in your new language of choice, how you would tackle http requests and some kind of algorithim depending on what you would have your twitter bot do. I decided that I wanted to write a twitter bot that would tweet something random every hour.

As Heroku tends to be my goto for this kind of project, I looked at what functional languages it supports without the need for any custom buildpacks. Clojure pops up on the list as the lone item in this category, so I decide to roll with that.

Like many other bots, I took inspiration from horse_ebooks and named my bot zach_bebooks. I wound up using the twitter-api library by Adam Wynne. My original plan was to hit the twitter api manually using clj-http. However, learning the payloads that return from twitter, as well as figuring out how to generate an oauth signature and how to insert and parse JSON for a rest request/response proved to be a lot to learn alongside a new language.

I let heroku take care of the scheduling by using the Heroku Scheduler. Borrowing some logic from Diego Basch's blog, I was able to do a crude Markov Chain implementation, allowing zach_bebooks to speak.

For the random sentence generation to work, I needed data. I created a makeshift persistence engine by storing the data used to generate markov chains in an atom. I actually loaded the data that is used now by running the program inside a repl and calling learn-files on directories loaded with text files.

The full source code for zach_bebooks can be found here.

I'm happy to say I think I achieved my goal of writing a twitter bot without having to hack anything (with the exception of learn-files where I return "Complete" to keep all the newly learned data from getting dumped to the REPL). It surprised me how difficult it was to write functionally without an imperative crutch. Concepts like appending to a list during a loop took what felt like an eternity to grasp because I'm now working with immutable data structures.

(defn gen-sentence
[]
  (let [corpus (deref corpus/data)]
    (loop [phrase [] word (start-chain corpus) n 0]
       (if (> n phrase-length)
          (clojure.string/join " " phrase)
       (let [next-word (get-next-word corpus word)]
          (recur (conj phrase next-word) next-word (inc n)))))))

This is the function zach_bebooks uses to speak. It gets the data (data being a persistent hash map of words and follow-ups to those words) from an atom (corpus/data). If we pass the length of our phrase, 20 words in this case, then it packs together the vector phrase into a string and returns that. Otherwise, it "calls" the loop again with a newly created vector that is a combination of the old vector and the recently selected word.

One thing about clojure in particular is that it takes awhile for the REPL to start. Despite the time it takes a REPL to start, the ability to reload code in a REPL session let me keep a single REPL going for a real long time. After getting past some of the nuances of Clojure, it didn't take long to feel the realization that code is data (I say this but I didn't use any macros :)).

For far too long my sitemap has been served as a static xml file that I update every time I write a new post. I'm forgetful, and I don't want any new articles to be missed by google, so it's a good idea to build up the sitemap when it's requested based on the content I've written so far.

Lapis makes serving up xml requests really easy with it's @html builder. The @html builder isn't limited to creating only html elements, so it can be used to generate any arbitrary xml element. Just change the Content-Type of your request to return xml and serve the rest of your request like normal. Here is what my sitemap action looks like:

[sitemap: "/sitemap.xml"]: =>
    postList = articleRepo.getPostList!

    @res.headers["Content-Type"] = "application/xml"
    layout: false, @html ->
        urlset { 
            xmlns: 'http://www.sitemaps.org/schemas/sitemap/0.9'
            ['xmlns:xsi']: 'http://www.w3.org/2001/XMLSchema-instance'
            ['xsi:schemaLocation']: [[http://www.sitemaps.org/schemas/sitemap/0.9
                http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd]]
        }, ->

            for i, post in ipairs postList
                url ->
                    loc "http://throw-up.com/#{post.slug}"

            url ->
                loc "http://throw-up.com/me"
            url ->
                loc "http://throw-up.com/me/portfolio"

I also want to make sure that /sitemap.xml always serves the sitemap and doesn't get mistaken for any other routes. To do that, rather than depend on lapis to find the route, I'm going to offload that responsibility onto nginx.

location /sitemap.xml {
    default_type application/xml;
    content_by_lua_file "applications/sitemap.lua";
}

So rather than looking at web.moon where the other applications are, I have /sitemap.xml look at a seperate application that only gets served when nginx receives that uri. I just have to tell sitemap.lua to serve itself.

lapis.serve class SiteMap extends lapis.Application 

    [sitemap: "/sitemap.xml"]: =>
    -- ..

That's it, we're done!

Like many programmers over the past two weeks, I have been experimenting with Apple's newly announced Swift Programming language. I've been working (slowly) on porting my recent ludum dare entry "Dig'em" over to the new language as an iOS application.

In doing this I have been learning how to use Apple's Sprite Kit game libarary. Last night I started looking at how Sprite Kit handles collision detection and found the SKPhysicsContactDelegate protocol. You can conform to this protocal by implementing two methods didBeginContact and didEndContact which will get fired for every collision that happens between two SKNodes in your scene. Here is an example:

class GameScene: SKScene, SKPhysicsContactDelegate {
    init() {
        super.init()
        self.physicsWorld.contactDelegate = self
    }
    func didBeginContact(contact: SKPhysicsContact) {
        // check the contact.bodyA and contact.bodyB and see if you need to do something
    }
}

This way, you then check the nodes that are stored in the contact object to see if you need to do any particular processing for a certain type of collision. For instance, you can kill your hero if he/she collided with a lava object. Because there are so many varieties of collision that can occur in a more than trivial game, I wanted a way for an SKNode to be able to keep track of it's own collision logic, rather than store all of that in one method with a potentially high amount of branching logic. However, I didn't want to subclass SKNode and downcast from the delegate method, because that meant creating an extra layer between me and Sprite Kit just to do custom collision logic.

Swift offers the ability to extend existing objects with new methods or variables. What's cool is in extending these objects, you can also add new protocols (swift's equivalent of an interface), effectively giving existing objects new types to conform to. I am able to offload collision detection logic to the SKNode with the following code:

@objc protocol Collidable {
    @optional func onContact(contact: SKPhysicsContact)
    @optional func onEndContact(contact: SKPhysicsContact)
}

extension SKNode : Collidable {
    func distanceTo(point: CGPoint) -> CGFloat {
        return hypotf(point.x - self.position.x, point.y - self.position.y);
    }
}

Here is where things get interesting. By making the methods in the Collidable protocal optional, the methods onContact and onEndContact aren't guranteed to exist. Swift allows you to call these optional methods by appending a ? to the end of a call to indicate the method might not be there. Here is how my didContactBegin method looks now:

func didBeginContact(contact: SKPhysicsContact) {
    let bodyA = contact.bodyA.node as Collidable
    bodyA.onContact?(contact)
}    

Now for any collisions that occur, the contact delegate will simply try to call onContact on the first node listed in the collision, and do nothing if the method is not there. I can implement custom collision logic in my nodes by doing the following:

class HeroNode : SKNode {
    init() {
        super.init()
    }
    func onContact(contact: SKPhysicsContact) {
        // do custom collision logic here
    }
}

I was a little dissapointed that I had to cast the node to a Collidable before the onContact method was recognized, but I am pleased overall with what I was able to accomplish.

Being able to extend existing classes with new protocols is a cool idea and I am interested to see how other developers use this feature in the future.

Lua was intended to be used as an embedded language. It's gotten a lot of use in games like garry's mod and in the World of Warcraft in add-on api. For the sake of demonstration I wrote a small game in .NET using MonoGame that allows you to manipulate certain aspects of the game through lua code. The game itself is a very simple simulation of gravity being applied to a ball tossed into the air.

The above screenshot is how the game would look without writing any lua. The game exposes a lua api that allows you to modify behaviour in the simulation by writing lua code. With the appropriate lua script, we can get the following:

This is a achieved with the following lua code

local color = { r = 0, g = 100, b = 100 }
local trajectory = { x = 0, y = 0 }

function incrementor(start, inc)
    local value = start

    return function()
        value = value + inc
        return value
    end
end

local theta = incrementor(0, 0.50)

function Run (ticks)
    ChangeTrajectory(trajectory.x, trajectory.y)
    trajectory.y = math.sin(theta())
end

SetClearColor(color.r, color.g, color.b)
SetBallColor(255, 255, 255)

The methods SetClearColor, SetBallColor and ChangeTrajectory are actually implemented in .NET and are being called in lua. The Run() method is being kept after running the lua script then called every frame. I am using a .NET library called DynamicLua to achieve this, However I would recommend looking into NLua for more involved projects. Here is the code used to actually embed the lua script shown above.

public ClientAPI(string scriptPath)
{
    ClearColor = Color.SkyBlue;
    BallColor = Color.White;
    Trajectory = Vector2.Zero;

    _lua = new DynamicLua.DynamicLua();
    _lua.SetBallColor = new Action<double, double, double>(SetBallColor);
    _lua.SetClearColor = new Action<double, double, double>(SetClearcolor);
    _lua.ChangeTrajectory = new Action<double, double>(ChangeTrajectory);

    _lua.DoFile(scriptPath);
}

private void SetBallColor(double red, double green, double blue)
{
    BallColor = new Color((int)red, (int)green, (int)blue);
}

private void SetClearcolor(double red, double green, double blue)
{
    ClearColor = new Color((int)red, (int)green, (int)blue);
}

private void ChangeTrajectory(double x, double y)
{
    Trajectory = new Vector2((float) x, (float) y);
}

public void Run(double ticks)
{
    if (_lua.Run != null)
        _lua.Run(ticks);
}

DynamicLua provides a dynamic object that you can assign methods to. Doing this will expose those methods in your lua context, so when DoFile is run, those functions will be available to the script passed to that method. Any methods or variables stored globally in the lua script are also stored in the dynamic after the file has been ran. This makes it possible to run methods that are implemented in lua, like the Run method.

You can view the full source on github here

About a few months ago I read this article by Sarah Mei that flags some possible issues with using MongoDB as a data store for a social networking application. The bulk of the article talks about using MongoDB as an approach to store activity streams such as those found on the news feed for your facebook account. It then talks about falling back to PostGreSQL, which was also not exactly optimal for solving the problem either.

This got me thinking, why is it that after so long we are only now considering something other than SQL storage for our production applications. Why is the only alternative to SQL storage a document database? Here is a quote from that article that really struck me:

For quite a few years now, the received wisdom has been that social data is not relational, and that if you store it in a relational database, you're doing it wrong.

But what are the alternatives? Some folks say graph databases are more natural, but I'm not going to cover those here, since graph databases are too niche to be put into production

This is interesting, because a graph database strikes me as a perfect model for a social network. I am betting that the growing popularity of Facebook and social networking was what spawned the idea of a graph database. So why not use that? The funny thing is that if you went into most software shops and proposed something like neo4j then you would have to explain why you shouldn't solve your graphing problem with a SQL database.

What I don't understand is why developers can only get comfortable with the idea of a SQL or document database and why those are the only two popular ideas. There are countless ways to deliver application code. For example, a simple application to serve web requests can be done easily in so many languages now.

Since Facebook is on my brain right now, I'll give another example about them. Hip Hop Virtual Machine is a VM capabile of jit compiling PHP for better performance. On top of that, they also invented the Hack programming language which adds strong typing to PHP. They would rather have invented a way to compile PHP into C++ than move to another programming language, then invented a new language on top of that.

Another example is the web framework that powers this blog. Lapis was written by Leaf Corcoran so that he could write itch.io using Moonscript, which was also a language he himself wrote.

Why does this never seem to happen with database technology? I have seen some technologies like ActorDB, which seeks to make a SQL database that is horizontally scalable and compatible with existing MySQL drivers. There is also RethinkDB which builds off a lot of MongoDB's ideas but adds things like joins and a nice admin UI.

Those are cool, but to me it's just more of the same. You are forced to choose between a strict schema that maps to a flat table, or a big unorganized glob of data. I would like to see developers consider other ways to represent their data, such as the graphing database, or if the problem is something new, then coming up with something new to tackle the problem rather than shoehorning that data into anothe relational database.

For the past few weeks I have been making changes to the look and feel of throw-up. The changes boil down to

• Upgrading HighlightJS
• Squashing the side articles bar
• Switching out Disqus with Moot for handling comments

HighlightJS

In my last post about Guard, I mentioned that I turned off HighlightJS because I was having issues getting it to detect the right language for a code block, and because I had a ruby snippet to show but didn't initially include ruby with my packed highlightjs file. At the time I decided it was easier to just drop it instead of rebuild it with the ruby language included.

The decision to pick a small set of languages wasn't to reduce page weight, although that is a qualifying factor. It was to reduce the probability that the wrong language would be detected on a page where I refer to code. With their 0.80 release, they fix this problem by allowing you to specify what languages highlightjs should look for before having it auto highlight anything. Now, in my post list I specify the programming languages to be expected in a blog post, like so:

return {
{
    Title: "Makin' changes, switchin' to Moot"
    Slug: "some-changes"
    FileName: "some-changes.md"
    PubDate: "January 25, 2014"
    Languages: { 'coffeescript', 'js' }
}
--... more code

I then initialize HighlightJS like this:

if @Post.Languages
    script src: '/content/js/highlight.pack.js'
    script -> 
        raw "var languages = #{util.to_json(@Post.Languages)};\n"
        raw [[
        hljs.configure({
            languages: languages
        });
        hljs.initHighlightingOnLoad();
    ]]

It's worthwhile to note the Languages attribute is optional, if it doesn't exist I don't even request HLJS which saves me about 8-10ms in page load time.

Squashing the Archive

I decided to move the archive to the bottom of the page because I don't have that many posts yet. So I could no longer justify using up 20% of the width of the screen when a long post like this one would mean leaving a huge gap of empty space beside the main content. Afterall, it's the content that people care about, or so I hope.

Switching out Disqus with Moot

This is probably the most signifigant change. Comments haven't really brought any value to throw-up yet, but I didn't want to remove the option to leave a comment. However, Disqus weighs a lot to keep around just in case someone wants to leave a comment, so I decided to try out Moot instead.

Moot is a forum and commenting engine that leverages Redis as a primary datastore. That last fact is interesting because Redis lives in memory, so to use it in lieu of a database might actually frighten some people. this post here details the pains they went through to make the Redis datastore a reality and may calm some fears of trusting a memory store to persist data. It's also a worthy read for anyone considering using Redis at all, even for a caching layer.

Because of their storage strategy, they boast 2ms load speeds when under load. Meaning I can have my comments without as much weight. Unfortanetly this means you have to use a moot or facebook account to leave any comments. One cool thing is when you register with moot is that you get a forum by default. So if this takes off, adding a forum to capture the discussion that happens on the site would be trivial.

Other small changes

I addded some share buttons to the top of the blog post in hopes to improve traffic. I didn't like how my posts looked on facebook without an image so I decided to add a little logo. It was surprisingly easy to find a non-offensive image depicting someone throwing up.

That's it! Maybe one day I'll write about code not related to throw-up. :P

Today I was bored so I decided to do some cleaning up on throw-up. A few things have bothered me since I started coding with the lapis/openresty stack. First is that nginx likes to create several temp directories at the location I run, which is where my code is. That generates about 4 directories of noise in my code base. The other thing is that I would compile my moonscript files right where they were, so anytime I glance at my codebase I would see two versions of every .moon file which made a blog that is almost no code seem like a big project.

Using moonc -t, I was able to kill two birds with one stone. the -t flag tells moonc to place compiled lua files in directory of choice. I decided to create a bin directory that rests at the root level of my code and put the compiled lua files in there. I wrote a small shellscript to copy over the content, mime types and nginx.conf file as well so I could run the lapis server in the bin directory instead of the root directory of my code. Now those temp directories only exist in the bin directory where I don't have to look at them to navigate code.

In hindsight, I should have taken a before and after screenshot, but overall I feel like my code is a lot slimmer now, even though it was technically always slim.

Replacing LiveReload with guard (but keeping live-reload)

One thing I was dissapointed by when first picking up Lapis was that I couldn't use tup to watch and build my moonscript files into lua. Fortunately I found LiveReload, which not only watched my file system for changes, but also refreshes Chrome for me whenever there were changes.

This is nice, but one problem is I now have another thing to look at for troubleshooting. There have been brief spurts where I had a compilation problem that I would glance over for several minutes because I kept forgetting to check my LiveReload log.

I use iTerm as my terminal emulator on OSX and I already have trained myself to look at that frequently when I encounter bugs. Plus, it has a nifty split pane ability to give me multiple feeds of data I can easily see at one time. Wouldn't it be nice if I could pipe the live reload output to iTerm and have all my logging go to one place?

That is where Guard comes in. Guard is a command line tool designed to handle file system events. Using ruby, you can write a Guardfile that defines how those events get handled. There is a live reload plugin available for guard that allows you to refresh your browser in response to those events.

Now I can run that in iTerm and have my build output right beside my server output. Here is what my Guardfile looks like:

filter /bin/

guard 'livereload' do
    watch(%r{bin/views/.+})
    watch(%r{bin/content/.+\.(css|js|html|md)})
    watch(%r{bin/web.lua})
    watch(%r{bin/models/.+})
end

watch(%r{.+}) { `sh build.cmd` }

Also, this is all free. Shame I already purchased LiveReload. Also, as far as I can tell it's cross-platform, so this may work on Windows. Having tried .NET Demon at work, I was dissapointed that it wouldn't refresh the browser after changing .cshtml files. This might be a nice alternative to get past that.

One other thing

I'm turning off highlightjs for now. Half my code is moonscript which isn't supported. I also never thought I would post up Ruby code so it wasn't included when generating the script file. I need to rethink how I'm going to post code on the site.

Christmas is coming up so I went ahead and got myself (and some family) a Kindle Fire HD 7" tablet. While playing around with the Kindle, I thought I would pull throw-up on the Silk browser. I noticed two things:

• I was crazy to show the sidebar in portait mode on a 7" tablet. The text gets way too tall.

but more importantly:

• there is a "reading view" that shows only the content from my blog post.

I was surprised to see this appear on my site and to see it work and work well. As it turns out, it's just grabbing the article tags on my page and displaying them in the order they appear on the page (and maybe doing some other things. I didn't thoroughly research how it worked).

It was cool to see that happen without me really having to do anything, besides make what is considered a good design choice according to w3:

An article should make sense on its own and it should be possible to distribute it independently from the rest of the site.

I would be lying if I said I did that from the beginning. I actually made some slight view changes so that the disqus widget wasn't rendered with the article as I wrote this. Now my reading view is pristine on Silk.

The other day I had an idea for a website that would basically be a CRUD application where the data store is a search engine. I wondered how I would do this while still being able to write a web application using the Moonscript/Lapis stack.

For my search engine, I chose Apache Solr. Namely because I have had a little experience with it already and I think it is a fascinating technology that I would like to learn more about.

One problem is that there are no well known tested client libraries for solr that are written in lua/moonscript. I did find a couple of sample solutions out on Github but they have both gone untouched for three years which doesn't bid well considering I'm trying to use an up to date version of Solr.

Then I had the realization that I don't need someone to write a client library for me. Solr primarily talks using REST over endpoints that you can configure. So now my quest shifted from looking for a solr client to a rest client for lua.

My search lead me to SPORE. With SPORE, you write what's called a spec file using JSON to describe a REST API. From there, your SPORE client takes that spec file and converts it into high level methods for your programming environment.

So I can describe my Solr API like so:

{
  "methods": {
    "select": {
      "path": "/select",
      "method": "GET",
      "required_params": [
        "q",
        "wt"
      ]
    },
    "update": {
      "path": "/update/:format",
      "method": "POST",
      "required_params": [
        "format"
      ],
      "required_payload": true
    }
  }
}

Here is how to use this in Lua. (I would have shown it in moonscript but the highlighter kept thinking this sample was SQL)

local Spore = require('Spore')

local solr = Spore.new_from_spec('solr-spec.json', {
  base_url = 'http://domain.com/solr/collection'
})
solr:enable('Format.JSON')

local result = solr:select({ q = '*:*', wt = 'json' })
print(result.body.response.docs[1].id)

local docs = { { id = '123', title = 'stuff' },
               { id = 'whatever', some_string_s = 'more_stuff' } }
result = solr:update({ format = "json", payload = docs })
print(result.body.responseHeader.QTime)

result = solr:update({ format = "json", payload = { commit = {} } })

And there we are! A mostly functioning solr integration with less than 50 lines of code, and without all the noise that usually comes from making an http request in code. If that commit method is a little too wordy you can always add another method in the spec file that uses solr's shortcut commit url.

Now, is this too magical? The fact is, I am taking it on faith that the methods I am getting back from SPORE simply wrap an http request with data I give it. If that's the case, then I'm fine with it, and maybe I will dig into the lua-spore client sometime to see if that's the case. Even if it's not the case, SPORE is just the specification not the client (although this client is by the same person who came up with that specification).

I could in theory write my own spore client. That may be worthwhile someday as I'm sure there are some optimizations that can be made to complement Openresty's non-blocking io functionality that I have yet to read about :P

Sometimes, I insist on being different, and sometimes that can come back to bite me. Writing the code for throw-up was a fun educational journey into front-end design and the lua scripting language. Deployment on the other hand, was educational in a much more painful way.

I decided to go with heroku since a lot of the work for that had been done for me. While Heroku doesn't natively support lua, there is the handy dandy lua build kit. To give Heroku openresty support, there is this luarock which makes me wonder if I can't just install openresty using luarocks on my own machine.

In order to make heroku aware of your projects dependencies on other lua libraries, the lua build kit looks in your project for a .rockspec file. Mine looks like this

dependencies = {
  "https://raw.github.com/leafo/heroku-openresty/master/heroku-openresty-dev-1.rockspec",
  "https://raw.github.com/jtarchie/underscore-lua/master/underscore-dev-1.rockspec",
  "https://raw.github.com/leafo/lapis-console/master/lapis_console-dev-1.rockspec",
  "https://raw.github.com/zach-binary/LuaHTML/master/luahtml-1.1.1-1.rockspec",
  "lua-discount",
  "moonscript",
  "lapis",
}

This is similar to node where you would define your dependencies in a package.json file for npm to go grab when you deploy. The process isn't perfect. I found when working with luahtml that it wasn't getting retrieved because it's rockspec file specified a release branch. The build kit didn't like that, so I had to fork the luahtml repo and modify it's rockspec file in order to make it work.

Next thing I wanted to do was define an nginx configuration to use in a production environment. Lapis makes this easy, you can define all your config values in a config.moon/lua file at the top level of your project, like so:

config 'production', ->
  port os.getenv "PORT"
  num_workers 4
  code_cache 'on'

  blogFilePath 'content/blog/'

Again, this is just moonscript that gets interpreted into a lua table, so if you want you can nest objects as configuration values. The code_cache tells nginx, I believe, to store an execution plan / build your lua server files in order to improve performance.

Finally, there was the Procfile to tell heroku how to start your server. Here's what mine looked like originally.

web: lapis server production

So now I'm ready to deploy my site! I commit my changes, do a git push heroku master, and everything seems to get copied correctly. Except for the fact that my site is throwing 500's. What did I miss?

After about 3 hours of cursing heroku and punching empty shoe boxes I found that I forgot to tell heroku to compile my moon files into lua files. Now I've opened up the troubles of getting heroku to do specific things before running your site.

The only "clean" solution I found for this was to make a custom buildpack. That seemed like a lot of work considering I just wanted to do a moonc before starting the server. Not to mention that heroku only allows you to have one buildpack at a time, and I still need the lua buildpack. You can bypass this using a special buildpack that is designed to load other buildpacks, but that adds even more excess to an already excessive solution.

Finally I just added it to the Procfile.

web: moonc .; moonc views/; moonc models; lapis server production

Not the prettiest solution, but it works.

Keeping Heroku dynos alive

I only need one dyno for this blog right now. The problem with this is that when you only have one dyno, it gets put to sleep after a hour of inactivity. Sleep meaning whoever loads the site when the dyno is asleep has to put up with a long page load.

To get around that, I followed the steps in this blog post and created a scheduled task to ping my site every hour. No more slacking dynos.

Conclusion

This concludes the exciting trilogy of posts about making a blog in Lapis. Here's a quick list of the pros and cons I found

pros:

• speed: openresty is fast. This is one of the key reasons I wanted to try it out. Running httperf with 1000 sequential connections on my macbook pro retina against the building-openresty page yielded a rate of 0.8 ms per request. That's sub millisecond to send an http request, parse markdown and send that markdown back. That seems fast anyway, I'll need a better way to compare metrics to other frameworks.
• developer experience: moonscript was designed so you can write clean code. It takes a little getting used too, and there was a point where I lost time due to an indentation mistake. However, I haven't really had to struggle understanding my own code. It's easy to keep files small and the lack of needed brackets cuts down on a lot of typing and makes writing code flow real quickly. Sure you have a build step but I quickly forgot about it once I started using live reload (which admittedly did bite me in deployment)

cons

• no repl/debugger: this is pretty self explanatory.
• deployment: Per this post, there are some improvements that can be made here. Having nginx interperet moon files directly is a todo for the lapis project, and would be a huge deal sealer for me and probably many other developers.

Some things I may tackle next are writing tests using busted to check my posts for spelling errors and broken links.

This has been exciting. In my freetime for the past 5-6 days I have been working furiously on this blog. I've decided that I need three posts to accurately sum up what has been an englightening project for me. This post I'll write about the actual implementation of throw-up.

Yes, you heard me correctly, throw-up. I thought the name was so clever I bought the domain sometime in late 2012-early 2013. I thought I would dedicate it to the don'ts of the programming world. My own version of the daily wtf.

My requirements were simple. I liked the idea of writing posts in markdown. I didn't want to bother with a database since I don't think I will write that much. Also, since Kijana claimed he was able to load his page in under 50ms before adding disqus, I wanted to be faster than that.

Somewhere in working on this I decided I wanted to have syntactical highlighting since I would primarily talk about code. In the end, here are the front-end tools I ended up using.

Typelate for typography.
Highlight.JS for syntax highlighting.
Socialicious for social media icons.
also Disqus of course because they freakin' sweet.

As for CSS frameworks, I opted out of those (with the exception of typelate). I realized that when I look at frameworks like bootstrap I really just want a grid and I don't care about or need the rest of the stuff. I looked around for a standalone css grid then eventually rolled my own after reading this post about grids by Chris Coyier. I like how my design is less "poppy" than a default twitter bootstrap build would get you.

One problem with writing posts in markdown is it's a challenge to apply syntax highlighting. Highlight JS solves this by looking at any code blocks in a document and using a heuristic to guess what kind language the code is in. This does mean it can be wrong. It also doesn't support moonscript so I had to try and trick it into thinking code blocks on this page were coffeescript.

I tried Font Awesome at first for icon support, but I don't think nginx liked it. Rather than look into the issue I looked for another solution. Socialicious was better for me since I really just wanted social media icons, and Socialicious is much smaller than font awesome so less page weight.

Learning Lapis

Lapis and moonscript held up pretty well considering they are both under two years old (Lapis being less than a year old itself). Since moonscript compiles into lua, you get access to any existing lua library, and I was surprised to see there are tons of useful lua libraries if you are building a website. For markdown parsing, there was lua-discount. For templating there is luahtml. I originally wanted to use etlua but it won't work with lapis just yet

One thing that concerned me about using Lapis was lack of robustness when dealing with lists/tables of information. lua doesn't have a lot of built in support for tables, so doing something like getting the size of a table involves writing a function to iterate through the table and count how many elements are contained in it. Fortunately, there exists underscore-lua, a 1-to-1 port of underscorejs to lua. This pretty much grants us functionaltiy similar to Microsoft LINQ. So it's possible to write code like this (last example from underscore documentation):

local stooges = {{name='curly', age=25}, {name='moe', age=21}, {name='larry', age=23}}
local youngest = _.chain(stooges)
  :sortBy(function(stooge) return stooge.age end)
  :map(function(stooge) return stooge.name .. ' is ' .. stooge.age end)
  :first()
  :value()
=> "moe is 21"

Lapis has it's own idea of how to create a view which I'm sure some of you will find a bit wacky. Here is a snippet of the code used in my layout

content: =>
    html_5 ->

      head -> 
        link rel: "icon", href: '/content/images/barf.ico'
        title if @Title then @Title else 'throw up;'

      body -> 
        header ->
          hgroup ->
            div ->
              small "var up = new Exception();"
              h3  "throw up;"

          section ->
             ul ->
              li ->
                a href: 'http://twitter.com/zach_no_beard', target: '_blank', ->
                  i class: 'icon-twitter'
              li ->
                a href: 'https://github.com/zach-binary', target: '_blank', ->
                  i class: 'icon-github'
              li ->
                a href: 'http://ren.itch.io', target: '_blank', ->
                  small 'itch'

So what is this? Well, this is moonscript. What we have here is a very clever use of moonscript syntax. I have a view called Index, and in that view I have a content method which defines a template for my view. From there you can call just about any method you want, and if that method name isn't defined somewhere then it will be reflected into an html element. The first parameter can be a table defining any number of attributes you want attached to that element. You can pass in a callback that will generate output to be nested in that element, or for brevity, you can pass in a single value if you only want a small amount of content to be stored in that element. The result is a templating language that resembles Jade

This is an interesting approach since most people would hand you a view and say "it's just data", but here I'm handing you a view and I'm saying "it's just code." At the same time, I can see how this approach could be very powerful, yet it's clean and understandable. It may be considered overkill for view generation though.

If this approach is too magical, then you can always introduce a templating engine. Here I use a template to render the disqus widget because dumping the html for that in my moonscript views looked pretty ugly to me.

content: =>
    article ->
      section ->

        if @Post
          small 'posted sometime around ' .. @Post.PubDate 

        unless @errors
          raw @PostBody
          @RenderDisqus!
        else 
          raw @errors

RenderDisqus: => 
  status, error = pcall ->
    raw luahtml.open('templates/disqus.html', { slug: @Post.Slug })

The full code is up on github. I'm happy to say I was able to hit my page load goal of under 50ms. The building openresty page clocks in between 20-25ms pre-disqus when running with production settings on my local machine.

I would like to note that Lapis has a pretty slick looking integration with PostGres SQL. I may consider changing my storage approach later to leverage that.

Life without a debugger

Moonscript is still a new language and as a result, advanced features like a repl have not been implemented yet. As a result, that means there is no way (that I know of anyway) to step through code using a debugger.

Lapis attempts to combat this with a web console you can route to from your lapis application. One thing you get from this is the ability to unfold and see what is in your tables, which the lua/moonscript console doesn't do.

Still, I found it easier to add a debug directory to my project and populate that with scripts when any form of advanced investigation of my objects was necessary. This way I can write code with Sublime. I would prefer a debugger much more though ;-)

My next post I'll write about deployment.

A few weeks ago I read this blog post by Kijana Woodard, which inspired me to create my own blog. This gives me an opportunity to touch on a number of technologies I've been meaning to checkout. Namely, Openresty and Lapis, a web framework that leverages moonscript.

I am going to break this out over two posts since I wanted cover the installation of openresty seperate from the rest of the blog implementation. It should be noted that I did this development on a Mac machine, and I am not sure how I would setup openresty on a windows box just yet.

So I went to the openresty website and faithfully followed their step by step instructions. I downloaded the latest version which at this time of writing in 1.4.2.9.

PCRE is a prerequisite for Mac users so I started by running this:

brew install pcre

Then I moved to an appropriate development folder and untarred the build files.

tar -xvf ngx_openresty-1.4.2.9
cd ngx_openresty-1.4.2.9

Next I had to configure the build. Since PCRE was a prereq for me because I'm on a mac, I had to specify where it could find that using the --with-ld-opt and --with-cc-opt arguments.

./configure  --with-luajit --with-http_postgres_module --with-cc-opt="-I/usr/local/include" --with-ld-opt="-L/usr/local/lib"

I also told it to include the postgres http module because that is recommended for Lapis, although I have no intention of using a database for this project. Luajit should just about always be added because it improves performance.

With that, all that was left was to make and install it.

make
make install

I did attempt to do this without PCRE only to run into an error in the last step. Once I installed that everything built smoothly.

With that I went ahead and installed lapis, which was pretty easy.

luarocks install --server=http://rocks.moonscript.org/manifests/leafo lapis`  

Created a new site using lapis new then tested it with lapis server after building the example web.moon. Everything is green so far!