Skip to main content

Mike Kreuzer

Built with Zine

February 19, 2017

Pay dirt: with this post I've pushed Zine into production use today, this blog now proudly carries a 'Built with Zine' tag.

Zine is the Ruby static site generator I kicked off my attempt at the 100 days of Code challenge with, and while on Day 27 there are still a whole lot of things to do & to fix – not least of which is writing some damn tests – despite all of that, the engine I'm using now doesn't have any tests either, so… it's time.

A little shy of two weeks on from my last blog post, the major changes to Zine involve adding file watching and incremental builds, and automating the resulting file uploads. Previously I'd rebuilt the whole blog each time, then manually uploaded the files I knew would have changed via Coda or Transmit. RSS, Sass, a tag pages index, and a bunch of other features were added too, but incremental builds & automated uploads are going to be big timesavers for me.

The Ruby gem & Github repo are up to date, and you can follow my progress here on the blog, as well as read my daily progress log & tweets.

Two weeks of code

February 7, 2017

I'm two weeks into my hundred days of code & yesterday I produced my first tangible output: publishing Zine as a gem, and pushing the code up on Github. I feel pretty chuffed to have finally published a Ruby gem. Fifteen years from the pickaxe book to a gem, there's hope for us all.

Zine as it says on the pack is yet another blog aware static site generator. I already have one of these things that I wrote two years ago, the thing I'm using right now, and there are literally hundreds of competitors, so apart from the satisfaction of having a gem to my name it's probably worth thinking about what I'm aiming to get.

So far what I've got may seem small, some layout changes: jump to content, links to Ripley & to GitHub; and an index for the tag pages (I've wanted that for the longest time). All will be visible on this site, soon, it's close to ready for production, but not quite there yet. What I will gain though is far greater, it's a tool completely optimised for me.
 
The frustrations in going back to Ruby have been few, but they're there - the decrepitude of some parts of the Ruby standard library/core (eg RSS, & WEBrick), the complexity involved in async/threading, things just taken for granted in other languages, and lastly some of my own habits which seem to come out more in Ruby than other languages…
 
One of the things I wanted out of this was code that would be easier to change & maintain, to get that I need to prune the data that's being passed around & decouple things a bit, and then seriously take to each & every file with reek & rspec. I've been in the habit forever of working in sprints - charging ahead with code for a week or two, then backfilling with architecture, docs & tests, a sort of "it's probably green, let's hope so/green & refactor" cycle, rather than "red/green/refactor". That's worked out ok, but the code in the first two weeks can be a bit gnarly.

Onwards any way, tests up next. Really pretty happy I committed to this thing.

100 days of code

January 24, 2017

Each year for the last few years I've undertaken what I've come to call my January project, with the aim of doing something new & different.

This year my January project's going to roll on for three months - I'm going to take part in Alexander Kallaway's 100 days of code challenge. A little late to start for a New Year's resolution, but better late than never. 100 nights of continuous coding that you can see the progress of in a couple of spots:

The theme for my hundred days is going to be consolidation: I'm going to take a few ideas, some of which I've already half started, and see how far I can take them. I have five projects in mind, each taking something like 20 nights.

First up, I'm going back to Ruby and back to this blog. I'm going to write the slimmed down Jekyll replacement I thought about writing before going with JavaScript. Zine, the first project even has a name already, Zine. I could have written it in Elixir I suppose, but I just don't feel the language is up to it yet. So Ruby, for a few reasons.

Ruby because it'll be easier for me to maintain, both because it's easier for me to read & because it'll be more fun for me to tinker with. Last week I moved the Node version to use SSL connections only & I changed the layout very slightly, and that wasn't as fun as it might have been. Fun is important in a side project. Ruby too because I realised that in all these years I've never published a gem, and giving something back however small would be nice. But Ruby because I wanted to get stuff done, & quickly, & there's no better language to do that in.

Setting up my development environment & the gem, and then getting the thing to do some useful things was all pretty straightforward, and very quick. I got further tonight in an hour than I've got in days in some other languages, and once working output's being generated the refactoring & other fun can kick off.

I had to cheat a fair bit on night one, Googling the stuff I couldn't quite remember, and while the examples were plentiful I was a little saddened to see how many of them were from 5 or even 10 years ago. All of comp sci is a trade-off. With Ruby some execution speed's traded away for other things, and it's worth remembering how important some of those things are: speed of development, ease of maintenance, an emphasis on testing, as well as being part of Ruby's unique community, they're worth it for me… monkey patching there's still no excuse for, but you can't have everything.

Onward, for 100 days.

Previously

Earlier posts...