I’ve been on a quest over the last year or so to understand fully how a program ends up going from your brain into code, from code into an executable and from an executable into an executing program on your processor. I like the point I’ve got to in this pursuit, so I’m going to brain dump here :)

Prerequisite Knowledge: Some knowledge of assembler will help. Some knowledge of processors will also help. I wouldn’t call either of these necessary, though, I’ll try my best to explain what needs explaining. What you will need, though, is a toolchain. If you’re on Ubuntu, hopefully this article will help. If you’re on another system, Google for “[your os] build essentials”, e.g. “arch linux build essentials”.

I started working on an x86-based pure-Ruby virtual machine! Not a virtual machine to run Ruby, a virtual machine built in Ruby that executes something that looks a little bit like x86 but isn’t. Why?

This is a write up of where I’m at so far.

I haven’t yet made a post about GiveMondays, it has been another one of those things I’ve been meaning to do but haven’t got around to until now. I have, however, been tweeting about it and posting on Facebook about it quite a lot.

Today prompted me to write this post because we almost got into trouble with the police. It was fun! :)

I ordered myself a copy of “Expert C Programming” by Peter van der Linden after reading this article, a “Beginner’s Guide to Linkers and Loaders”. Trying to get myself to grips with C and how it goes from being C to being machine code, apparently van der Linden’s book is an excellent resource for this topic :)

This post is my solution to his “The Piece of Code That Understandeth All Parsing”.

This is quite overdue, but I took part in Movember in November of last year and got a little bit ahead of myself while trying to raise as much money as possible.

Andy Kent gave a great talk at Forward about things that he has learnt through CoderDojo about kids and what they do and don’t understand when trying to learn. I’m going to reiterate some of his points here and add a few of my own on top.

It has been a few months! Lots of cool things have happened:

• I graduated
• I went to America
• I got a job working at Forward
• I moved to London
• I got involved in lots of cool charity stuff

This post is less tech heavy, more catchy uppy.

Access control in Ruby feels, to me, a little different to access control in other languages. In this post I’m going to talk about it, demonstrate ways around it and ultimately give my opinion on why I think access control in general is a little bit pointless.

Note: This is going to be fairly light-hearted and not-practical. If you truly need something to be private in your code there are best practices involving databases and encryption. This post just aims to demonstrate the possibilities in Ruby and have some fun with them.

Prerequisite Knowledge: Knowing what access control is will help, but I’ll provide an explanation at the beginning of the post anyway. Basic Ruby is required. Some of the metaprogramming stuff might be confusing but bear with it. If you don’t know what instance_eval does, I recommend looking it up before reading this post.

I’ve been tinkering around with using Vim sessions recently. They allow you to save the state of Vim and reload it at a later point. It saves things like the files that you have open, the windows they’re in, the sizes of those windows and so on and so forth. Here I’m going to share a few lines in my .vimrc that should hopefully come in useful.

Prerequisite Knowledge: You should be a vim user that isn’t afraid to make changes to their .vimrc file.

I’ve been meaning to get into electronics for a long time, so the other day I decided to actually make the leap, order a tonne of Arduino stuff and a book on learning how to use it, and start hacking.

Prerequisite Knowledge: None, really. I didn’t have any. This post is more of a “look what I bought! Woot!” post.