Read my book

I wrote books about Webpack and React. Check them out!

Tuesday, March 23, 2010

Garbage In, Garbage Out: Challenging the Notion of Teaching Computer Science

I just came upon this interesting article. The basic premise is simple, we are teaching people to program the wrong way!

Traditionally programming is considered an art to be learned by doing. This is known as constructivist approach. I agree with this approach to some extent. I think the key here is understanding that it's not a good starting point.

Instructionists offer another school of thought. According to this school, it's better to provide full examples and learn by examining them. This is where studying existing programs, their architecture and code comes in.

In principle programming is just an act of understanding structure. Reading code gives some idea on how to solve problems. Of course to truly understand the code you need to learn the constructs which isn't a bad thing itself.

Just to conclude this post I think it would be a worthwhile idea to introduce courses aimed at reading code besides just writing ones. Good design and code should be given the same value as literary and art classics. To give some idea of the current situation imagine if we taught people to write before they can read properly. Would that work?

Sunday, March 21, 2010

Harmony - New Experimental Features, Mirroring, Constraints etc.

I mentioned about Harmony in an earlier post. Harmony is HTML5 Canvas based sketching application. It's extremely light and doesn't have much bloat, yet. ;)

I glanced at the code about a week ago as I had a couple of ideas I wanted to implement. The problem was that it was formatted badly and contained some extra code that needed to be gotten rid of. Fortunately rhyolight managed to do this. In the process he added a couple of new brushes to Harmony. You can find more information about those at his blog post.

With source code available I was inspired to hack around a bit. I ended up implementing following features:
  • mirroring (x, y, radial)
  • "sticky" palette (shift). Note that it's not possible to paint under the palette!
  • vertical constraint (hit s while painting)
  • horizontal constraint (hit a while painting)
  • perspective constraint (hit d while painting, set target with f)
Constraits mimic the perspective system implemented in "Digital Painter" except that it's only 1D. :) It probably would be a good idea to add support for more targets and a way to cycle between them but that's for some later time.

Note that mirroring has been implemented so that it's possible to use multiple mirrors at once. Give it a go.

rhyolight appears to host quite a recent version here. It's missing undo but otherwise it should be ok. You can find a version with an early implementation of undo at my development branch. It might be cool to make it a bit faster and add playback.

Feedback on the features and ideas are welcome as always of course.

Sunday, March 14, 2010

Speccer - Early prototype of a specification based test runner

I came upon this post by Steven Kryskalla today. From my perspective it managed to solve one major problem, the inadequate output of assert! I know Expecter gadget can do it but still his approach seemed like a cool one. I was also inspired by the way he specified tests. Instead of doing the regular "test_" mambo, he just dropped that notion and moved into more BDD'ish direction with his naming scheme.

I decided to take the idea a little bit further. What if specifications were defined in less technical way? Enter YAML. Here's my version of the specification mentioned on his blog:



Note how simple the specification is now. I bolstered the implementation with set_up to get rid of some redundancy. There is probably some work still left in semantics but to me that strikes as something more readable than regular tests with asserts etc.

Here's my initial, extremely hacky implementation of a test runner:



And here's an implementation of the specification:



The runner is extremely limited and is pretty much guaranteed to work properly in this case only. It would be somewhat interesting to extend the idea further to work with system tests ie.

Friday, March 12, 2010

Linkdump 1

I tend to accumulate quite a few bookmarks while surfing the net. I suppose it might be fun to share some of the most interesting ones. Here are the ones for this week:
  • Harmony, a procedural drawing tool. It's based on HTML 5's canvas element. You can find technical details here.
  • Tonematrix, a simple sinewave synthesizer. Just paint and have fun making music in the process.
  • Xerxes, ambient music for coding sessions. I'm more into progressive and heavy rock but I digress.
  • Automata based programming with Petri nets - Part 1. Now that sounds interesting. It kind of reminded me of DAGs.
  • Data compression explained. Now that's what I call a comprehensive look at the subject.
  • Git tricks. There is some nice information about git condensed.
  • Django flowcharts, [1], [2]. If you want to know the anatomy of a Django beast, check those out. They might help to explain a thing or two.

Sunday, March 7, 2010

Book Review - Grok 1.0 Web Development

Disclaimer: I received a review copy of this book from the publisher, Packt Publishing.

 I had not heard of Grok before being asked to review this book. As it turns out, the framework is based on Zope. That rang a bell as Zope forms the core of the famous Plone CMS.

Compared to the popular Django, Grok is currently somewhat lesser known. Even though both Grok and Django are based on the MVC paradigm there are some vital differences between the two. It appears that by design and Zope Grok applications seem more extensible than ones written in Django. Sadly Grok appears to miss admin interface that's provided with Django by default although it would not surprise me if there was some Zope extension that fills this gap.

The description of the book states following:
  • Develop efficient and powerful web applications and web sites from start to finish using Grok, which is based on Zope 3
  • Integrate your applications or web sites with relational databases easily
  • Extend your applications using the power of the Zope Toolkit
  • Easy-to-follow and packed with practical, working code with clear explanations
I think the book manages to deliver on its promise really well. I will elaborate on this and its content in detail next.

Friday, March 5, 2010

Fossil DVCS on the Go - First Impressions

I have been using Fossil DVCS (Distributed Version Control System) at work for a couple of weeks now. I thought it might be interesting to share some of first impressions of the system.

I came by Fossil while searching for a small self-contained and full featured version control system. I wanted something I can run easily portably from an USB stick. It's quite nice to have a development environment in your pocket. :)

Fossil seemed to fit my requirements fine. I did consider using darcs, git and Mercurial but I ended up testing Fossil just because it provides some interesting additional functionality not usually seen in DVCS systems.

Fossil is not just a DVCS, it contains a wiki, an issue tracker and a proper web interface as well! I don't think there are other DVCS's that can compete it in this regard. In this sense it has managed to find a nice little niche for itself.

I found the quickstart documentation quite instructive. It's a bit sparse. You might want to take a look at this page for further discussion on the basic concepts its built upon.

I was a bit confused about the meaning of "open" and "close" commands at first. Apparently "open" extracts the actual files from a repository and creates a local checkout while "close" gets rid of it [1].

In case you are using a repository set up on your portable device (USB stick, ie.) it's important to remember to "close" the repository once you are done with your development work. This will get rid of local checkout information (__FOSSIL__ file) and allow you to open the repository yet again later. If you forget to do this, it's possible that the local checkout points to the wrong place as the path to a portable device is not guaranteed. This may manifest itself as errors while trying to do something (ie. show the web UI, commit, ie.).

It's possible to fix this situation by getting rid of the aforementioned __FOSSIL__ file and by opening the repository again. Note that in case you have made some local changes you with to retain, you should use the --keep flag ("fossil open --keep").

I have found the lack of native support for recursive "add" on all platforms bit of a nuisance. Fortunately there appears to be a nice workaround for this. Anyway that's easy enough to fix properly with some scripting.

Overall I have found Fossil a nice little system that's surprisingly full featured. In case you happen to do portable development, check it out.