$ cat /home/buntine/mind_melting_brilliance

I've been collecting Czech heavy metal LPs for several years now. There are just a few titles that I am missing. Some of these are so rare that only a few people even know they exist. The Sax Pijak is not so rare, but I still haven't got it yet.

I've seen some of them in photos and others I have been told exist from Czech nationals. The only one I have never actually seen is the Merlin "Nevada" LP. If anything has one of these, please let me know!

• Sifon - 100 høíchù LP (self, 1991) - FOUND 01/06/10
• TÖRR - Kladivo na čarodějnice LP (Monitor, 1993)
• Alkehol - Alkehol LP (Monitor, 1992)  - FOUND 20/05/10
• Alkehol - S úsmìvem se pije líp LP (Monitor, 1993)
• Arakain - Schizofrenie EP (NOT LP) (Suprahpon, 1991)
• Alien - Kino noc a kino den/Cesta všech EP (Best I.A, 1992)
• Distorze - Distorze / Zrcadlo (Best I.A, 1990)
• Distorze - Fuck of War EP (Private, 1991)
• Tarantula - Peklo pro všechny LP (Tony records, 1992)
• Merlin - Nevada LP (Monitor, 1991)
• Sebastian - Sny o Marii LP (Monitor, 1991) - FOUND 05/07/10
• Mac Beth - Mac Beth LP (Best I.A, 1992)
• Sax Piják - Válka nervù LP (Sacred records, 1992)
• Calibos - Calibos LP (Globus, 1992)
• Kabát - Děvky ty to znaj LP (Monitor, 1993)
• Pathologist - Putrefactive and Cadaverous Odes About Necroticism LP (M.A.B, 1993)
• Apolon - TVÁR SEBCA / ČACHTICKÁ PANI EP (Zeras, 1992)

ROT13 (that is, ROTate by 13 places) is a very simply substitution cipher that is often used in online forums, games and chat rooms. The idea was invented by Julius Caesar over 2,000 years ago (it was ROT3), but has been popular on the WWW since the '80s.

It works by rotating each character in a string of text by thirteen alphabetical characters, wrapping over to the beginning if necessary. For example:

Hello --> Uryyb --> Hello

As demonstrated above, one of the cool things about this simple technique is that it is it's own inverse. That is, applying the same filter twice will yield exactly what you started with. This, of course, makes it totally useless as a production-level encryption algorithm, but very handy for non-critical uses such as games and puzzles.

A very-similar alternative is ROT47, which applies the same concept to a larger range of characters in the ASCII set (94 to be exact: 33 to 127). This allows us to include several additional characters such as exclamation marks, commas, etc.

I've written a Firefox add-on, which allows you to select some text on a webpage, right-click it, and then generate the ROT13 or ROT47 substitute. From here you can re-apply the cipher and/or copy the new value to your local clipboard.

Please check it out and let me know of any problems you run into. Thanks!

Official download: https://addons.mozilla.org/en-US/firefox/addon/125128/

Or view/modify the source code: http://github.com/buntine/Quick-ROT13/

After I finished writing the Bolverk emulator (source, implementation) in early 2009, I instantly had ideas about designing an assembly language for it's native instruction set. It sounded like an interesting project.

After reading the first few hundred pages of Michael L. Scott's brilliant book "Programming Language Pragmatics" during February of this year, I felt that I had enough knowledge about writing simple compilers (most assemblers are not really considered compilers, but shhhh) in order to get started. In fact, the whole process turned out to be far more challenging and rewarding than I would ever have guessed before.

An assembler provides a level of abstraction above the native language of the machine at hand. Most basic assemblers provide a one-to-one mapping between named instructions and native commands (generally ones and zeroes). Many more modern assemblers also support more advanced features like macro expansion and control structures over basic JUMPing.
With an assembler, we can now express instructions to Bolverk in atleast slightly more memorable instructions. This is the reason the primitive procedures defined in an assembly language are often referred to as "mnemonics".

Another great advantage of an assembler is it's ability to define arbitrary abstractions that defy the architectural restrictions of it's target machine. In particular, the bolverk machine specifies that only 4-bits are used to identify an instruction. This leaves us with only sixteen (0..F) possible options. If chosen correctly, these sixteen natives will be more than enough to define useful abstractions by compounding and naming them. As an example, the PVDS mnemonic used in the example below will actally compile to 3 lines of machine code.

With the finished product, we can now write something like this:

-- Print the sum of two decimal numbers (-10 and 120)
-- followed by an exclamation mark.
VALL 1, -10
VALL 2, 120
PVDS 1, 2
PVCH '!'

Instead of the very-hard-to-remember machine code equivalent:

21f6
2278
2421
5123
33a0
34a1
d1a0
d0a1
c000

The assembly version required only four instructions opposed to the nine required in the machine code version. It was also presented in much more readable manner.

Once we know the following semantics:

• VALL: Load into register X the value Y
• PVDS: Print to STDOUT the value of the sum of register X and register Y
• PVCH: Print to STDOUT, the value of X as though it's an ASCII character

The assembly version becomes very easy to understand.

The source code is openly available from my git repository here: http://github.com/buntine/Bolverk-Assembler. I will add a front-end for it into the web-based implementation of Bolverk (linked above) in the coming days. I've also published the grammar and a language specification in the same git repository.

I feel that my work on this set of projects could really be beneficial in teaching the ideas behind a Von Neumann machine to beginning computer science students. If found by the right person in the right position, I think they could do wonders with it. If you are that person - please give me an email or some feedback! I'd happily donate all of my work to your organisation if it can be put to good use.

If you're like me, you've probably read the first 150 pages of SICP (The Structure and Interpretation of Computer Programs) about three times. Personally, I find that it starts out extremely easy, but quickly becomes difficult. After a while I find that I am still reading, but not a whole lot is making sense to me. It's as though there is an underlying peice of knowledge that the authors assume I possess, which I don't.

I am of the school of "SICP should be read by all programmers". But I think my exact statement would be: "SICP should be read, and understood, by all programmers".

If we take a look on Amazon, we will see the strange mix of reviews SICP has received thus far (stars/reviews): 5/89, 4/8, 3/8, 2/3, 1/53

What?? So, I guess this implies that people either LOVE or HATE this book. If you go through the reviews in detail, you can see that a lot of the 1-star reviewers are upset with the text because it's simply too abstract and they do not leave with any confidence. I feel it is also worth mentioning that this text has received an elitist badge in our industry. If you read it, watch the lectures, and brainwash yourself into thinking you understood everything, you are now part of the genius club and can start quoting Paul Graham and Peter Norvig.

Enter Simply Scheme (Brain Harvey, Matthew Wright. 2nd ed, 1999, MIT press). A fundamental computer programming textbook for those of us who have trouble tackling SICP (and also for the people who, out of fear, pretend they could). According to the authors, SS was actually written as a pre-cursor to SICP. This textbook presents all the major concepts in a much more digestible way than SICP. This is good news!

As a word of warning, it's worth knowing that SS does use Scheme, but it teaches a slightly modified version of it. You will learn effective program design, but not the inner workings of Scheme itself. I already knew scheme when I started this book, and it annoyed me a little at the beginning, but I quickly got used to it.

The entire text is available free on the web. Take a look: http://www.eecs.berkeley.edu/~bh/ss-toc2.html.

I have also spent a lot of my freetime publishing my answers to all of the exercises at the end of each chapter. You can take a look at my solutions here: http://github.com/buntine/Simply-Scheme-Exercises (perhaps you can fork me and juxtapose your own solutions??). I hope this can help someone in their travels.

So, once you get through Simply Scheme, you may be much better suited to properly tackle SICP and finally become a master craftsman!

I had planned to post these more often, but hey, I guess I've been busy with non-computery stuff for the first time in far too long.

At the moment I am in Thailand, in Krabi Town specifically, a small-ish city in the south. It's near Phuket (which I did not like, for the record).

I've been on the road for about a month now and have loved (nearly) every minute of it. The first few days were a little rough as it was at that point I truly realised I was alone in a very foreign place.

At this point, I've seen most of the country. There are still some spots in central Thailand that I'd like to check out, but that will have to happen another time. I think my favourite place so far has been Chiang Mai, the proverbial "capital of the North". It's an ancient city with a laid-back atmosphere. Tomorrow night I am catching the overnight train up to Bangkok, where I will spend a few more nights.

On the 29th of December, I am flying directly to Munich, Germany. From there I will try and see as much of Eastern Europe as possibly can in 20 days (without rushing too much, of course). My only guideline is that I will need to be in Amsterdam on the 18th of January. At this point I will be meeting my younger sister, Grace, with whom I will travel through some of Western Europe (The Netherlands, Belgium, France, Switzerland).

At this point, I am feeling glad that I decided to travel alone. This type of radical decision really helps you come out your shell. I've met a lot of really cool people from all over the world and experienced Thai culture in a way that a lot of package travellers would never get to see.

Until next time!

A few weeks ago, I booked a one-way ticket to Bangkok. I have a netbook, a backpack, malaria tablets, new shoes, and some books on LISP.

I am departing from Melbourne at 2:55pm on December 1st, 2009.

The plan (well, if I had one, this would be it) is to spend a few weeks in Thailand, and then transplant myself into Cambodia. After visiting all of the Wats (temples) and soaking in the atmosphere, I'll travel into Laos and lay back for a few weeks. I've heard there is a cool "river-tubing" activity near Vang Vieng, which sounds fun.

Next is the hustle-bustle of Vietnam! I've heard excellent things about this country, and really look forward to checking it out. My sister says she will fly over and meet me in Hanoi, which would be ultra badass!

After that, depending on my financial, physical and emotional state, I may well just keep going and catch a flight to somewhere in China. But who knows? By then I might be in Africa or South America...

I'll still be online regularly (where possible), so hopefully I can document some of my travels as I go. Wish me luck! :)

Running an arbitrary process, such as a Python script, on your Linux box as a daemon is really quite simple if you have the right tools.

In my case, I had a simple Python socket server that needed to run permanently. Simply running it in the background (Ctrl-z) is no good as it would die the moment I logged off!

Enter daemon, a really handy tool for solving this exact problem.

Installation is easy. On Debian-based distros, you can just install it directly form aptitude. On CentOS, which uses yum, I had to install it from source. But I ran into no problems there.

Once installed, getting things running was easy:

$ daemon -r --name=myserver python /full/path/to/myserver.py

The "r" flag tells daemon to respawn itself if the service is killed. I've given it a name so I can refer to it later. And the rest of the line is the actual command I want to run.

To test if the process is still running, you can look in ps or pgrep, but the best way to do it is to simply ask daemon personally:

$ daemon -v --name=myserver --running

The "v" flag is for verbosity (of coarse). The "running" flag tell daemon that I want to know if the process specified by "name" is still running. The output you receive is simple to interpret, e.g: "myserver is running with PID: 23324".

To finally kill the process at some point in the future, you can issue the following command:

$ daemon -v --name=myserver --stop

And this one should be rather self-explanatory by now. :)

I've only grazed the surface here. Just check out the man page for an idea of how much more you can do with this. Good luck, muchachos!

A while ago I found myself in the position where I needed to convince my managers that Pair Programming was a worthwhile business investment. I was recommending the traditional approach, consisting of a "driver" and an "observer", who optionally switch roles at semi-constant intervals.

I was conscious enough to know that getting the actual benefits across clearly was important as the whole concept could easily be misconstrued to mean something along the lines of: "Hey! I want to sporadically wrap all of the production staff into neat little bundles of two".

Below are my no-bullshit reasons why, from my own experience, pair programming/designing/writing works well. Now, I should mention that your own mileage may vary. I've had occasions where peoples ego's (perhaps including my own) have got in the way -- but that's a whole different issue! Anyway:

• When working in two, people spend less time looking at forums, news and otherwise useless crap.
• Increases the Bus-Factor. That is, the number of people that need to be hit by buses before a substantial amount of domain knowledge is forever lost.
• If stuck on a problem, sometimes the best way to solve it is simply to ask someone to listen to you explain it (the answer becomes clear when you dictate the issue). This is a well-known phenomenon.
• When seeing each other work, staff can really gain an insight into how they spend their days and why they are an important asset.
• Staff can expand their skillset by observing each others experience and knowhow.
• Two minds are better than one when it comes to complex problem-solving.
• Bonding is always a plus.

Perhaps this list will help another cronie in convincing their managers of "pairings" effectiveness? Good luck.

I recently noticed that Discogs.com, a huge discographies database, had released their API in the public domain. I think this is a really nice offering, especially considering effective use of the Ebay API can cost in excess of $50,000 per year...

Unfortunately, I couldn't really think of anything useful to do with the information. So instead I've spent the last few weeks writing a 100% Ruby wrapper for version 1.0 of the API. It abstracts all of the tedious work of handling requests/responses, parsing the XML, etc. This way, if someone else has a good idea (or I have one in the future), most of the work will already be done!

Anyway, enough of that. The specifics:

Support

The library currently supports everything in version 1.0 of the API as documented (sort of) on the Discogs website. Namely:

• Artists
• Releases
• Labels
• Searching (all of the above

Installation

I've setup the library as a gem so installation is as easy as:

$ gem sources -a http://gems.github.com
$ sudo gem install buntine-discogs

Usage

Here is a small taste of what you can do:

require 'rubygems'
require 'discogs'

wrapper = Discogs::Wrapper.new("my_api_key")
artist = wrapper.get_artist("Master's Hammer")
release = wrapper.get_release("611973") # Supply an ID.

artist.name                        # => Master's Hammer
artist.releases[0].title           # => Finished
artist.releases[1].year            # => 1989
artist.releases[4].extraartists    # => [ "Arakain", "Debustrol" ]

release.title                      # => "Ritual"
release.labels[0].name             # => "Osmose Productions"
release.formats[0].descriptions[0] # => "LP"
release.styles                     # => [ "Black Metal", "Death Metal" ]
release.tracklist[1].title         # => "Pad modly"

Finding out more

I have setup the repository at github. Please let me know of any bugs/problems you find. I'm open to suggestions for improvement, also. Fork me!

On the wiki at github, I have setup a bunch of examples and some documentation for each resource.

Since Bolverk has gone live, I've had a few friends mention to me that "[It] sounds like a cool idea, but I have no idea where to start". Because of this, I've decided a small example of how one might go about programming her is in order.

I will demonstrate how to read in two binary numbers, determine their sum, and then print that value to the standard output.

0: Write the machine instructions

Below is an example of how you could write the solution (along with notes in parentheses).

2143 (LOAD register 1 with the decimal value 67)
220D (LOAD register 2 with the decimal value 13)
5123 (ADD register 1 and register 2 and store the result in register 3)
33A1 (STORE the contents of register 3 into the memory cell A1)
D1A1 (PRINT the contents of memory cell A1 as a decimal number -- 80)
C000 (HALT the program)

1. Load the instructions into main memory.

Click the "Write / Load Program" link and wait for the thickbox dialog to load up. Once ready, copy the following into the textarea:

2143 220D 5123 33A1 D1A1 C000

The "Starting cell" select can be left as is. Now click "Insert". You will notice that the program has been loaded into main memory. The populated cells will appear purple.

Note, you can manually change any single memory cell by double clicking it, changing the hexadecimal value, and then clicking out of the cell.

2. Initialise the program.

Click on the first cell of your program. You will notice the "Initialize Program" button will be enabled. Click it.

You will notice that the first two cells of your program code will be highlighted. This, as the legend shows, is the next instruction the machine will execute.

3. Run the program.

This is the easy part. You simply have to click the "Machine Cycle" button for each machine instruction in your program. At each instruction, you will see how the processor is being affected.

Try it! By the time the program ends, you should have the decimal number "80" printed to Standard Output.