The home computer was born in the early 1980’s and in England this came in the shape of the ZX Spectrum. Along with it came the birth of the British video game industry. Although I had a ZX81 the year before, it was the ZX Spectrum I received as an xmas gift in 1983 that got me hooked on games, in particular the classic Manic Miner; a simple, addictive, and deceptively difficult platformer.
A year and a half ago I found the Skoolkit disassembly toolkit and one of the examples was the disassembled source code for Manic Miner. As I’d recently started learning to program in C, I thought it’d be a great learning experience to port this classic Z80 game to the C language. After some months I had a working version of Manic Miner written in C and using SDL2.
Porting Manic Miner was a lot of fun and it’d given me a greater understanding of how these early assembly games were written. It had also piqued my interest for how these old Z80 games are disassembled so I decided to give it a go myself.
There are many speccy games to choose from, such as Jetpac, or the classic Knight Lore, but that had been disassembled by others already, so for my first disassembly I decided on Cyclone (the sequel to TTL - Tornado Low Level). Although TLL was the more popular of the two, I’d always preferred the less frantic Cyclone. I thought this would make an interesting project, especially due to its isometric game view.
As of writing, this project is not complete, but I wanted to share some of the tehniques I’ve discovered so far…
After barely programming in Go these past two years I really wanted to get back into using the language, and figured a good starter project would be to port my Ruby time tracker to Go. So a few weeks back I started rewriting that old CLI application in Go, and have now released TimeWarrior 1.1.0 on Github.
TimeWarrior is a CLI based time tracking application used to record timeslips for your freelance and personal projects. Timeslips for a project are stored in their own project data files, with each timeslip saved as a valid JSON string.
Project and Task names are given as
CamelCase; separated by a period. You would
start a new timeslip like this:
$ tw s MyProject.SomeTask
resume a timeslip at any time (the
r shortcuts are available), and once work on a task is complete, you can mark it as
$ tw d "Some nice description of the work"
It’s also possible to adjust the time you’ve currently worked on a pending timeslip with the adjust command:
$ tw adjust 10m
I recommend you visit the Github repository which has full installation and usage instructions.
At the moment you will need to build the executable yourself, but hopefully I’ll have ready-made downloads for Windows and macOS soon, once I’ve run some tests on a Windows machine!
Please note that there’s currently no reporting functionality. I have a simple old script for my own needs, which I’ll eventually look into adding to the app.
If you’re impatient and you’d like to implement a
report command yourself, please feel free to submit a PR!
If you’ve been trying to use the
goncurses library in your Go project, but kept encountering various ncurses related errors - such as missing
.pc files (
panel.pc) - then this post may help you get your Mac OS X, ncurses and golang installation running smoothly.
A couple of weekends ago I decided that porting the classic UMoria game could teach me alot about Go. It all went swimmingly well - if somewhat boring at times - and finally last night I was able to get the code to compile without errors, Woot! But when trying to install goncurses I kept getting ncurses errors. Boo!
I’d experimented a little with goncurses a couple of months back and somehow go it working - for the life of me I don’t now remember how. It was fun making my little
@ character run around the screen, but when I updated to Go 1.5, I’d reset my golang dev environment, which included deleting old sources.
After several hours down the rabbit hole, I finally figured out what the issue was, and as I’m sure others have encountered these same problems, I wanted to share the solution here.
For the past five years I’ve been building software in Ruby, it’s a great a language to work in and for many situations its performance is more than adequate. Recently though, I started to encounter situations that would benefit from something with a little more oomph! There’s plenty of languages I could choose from that’d give a good speed boost, and after much consideration I whittled the list down to Go and Java.
I’ve been playing around with Java for a couple of months (just some casual learning really) and I have no experience what-so-ever with Golang. To allow me to gain some real world experience, as well as something to let me gather performance data of each, I decided to write a small test app, and share my test results here.
I won’t be going into details on why I chose Golang and Java (speed was just one of the criteria), but I will give you a little background on the app I wrote to test them.
UPDATED 2015-11-21: now includes benchmark results for both Go 1.4.2 and 1.5.1.
Anyone who’s used Ruby on Rails has likely needed to implement pagination, and for that you probably used WillPaginate. Although it’s been possible to use WillPaginate with Sequel for some time now, we’ve only just seen the first Roda GEM released. After some experiementation, it turns out adding pagination to our Roda app is actually pretty easy.
We’ll be building on top of my Roda Blog tutorial so if you don’t already have an application to try this with then you should take a look at that first.
Here’s the versions and GEMs I’ll be using for this tutorial;
Our first task is too add
roda-will_paginate to our
Gemfile – don’t forget to
bundle install once you’ve done that.
# ./Gemfile gem "roda-will_paginate", ">= 0.0.4"
The plugin only handles generating the HTML links on your view pages, so we need to make sure our blogs
Post collection includes the required WillPaginate methods. As the plugin README states, “That would mean adding
total_pages as methods of your collection and including
WillPaginate::CollectionMethods in your collections as well.”
That’s quite a bit of work, but lucky for us we’re using Sequel, and WillPaginate supports that out-of-the-box.
There can be a number of reasons for wanting to add sitemap to your site, but perhaps the most important is for Google - and other search engines (SE’s) of course! From an SEO viewpoint Google expects your site to have a sitemap and thankfully, this is very easy to do with Ruby websites.
In this short tutorial we’ll be implementing an automated sitemap for a site built with the Roda framework. I’ll be building on top of my previous Roda Blog tutorial, which you might find useful to look over before continuing.
After launching my new blog - built with the Roda framework - I was pretty chuffed with how things turned out. Sure, there’s still a few minor niggles, but for the most part, everything is working well.
Then a couple of weeks back an issue turned up on Google groups about how Roda was returning a 404 on empty responses. This got me thinking on what the headers of my site look like, so I booted up the terminal and made a
$ curl -I http://mrcook.uk
The response included these two lines;
HTTP/1.1 404 Not Found ... Status: 404 Not Found
That was a surprise, although it turns out this is actually correct Roda behaviour.
Roda is a framework, but unlike Ruby on Rails, it let’s you have full control over how you build your app, and that includes how the headers are configured. Fair enough, but for public facing websites, having the headers return a 404 status is probably not a good idea.
In my last article we built a simple Roda website, which let us deliver some rather static pages. We’ll build on that work by implementing some basic blogging features such as User accounts and Posts.
Note: as this article was posted in April 2015 I can not guarantee it will still work with the latest versions Roda.
We’ll be using a PostgreSQL database, the defacto DB of many Rubyist, which we’ll interact with using Sequel, an excellent ORM by Jeremy Evans, who is also the developer behind Roda.
Please make sure to install PostgreSQL before continuing. Once that’s done we need to add the appropriate RubyGems to our Gemfile;
# ./Gemfile gem "pg", "~> 0.18.1" gem "sequel", "~> 4.21.0"
bundle install we need to connect Sequel to the database. In a real world application we’d want to keep our
myapp.rb uncluttered by placing the configuration in a separate
database.yml file, and ORM initialization in
database.rb, but I’ll simplify that for this tutorial by including everything right in the main app file.
# ./myapp.rb require "roda" require "sequel" database = "myapp_development" user = ENV["PGUSER"] password = ENV["PGPASSWORD"] DB = Sequel.connect(adapter: "postgres", database: database, host: "127.0.0.1", user: user, password: password) class Myapp < Roda # ... end
It can be useful to use environment variables for things like usernames and passwords, which is what I’ve done here, but if you’d like, just replace the
ENV directly with your database user/password credentials. If your
host setting is different then make sure to change that too.
Recently I started experimenting with the Roda framework to build web applications but as there are not many tutorials, or blog posts in general, about Roda, I thought I’d share my experiences here. Over the coming weeks I’ll be writing a number of articles on using Roda but rather than having to duplicate lots of setup code I think it’ll be easier to have a base app to work from. So, in the next two articles I’ll be building an extremely simple blog using Roda, Postgres, and the Sequel ORM. For this first part we’ll deliver static content, leaving User accounts and posts for part two.
For those who want to follow along, my system is Mac OSX 10.9, along with the following software versions;
Your application may not work if you use a different version of Roda than what I specify here, but for the rest, you shouldn’t encounter any issues if your versions are a little older/newer.
Installation of Ruby and Postgres is left as an exercise for the reader.
This is actually the simplest part of the whole procedure as Roda is just a regular GEM. We are however going to be using Bundler for our gem management so first you’ll want to install that, followed by Roda;
$ gem install bundler $ gem install roda
Unfortunately there are currently no site generators in Roda like there is in Ruby on Rails (
rails new myapp). This means we’ll have to generate our application directory and file structure by hand. Here’s the outline that we’ll be using for our simple blog;
- myapp/ - models/ - public/ - views/ - config.ru - Gemfile - myapp.rb - models.rb
Go ahead, create the base app directory;
$ mkdir ~/myapp $ cd ~/myapp
I always like to use Bundler for the gem management so we’ll need to create a Gemfile in which we’ll specify the basic gems requirements for delivering static content;
# ./Gemfile source "https://rubygems.org" gem "roda", "~> 2.1.0" gem "tilt", "~> 2.0.1" gem "erubis", "~> 2.7.0"
Remember to run
bundle install now, and each time you make a change to this file.
At present we have just three dependencies; the first is Roda itself, but we’re also including
erubis so that we can use ERB templates in all our views.
Like all Ruby web frameworks, Roda is built on top of Rack, so we’re going to need a
config.ru so that when we start the server (with rackup), our application will be loaded;
I’m currently experimenting with building a web application using Sinatra and the Sequel ORM, and as is often required in database driven applications, I need to pull a bunch of records yet exclude those that don’t have any associated records in a
one_to_many relationship (
has_many in Rails parlance).
Imagine we are building a blog platform where we can have Post’s that get assigned to a Category (
many_to_one). When listing our available categories we don’t want to be showing any that haven’t any posts assigned. I wasn’t able to gleam anything specific about doing this from the Sequel documentation, so after a prolonged hair-pulling session I came to the following solution.
First, here’s the basic outline of our models;
class Post < Sequel::Model many_to_one :category end class Category < Sequel::Model one_to_many :posts dataset_module do def with_posts where(id: Post.select(:category_id)) end end end
As you can see, we are using a
dataset_module to set the scope for our query, allowing us to call
.with_posts wherever we need a listing of categories. The
where(id: Post.select(:category_id)) tries to match any Post that has our
category.id. Using our new scope we can now set our controller like so;
get "/categories" do @categories = Category.with_posts.order(:name) erb :categories end
In Rails we have the option to set a counter cache on the Category model;
posts_count, which let’s us filter by that. Sequel has the
sequel_postgresql_triggers plugin, which let’s you do the same (using
pgt_counter_cache) if you are using PostgreSQL, although I haven’t looked into that just yet.
Hi, my name is Michael and this is my personal blog. Here I’ll be posting various coding thoughts and experiments; everything from writing blogs in Ruby, to Go tools and Z80 Assembly. This site is powered by Thunderaxe, a blogging platform I built using the Roda Ruby framework.