Waiting for the PS4 I realized that (1) it’s still a while until it arrives, (2) it’ll probably be a bit expensive at first and (3) there won’t be a huge number of games for it. Conclusion: had to buy a PS3, and play some things I missed.

Having been a PC-only gamer, I had a screen and great headphones. Note: not a TV; a computer screen with no speakers built in. I asked about the video, and got a DVI-HDMI adapter. Simple. Surprise: I noticed after all else was et up that there’s no jack output on the thing. There are plenty of other outputs though. If you want 5.1, you can use the HDMI or optical digital output. If you want 7.1, you need to use HDMI. I just wanted my headphones to work, so I used the simple RCA output (which supports only stereo).

1
2
3
4
5
6
7
8
9
10
11
12

from rest_framework import serializers
from models import MyModel


class WithPkMixin(object):
    def get_pk_field(self, model_field):
        return self.get_field(model_field)


class MyModelSerializer(WithPk, serializers.HyperlinkedModelSerializer):
    class Meta:
        model = MyModel

If that’s enough for you, glad to be of service. Some context follows, and also a way to wrap JSON top-level list responses in a JSON object.

If you have a hsenv environment (kind of like virtualenv, except it’s for Haskell), you can easily move it to another location and use it there; all you need to do is change a few strings in a few files. Here’s how, assuming you’re in the directory containing the .hsenv folder:

1
2
3
4
5

old_location=FILL_THIS
new_location=FILL_THIS
for file in ghc_package_path_var path_var_prependix bin/activate; do
    sed -e "s,$old_location,$new_location,g" -i .hsenv/$file
done

Using Bacon.js to escape from Butcher Bay callback hell has been quite a pleasant, if mind-bending, experience. However, there hasn’t been too much talk about real usage on the server-side. I’d like to remedy this situation with some examples and tips I learned while converting a simple hand-coded REST API to Bacon.js.

Ingredients

• One spoonful of OSX
• A sprinkling of Git
• Three pounds source code

Preparation

1. Rename user.coffee to User.coffee, setting core.ignorecase just in case
2. Commit, push
3. Edit User.coffee and watch as git diffs don’t make any sense, git reset doesn’t reset, git stash doesn’t stash, git commit -a doesn’t commit.
4. Laugh with glee as your editor jumps between the current and an old-old-old version
5. Go on holiday, give up, freak out

Serve for two

1. Realize (probably with help from colleagues) that the OSX file-system is not case-sensitive
2. Go to GitHub or clone the project on Linux
3. Realize that both user.coffee and User.coffee exist
4. Delete user.coffee

After having fought my way through Clean Code, I’m now reading The Clean Coder. Both are great books you should read. Clean Code helped me crystallize and expand on the ideas I had about good code. The Clean Coder is more about the part of programming you spend away from your computer; estimation, testing strategies, communicating inside and outside the team, generally being a professional. The whole book is really about being professional. (Disclaimer: links are affiliate links to Amazon)

I already have two active to-do items. There’s a whole paragraph asking “do you know what X is”? And honestly, I have no idea about most of those X’s. Not even what they may be about. So it’s probably time to pick up some more theory. On the other hand, Uncle Bob emphasizes actively honing your programming skills. A good way to do that is code katas. The term, apparently started here, is taken from martial arts: a kata is a series of excercises you practice until you achieve perfect form (for an appropriately small threshold).

I’ve written three small scripts that should help document katas. One asks which kata you want to do, what language you want to use, sets up the environment and commits the initial state. The other makes sure your tests pass and commits your code. The third runs tests and commits the state after each test run. A kata “run” goes into a branch named after the kata, the language and the date. The branch reference is deleted after the kata is done. There’s one template directory per language; this is used to initialize a new kata by the script. A kata is just a directory with a README; it’ll contain all the actual kata “runs”. Here, have a look: code-kata@GitHub

The only template at the time is for Ruby; I’m usually knee deep in chef cookbooks nowadays, so getting more fluent in Ruby looks like a good idea. The “start” and “done” scripts are also in Ruby for the same reason. Testing is done with rspec, a really cool DSL for writing tests. The first kata I did is Prime Factors. The spec is very simple, but the goal is to get the feel of the thing. It was also useful for fine-tuning the framework.

Here’s an example session using the tool:

$ ./start.rb

Language:
0. ruby
Choice: 0

Kata:
0. prime-factors
Choice: 0
You can now start working in katas/prime-factors/ruby-20121003-0
When done, just come back here and say ./done.rb
(creates a new branch, checks it out)

# Write test
./test.sh
tests fail (creates a commit with message FAIL)

# Write code
./test.sh
tests pass (creates a commit with message PASS)

# Write test

$ ./done.rb
Running tests for katas/prime-factors/ruby-20121003-0
Tests failed. Can't finish the kata if tests fail.

# Write code

$ ./done.rb
Running tests for katas/prime-factors/ruby-20121003-0
Grats, that's another one down. Don't forget to push!
(Commits, merges the kata into master, deletes the branch reference)

Just a note if you need / want to remove the redirects of yesod (a Haskell web framework) from http://myhost.com/ to http://myhost.com. You can find the below instance declaration in Foundation.hs if you’re using the scaffold. If not, you’ll know where it is, because you put it there :)

1
2

instance Yesod App where
    cleanPath _ pieces = Right $ filter (not . ((==) "")) piece

This ignores any trailing slashes (and duplicates as well), so that all the following URLs will be considered the same as http://myhost/a/b

• http://myhost/a/b/
• http://myhost//a//b
• http://myhost/a/b//
• http://myhost/a/b

#

You’re a cool kid, right? All the cool kids have their blog and other stuff on a VPS (or on GitHub, but that’s a different story). Really cool kids have their stuff on Linode, by the way; yes, that’s a referral link. All the cool kids use Chef to manage their infrastructure at work consisting of N-hundred Heroku dynos and AWS instances. So why not manage your VPS with Chef? While you’re at it, why not upload the whole thing to GitHub? (Like this)

Yes, really, in 2012. See here, it’s on GitHub.

Why, in the name of all that is 8-bit?

For one, it’s fun. The core protocol is well defined by the RFCs.  In the web development world you don’t often get to program to specifications like that; it’s a nice change of pace. There’s no need for any front-end work either. I get to write Python, which I haven’t done for a while. And finally, it’s my own free time, nowgetoffmydamnlawn.

TL;DR No, it doesn’t work (as of 2012. April 28). This post is just to save you some time. But I’ll buy you a beer if you manage to get it to work, and tell me how.