It looks like this year is nearing its end. Thanks for tagging along! I thought it might be fun to write a post that highlights some of the nicer posts I wrote this year. So far I've been blogging around two and a half years.
I think blogging is slowly starting show its advantages. Just a while ago I needed to solve certain Django specific problem. After googling around I happened to find the solution at my blog. In essence this blog serves as a kind of auxiliary memory of mine. As a side benefit some other people might find my ramblings useful too. This in turn might lead to new chances. Blogging is definitely a good way to market yourself if you're into that sort of thing.
There has been some talk on whether or not blogging is dying. The basic premise is that social mediums such as Facebook and Twitter are eating its popularity. That's probably partially true. I believe blogs will remain to have some influence. After all you'll need something to discuss and tweet about. Most importantly blogs are more permanent by nature. It's easier to refer back to some concrete blog post than some obscure Twitter conversation ages ago. Different mediums serve different purposes.
Now that I got the intro bit out of the way, let's take a look at the year. Quite a few things happened. While at it I'll try to outline some possible ideas for the next one. It's not like I'm running out of ideas. On the contrary. There's still plenty of material left I need to get out there sooner or later.
Open Source Projects of 2011
Project-wise this was a decent year. I managed to come up with quite a few personal projects and have a few new ones bubbling. I also did some commercial work. You know having some money doesn't hurt. :)
jswiki
At the end of January I set up a small JavaScript related wiki. This project started out of a request made by Andrea Bianco. He simply wanted to know what JS game engines are out there. As a result I ended up writing a brief list that eventually evolved into that wiki.
I'm still not entirely happy about the way it turned out. It's better than nothing but far from ideal. I've got some plans to make it better. Let's see if I can realize those during the next year. There's definitely some demand for this.
jsopo
I've always felt JavaScript would benefit from operator overloading. Doing some heavy duty math just gets plain ugly without it. jsopo was my first go at fixing this issue. Technically I wrote it during the last days of 2010 but let's not get too pedantic here...
On retrospect it was a good example of how not to solve this problem. Writing a semi-hacked JavaScript preprocessor just isn't that fun. At least the project served as a nice test case for another project of mine, Speccer. I'll get into that in a while.
Fortunately I managed to find a proper way to solve this problem. I came by a tool, JSShaper, that allows one to write AST transformations for JavaScript. The tool allows you to take valid JavaScript code and transform into it valid code looking a bit different. This was enough for me. I simply had to replace each math operation with a function call (ie. 2 + 3 get converted to add(2, 3)). It's easy enough to write those functions so that they handle polymorphism for me.
I haven't used the solution in practice yet. If I have to do some mathy stuff again (ie. vector math and such), I'll likely get to take advantage of it.
It would be fun to take the idea a bit further and come up with a way to extend JavaScript with some custom syntax that then gets converted into valid JavaScript code. This way I could get saner syntax in the language in certain cases. I consider this some kind of a compromise between solutions such as CoffeeScript and pure JavaScript.
Speccer
I implemented the first crude version of Speccer in March 2010. During this year I took it quite a bit further. I actually test my own Python packages these days using solely it.
I released version 0.7.5 of it a while ago. In my eyes it's getting safe to use for smaller scale experimental work. There are still a few features I want to add to it before I can get 1.0.0 out. Primarily I want to support decorators better and add some additional ways to structure your tests. These latter changes would make it more like Jasmine except with a lot lighter syntax.
This is definitely one of those tools that will remain in my toolbox. If you want to give the tool a go, check out the GitHub version to make sure you have the most recent fixes.
pyqa
pyqa is one of those projects I wrote just for fun. I've always found it annoying to write those scripts that ask the user a bunch of things and then do something based on those answers. pyqa fits just this niche. You can write your questions in nice YAML format (or XML if you are a masochist). pyqa handles asking those and returns you a data structure you can plug where you want to. It can be handy to use it to inject some values into some template or something.
It would be fun to use this projects to build those projects that can be used to build scaffolding for a new project. Talk about meta! Anyhow it would be nice to have some solution for this boring bit. After all you always have to do pretty much the same things at the start and it's always annoying to set them up.
pypandoc
pypandoc is one of those projects that grew out of frustration. PyPI allows project descriptions to contain only ReST formatted text. I really don't like ReST a lot. I'm more of a Markdown man. Ergo I must have a way to write project descriptions using it. pypandoc fits right there in the middle. It uses pandoc to convert my Markdown into ReST formatted text and everyone is happy!
iterplus
iterplus is a project that grew out of my dabblings with Haskell. It contains a set of Haskell inspired shortcuts that make it possible to do certain things easier. Just consider something like "fibo = scan(0, 1, lambda a, b: a + b)". It doesn't get a lot more succinct than that.
I guess the interesting bit about this project is that I wrote it in a documentation driven manner. The uses cases contained within the documentation are actual tests. Each time I want to add some new functionality there, I'll write a case for it and then come up with an implementation. This way I can guarantee the documentation and implementation will stay in sync.
Placidity
I dug this old project out of the attic and added some polish to it. Now it's semi-useful. Basically it's a Python REPL that sits on top of your terminal. I don't really use it these days, though. Perhaps this is something that could be evolved later on into a more interesting direction.
colorjs
I wrote this little library since I wasn't too happy with the available color abstractions available for JavaScript. So like a good NIHist I went on and wrote my own. I like the simple yet powerful API. There are a couple of projects where I intend to use.
I have some color picker (pure CSS) code hanging around. I want to hook that with this library and get that released at some point.
bunit.js
bunit.js is a testing library which I developed in order to test colorjs properly. It was built heavily on top of my earlier experiments with a chaining assert statement and runner pattern.
This is another library that'll remain in my toolbox. I guess one of the coolest things about bunit is that it makes TDD quite effective thanks to it browser based test runner. Basically it will just reload the page till you tell you to stop. This often allows you to spot mistakes as you make them. Highly useful!
Conclusion
That was quite a bit of projects! The listing is actually missing my fiddling with Turtles and CSS preprocessing. I intend to develop especially the latter further in some kind of a series of blog posts. There are a few ideas I want to give a go.
I have some work still under wraps. Hopefully I'm able to release some of that work during the next year. I probably need to focus on a smaller amount of higher impact projects anyhow. :)
Other Highlights
I managed to develop my programming skills further quite a bit. Especially JavaScript feels solid these days. It's one my favorite languages along with Python and Lua. Delving into Haskell gave me some extra insight into these. I'm still far from being an expert at Haskell. It's one of those languages you'll have to learn not because you want to it but because you want to get more out the languages you actually use.
These days I believe functional composition is superior to class based. It's simply more flexible and doesn't force you into a corner as easily so to speak. Many functional patterns are highly useful beyond purely functional languages. Generally I don't mind mixing different paradigms to suit the given problem. Just sticking to one seems bit of a waste to me.
JavaScript
One of the biggest problems I've always had with JavaScript is that it really doesn't have a proper module system like Python for instance. Fortunately things appear to be changing. Around a year ago I came upon this little project known as RequireJS. Effectively it allows you to structure your project in a modular manner. Basically you just state your dependencies, implement something and state what your module exports for others. This simple pattern is all you need.
RequireJS enabled me to write a relatively large Canvas based drawing application. I've shared my notes about it at my overview of JavaScript application development. It would be interesting to expand that document further and convert it into a book of some sort with proper introduction to Canvas and similar technologies. There might be room for yet another book on JavaScript.
Pretotyping, Wireframing and Lean UX
I went to a course about User eXperience (UX) early this year. It really changed the way I think about development. Particularly Cooper's "The Inmates are Running the Asylum" was influential. I don't entirely agree with all of his points. I do think he's onto something by saying programmers and actual users think differently, however. It's up to the UX designers to bridge the gap. This in turn makes it easier for us to deliver concrete value to the users. It doesn't hurt if programmers can be empathetic towards real users.
The concepts of pretotyping, wireframing and lean UX are closely related to this. Just like with testing, I believe we can gain most out of UX design by moving it early in the process. It's not something you can do last and expect to produce a stellar product. It just doesn't work that way. Same applies for quality by the way. It's not something you can control later. It's something you have to build consciously within.
Does this mean we should move back to BDUF (Big Design Up Front)? Not at all. It's good to do some design upfront and then get some actual feedback to drive the process forward. Software development is by essence a feedback driven process. This is incidentally one of the core tenets of both agile and lean.
Conclusion
There are many other posts in the blog I didn't cover in this overview. Explore and you might find something interesting. To be honest the blog is bit of mishmash and the type of writing tends to vary. Lately I've been writing these longer articles. I might shift into shorter ones again at some point.
I'll continue writing on my projects and interesting concepts I come by. As I mentioned somewhere along the article I have some material I want to develop further here. Actually the recent post about immaterial rights was born this way. I took something I had researched before and turned it into blog format. The coolest thing about this is that it allows me to be as informal as I like. Blogging is way more fun than academic writing. :)
I hope you have a great 2012! If you happen to have some specific ideas on how to make the blog serve you better, let me know in the comments or just drop a message. It has been nice to see the blog evolve. :)