Macha

This post is a response to the view of Hacker News outlined in this blog post on MattMaroon.com, read that post first for context. The main points are summarised up below, but I suggest you still read the original post.

1. Vocal, small groups can cause certain topics (e.g. the TSA) to become too popular.
2. Votes are used to represent agreement, not value added.
3. The community repeats the same views over and over again.
4. The community doesn't recognise the world outside itself.
5. It takes too much time.
6. It takes comments from blogs to itself.
7. It takes away time that could be used for blogging.

1. This is a problem on any social media site. The other one that I use, Reddit is even worse. And while it does let you pick certain categories to subscribe to, that doesn’t always help. TSA stuff ended up in /r/science even. And don’t talk to me about Prop 19. The site was rendered useless for me for the better part of 2 days because of people that are trying to pressure people to vote for something about some point I’m indifferent about at post in a country I don’t live in.
   I’m on the fence about downvotes in general. While I have thought downvotes will be useful at times, they lead to possible abuse like Digg’s bury brigade that came out a while back. The fact that the top voted comment on any sensationalist post is a highly voted rebuttal usually counters it out for me.
2. No argument here.
3. Pretty much agree with you. Though tech companies tend to polarize all communities. Reddit tends to dislike Apple to the same extent that HN likes it.
4. No argument here.
5. No argument here either
6. I don’t know about this one. I’ve submitted links to my blog to HN, some of which have done quite well before. On the one hand, it does bother me a bit to have the 50 or so comments occuring on HN while only 5 or 6 occur on my blog. But, had it not gone on HN, I might have had 2 on my blog and none elsewhere. So while I would like more of the discussion to be on my blog, it still benefits me. And in my experience, HN referrals are far more likely to bring comments than other sites.
7. On the one hand that is kind of true. Certainly there have been some things that I have posted as comments on HN and Reddit that could have been blog posts. But on the other hand, some of these are not fully formed thoughts until I read the post that HN is linking to. Furthermore, reading these sites sometimes gives me ideas that do become blog posts. And finally, given that HN has brought me in most of my traffic when my blog posts go popular there, would I feel comfortable just hit and run submitting my links? Definitely not.

So, I've had my blog and my twitter account for a while, and sometimes the constraints imposed by both formats has led to thoughts that didn't really have a place. Too long for Twitter, not long enough for a full blog post.

To top that off, Twitter lost all my tweets from when I started using it to about a month ago, further making me want to bring my content under my own control. This also rules out using Tumblr for this blog.

Taking some inspiration from Zed Shaw and his many sites, I've set up a seperate blog for these shorter posts. I'm not going to take it to the extreme of one blog per topic, however.

Also, for some technical experimentation, this is powered by blogofile, a Python blogging program which takes posts in Markdown and renders it to a static site. This does mean that it won't have comments initially, but I have strong opinions on the need for comments, so I'm looking for how to deal with that. I don't particularly like Disqus (it's way too bloated), but I'll probably end up needing to use that.

Ubuntu 10.04 Netbook Edition (2010)¹

Mac OS X Lion (presumably 2011)

Windows 3.1 (1992)

While working on my Haskell IRC bot, I needed some information on the actual IRC protocol. Much of this information sadly isn't available in any centralised format, and much of the information that is there is just a copy/paste of the RFC. There are two formal descriptions of the IRC protocol, an older one (RFC 1459) and a newer one (RFC 2812), though the actual protocol as used by most servers doesn't adhere exactly to either of these. So, here is a short summary of the information that I have gathered in my research. This is by no means a comprehensive tutorial, but it is sufficient to write a basic IRC bot.

The first part of the IRC protocol is the rough layout of messages. The first, optional part, is the source (username and hostmask, or server) preceded by a colon, as in :holmes.freenode.net . Because they only deal with one other part of the network, the server, clients will rarely, if ever send this part, while servers nearly always will.

The next part of the protocol, seperated by a space is the command name, which is in all-caps. Most of these are pretty much the same as what the user types in after the /. For example, the /join command becomes JOIN. The most notable exception is the PRIVMSG command, which is used for sending a message to a user or channel (it's the same command for both).

After this come the arguments for the command, again, space seperated. Most of these are limited to one word values. The one exception is the final argument, which can have more than one word, and is started off by a colon.

There are a few types of channel, but nearly all the channels you will encounter are of the #channel variety, so we will not go into detail on other types.

Finally, the command is terminated by \r\n, not \n according to the spec, though it seems most servers will accept either.

An example of a full message is as such:

:Macha!~macha@unaffiliated/macha PRIVMSG #botwar :Test response

The first part of any IRC connection is sending the NICK and USER messages. The first of these is simple, just NICK name. The next is the USER message.

An example of a USER message is:

USER username 0 * :Real name

The * part is a remnant of earlier days, and will not need to be changed. The 0 is a bitmask for the user's mode, but with just one switch. Change it to 8 to be invisible to those not in a channel with you.

The next part of the protocol we will discuss is the PING message, because some servers need one immediately after these two messages. The server will send you a message in the format PING :message to which it needs a response of PONG :message. This is the most common case of a server not sending a source. Most servers use the server name as the message part, but this isn't consistent.

For all of the rest of these messages,  there is a source on the other messages from the server side. This is a user and hostmask for a user's message, and a server name otherwise. If you are writing a client, do not send the :source part.

The next message to deal with is JOIN. The basic format of this message from most servers I've tested is

:source JOIN :#channel

although the spec says otherwise as regards the need for the colon. This is pretty self explanatory, and works the same as the /join used in an IRC client. The one unintuitive part of this command is that JOIN 0 leaves all channels.

Its counterpart is PART. Its format is

:source PART #channel :reason

The reason part is optional, and some servers (for example Freenode) seem to just cut it off, as it did not exist in earlier versions of the IRC protocol.

Both of these messages can also accept a list of channels separated by commas when sent from the client, for example PART #channel1,#channel2. Don't put spaces between the channels in this list.

The most important command in the IRC protocol is PRIVMSG. This command is used for sending messages both to channels and between users. Its format is

:source PRIVMSG <target> :Message

where the target is either a user's nick, or a channel name. So to send a message to a channel, use PRIVMSG #channel :Hello, World and to send a private message to a user, send PRIVMSG Nick :Hi!.

The final message you will use in basic usage is QUIT. Its format is

:source QUIT :reason

where the reason is optional.

These commands are sufficient to write a basic IRC bot but are by no means the full list. There are also numeric commands, and you can find more detail on these here.

I was helping someone who is just beginning to program over the past few weeks, and it led me to actually write a blog post I'd been saying I should write for a long time, about how I got where I am today as a programmer. This is mostly from memory, so some of the timing may be wrong.

My first experience with anything even close to programming was when I was around 12. I had gone through all my mum's ECDL stuff for MS Office years before, and there was one program in Office on my then computer that wasn't even mentioned - Frontpage. So I got bored one day, and decided to check what it was. I gathered quickly enough that is was for making websites, and I sort of got parts of it, but I had to get a book from the library to figure it out fully. Armed with this newfound knowledge, I managed to make a basic website, a horribly primary-coloured frame-filled website, but a website nonetheless.

Of course, my instinct was to show it to people, so I found out about Angelfire for hosting from an even older book, and uploaded it, then showed it to people online. Needless to say, people didn't like it very much. But a few people did give me some somewhat useful advice, to drop Frontpage. They mentioned something called Dreamweaver as being better, and also suggested learning HTML. Which I did, until eventually I was using Dreamweaver as a glorified text editor.

Meanwhile, looking for the next thing to do, I decided to learn actual programming, in the form of Java. In retrospect, not the best choice of language for starting out, but it was one of the few that my local library had books for. The other alternative if I was to stick to library books was Visual Basic 6.0, so it was definitely the better of the two options. I went through the whole book of Java All-In-One for dummies, went through it, did all the examples, got to the end, and wrote a little Java clock applet for my website. I was so happy with myself, that I decided to go even further, and my next plan of a project was to make a Simcity clone in Java. Unsurprisingly, that didn't work out too well, and the failure put 13 year old me off programming for a while.

The next time I came into contact with programming was when I was running a forum with a few friends. It ran off phpBB, and when installing mods, I noticed that all I was doing was editing programming code, which was kind of familiar. I looked into it a bit more, found out about PHP, and then quickly learned that. It was significantly easier to learn, both because it was my second language to learn, and also because languages with weak dynamic types are easier to learn in my opinion.

Of course, the problem with learning PHP, especially if you use the phpBB 2 code base as your example is you pick up bad habits. Now there's nothing inherently wrong with the language nowadays, but this was the PHP 4 days, with it's half-assed attempts at OOP. On top of that, something that is still a problem today is the amount of bad material floating around. Now, this is a problem with any language, but given PHP's large userbase, and popularity with hobbyist coders, it's far more pronounced in PHP than others I have used. So code found on the internet is ripe with a lack of care towards seperating output and processing, full of SQL injection holes, and often even relying on register_globals. But this isn't anything new. But it does lead me to recommend to everyone trying to get a good book. I started with this one, and while it did help me learn PHP, it set me back a long distance in terms of proper coding practices. Eventually, I got this book to learn how to code properly in PHP.

Around that time I started reading programming blogs, and found out about source control, in the form of Subversion, a rather important topic that no programming book seems to mention. Seriously, apart from Code Complete, which mentions it in glancingly a few times, the only book on my shelf that explains source control at all is the Linux Bible, 2009 edition. And that's talking about CVS. Now for all Subversion's faults, any source control is better than no source control. Later I was introduced to git and DVCS in general by some friends, and it's now my preferred form of source control (git for all Linux projects, hg if I have to work with Windows users). It didn't exist at the time, but for anyone looking for a good DVCS tutorial now, I reccomend Joel Spolsky's hginit. Even if you plan on using git or another program afterwards, it's the best basic explanation of the concepts of DVCS I've seen.

This was the only book to mention version control. Going back to my own journey, after that time in PHP, and several ill-fated projects, countless attempts at building a forum, a incomplete social network, and a completed, if basic, social network that I failed to get anyone to join, I moved on to Javascript. I spent ages messing about in that, making small scripts to move things around, before getting more ambitious. Yet again, I returned to the idea of a simcity clone. Given that this was before canvas became well supported or known about, the core of the program used a 200x200 table for the game's grid. It was every bit as slow as that sounds.

After a while of this, I returned to trying to make GUI desktop apps. I know, I know, many considering this a step backwards from web apps, but at the time, I couldn't think of many examples of web apps that had progressed of the "Oh, that's mildly interesting" stage. I had used Swing before, in my failed Simcity game, but wasn't particularly impressed by it. I gave SWT a go, before giving up again. I guess my problem with GUI apps resolves from my desire to control every last detail, compared to the designer-tool-centric design of most of the GUI toolkits. Somewhat bored with GUI apps again, but also bored of the general dislike of my main language, PHP, I went on a quick tour of several languages, including C#, C++, Ruby, Python, Ruby again, before finally deciding on Python as my new favourite.

Around this time, I switched to Linux as my primary OS. I'd tinkered with Linux for a while before this, but had always been too used to Windows to actually make the switch until then. Since then, Windows has been mostly relegated to use for gaming and iTunes.

I spent a while coding in Python, before going on a short hiatus from programming for a while, being somewhat bored as all the languages I learned being roughly the same at this stage, and no new ideas for a project to keep me interested. Projects are another thing I recommend to anyone starting to teach yourself programming, as even the failed ones or ones you get bored of are a good learning experience, especially if you have others looking over the code.

After a while, I decided to learn a less mainstream programming language, and after a quick straw poll on Twitter, Haskell emerged the winner. Luckily for me, Haskell has a good beginner's tutorial, Learn You a Haskell. I've heard it described as like Why's Poignant Guide, but it's not really. It's much more to the point which works for me (I'm sorry to say I found Why's Guide a rather boring read, having too much unneeded meandering with stories. But I accept it's good for others). It is a rather basic tutorial, but there is also Real World Haskell for when you need to go further, even if it isn't as well done.

And now, my current project is to write an IRC bot in Haskell to learn Haskell better. I'm still learning and improving, and it's going to be a handy headstart for college that I have all this done already, so the story goes on.