Thoughts on Kasvu Open Forum and Djangocon Finland 2012

Two days, two conferences. The first was a local, business oriented one, Kasvu Open Forum. The second, Djangocon Finland 2012, focused mainly on technology. I gave two talks in the latter one. It was very nice to experience both events and meet some new people and a few old acquaintances.

Kasvu Open Forum

Kasvu Open is a competition of sorts aimed for Finnish growth ventures. This is the second year they are organizing it so things are just about to get rolling. They have two series, one for ideas and one for established companies. Me and my business partner participated in the former one this year with an entry.

We didn't make it to the finals and weren't impressed by the quality of the feedback given. This event totally made up for it. This is definitely something they can improve on the next year. The last thing you want to do is to discourage some potential idea or company. After all Kasvu Open is in the business of creating new business.

You might expect business conferences such as this to be really boring. This wasn't the case here. Each talk given gave some unique view to growth venturing. For instance it was particularly interesting to see how different the mindsets of a venture capitalist and a business angel can be. Former focuses on profit while the latter thinks in more long term and uses a different kind of investment strategy.

I also enjoyed the talk of Jouni Hynynen. He represented The Foundation of Finnish Inventions and explained how immaterial rights relate to business and what is their worth in practice. Even though I'm somewhat categorically opposed to concepts such as software patents, the talk gave some nice insight to the subject.

Overall it seems like there is some positive buzz going on in the Jyväskylä area. It might not be the Silicon Valley and we might be missing the scale benefits. I wouldn't be surprised if something really interesting emerged from the area within the next decades.

Djangocon Finland 2012

This was the first time I visited the Finnish version of Djangocon. I think there were around forty people or so participating the event. The talks were primarily technically oriented. There were a couple of longer talks and several lightning talks.

I actually met a reader of this blog (apparently there are those) at the conference. That was quite a pleasant surprise to be honest. It's small things such as this that make it all worth it.

Thoughts on "Kaleva.fi - how we replaced 10 years of legacy code in one year"

It was particularly interesting to see what Kaleva.fi looks like from "outside" in terms of DevOps. I participated in the project as a software designer during the past year for a period of a few months. So I got to know certain bits of it quite well. I never really looked into the overall infrastructure (too busy staring at my code :) ), though.

There were many interesting tidbits in Markus' talk. Especially the bits on scaling the service were interesting. It's quite different to develop a service used by hundreds of thousands than something that has only a few users. You get a lot of new problems to solve.

Thoughts on other talks

There was this one guy that made Django act like PHP. Django Home Pages is a terrible abomination that simply should not exist. I guess that was kind of the point, though. He created it just in order to see if it can be done.

Leo Honkanen discussed about classy Django applications. I think the main gist here was that with some effort you can provide namespaced url lookups for your templates. Essentially you have to deal with routing using a proxy class that implements urls using a property. The proxy class contains the name of the namespace as a class level attribute. I believe it is possible to implement this as a class method so you can avoid instantiating the whole thing at your url definition.

I'm not entirely sure if one should abuse classes this way. There might be a neater functional solution around to be found. If I ever need to namespace my urls somehow, I'll keep this in mind.

There were a couple of lightning talks as well. The BDD one was semi-interesting. I couldn't see myself writing that amount of code anytime soon, though. There must be some nicer way to describe stories.

bongaus.fi - Spotting Service Powered by Django

My first talk had to do with a service me and my business partner developed during the Spring. We did the development of bongaus.fi in a few distinct phases. The idea of the talk was to give some insight how we created the service and what kind of lessons we learned while doing it. I hope the people got something out of it! You can examine the slides below (probably not visible in RSS):

bongaus.fi - Spotting Service Powered by Django

View more presentations from Juho Vepsäläinen

If there is something you should pick out from the talk I believe it is the importance of developing a Minimum Viable Product (MVP). The only way to know if your product is on the right track is to give it for your users to test. Developing a MVP is an effective way to do this. Besides, it is really fast to get one done since you don't need to get stuck on the details.

In development of bongaus.fi we noticed Pareto principle applies quite well here. It takes only perhaps 20% or so time to get the relevant bits done. The rest is just tweaking and dealing the corner cases. And boy that sure can take time.

Another important thing to pick out is the value of pivots. Even if you are doing something and going to a certain direction, doesn't mean you should be going there indefinitely. It can pay off to adjust the trajectory and try something perhaps a bit different. I believe the willingness to pivot is one of the key attributes of startups that become successful.

Speccer

My second, really brief talk, had to do with Speccer. It is a small testing tool I developed ages ago to make using unittest bearable. To quote myself "unittest provides testing for masochists while Speccer is meant for the rest of us". I hope the slides below give you the gist of it:

Speccer

View more presentations from Juho Vepsäläinen

Essentially the tool just transforms the light Pythonish syntax (you can mix Python with it) to code using unittest. This means you get to enjoy from the benefits of the both. You get the robust output provided by unittest's test runner while get to use a lighter syntax.

Conclusion

At times I feel like I'm slowly drifting away from a pure development role and more into business. These kind of conferences seem to confirm this. It takes a lot more than just technical skill to make things work in a real world.

Overall it seems like a good idea to be active. You get a lot of new contacts that in turn might prove to be valuable longer term (applies both ways). In addition these sort of events give you a nice extra burst of motivation and helps you to validate some of the work you have done. Sometimes it is a good idea to step out of your role a bit and try something different (ie. a business conf :) ).

The Importance of Development Hygiene

Believe it or not, hygiene has a lot to do with software development. It is one of those things you'll notice when you delve into a new codebase. Having good hygiene habits can help in getting a fresh codebase on a decent track. Often poor hygiene results in some form of technical debt and eventually slows you down. This is one of the reasons why maintenance work is so expensive in the realm of software.

Development Hygiene - a Definition

Hygienics is often defined as a science that deals with the preservation of health. Even though we deal with hygiene in a rather different context than software, the concept translates well to here as well. Healthy codebase is a happy codebase.

Consider that you are just about to start working on a maintenance project and need to set everything up to get the thing run on your development environment. You'll likely need to fetch and possibly build a bunch of dependencies, perhaps set up a virtual environment even. If you are unlucky, it might take a while to get all of this done.

This is actually one way how hygiene shows up in practice. If the project has been set up properly, you probably won't have much trouble getting to speed with development. One solution to this problem is simply to package the whole development environment in a ready made snapshot that you can simply run.

Just getting the project run and build isn't enough. Next you'll probably need to some real work. Time to open up the maintenance hatches and dive in. What you'll find can vary quite a bit. With some luck you might have some documentation available. Otherwise you might need to poke around a little and see what does what. Eventually you'll get around the codebase and will be able to contribute to it.

Besides documentation there might be some scaffolding, ie. tests, that describe boundaries of the system to some extent. This kind of scaffolding makes it harder to break things accidentally. If you are unlucky, there might not be any or the ones that are there are faulty somehow or simply won't run. In order to learn how the code is supposed to work it might not be a bad idea to write a few tests to assert your hunches. These will likely become beneficial later on.

Sometimes documentation might be somewhat non-existent as well. In this case it isn't a bad idea to jot down some notes. You'll thank yourself the next time you'll need to touch that steaming pile of ... code.

One of the first things you'll notice while delving into a new codebase is style, or lack of it. The way the code is written tells a lot about its writer and the project even. If you are seeing a lot of defensive coding around, you can bet there isn't a lot of trust in the organization. Huge swaths of comments probably imply that there is some kind of a bureaucracy in place. It's not that comments are bad, there's a certain limit, though.

Why Development Hygiene is Important?

Often we just write code in a hurry and hope it works. As I mentioned in a previous post of mine, developing fast isn't necessarily the fastest way to get things done. Even though you might be or feel fast for a brief period of time, the reality will sooner or later catch up with you.

Maintaining proper development hygiene makes it easier to go faster. Quality is fractal. If you can keep the quality of a codebase high, you'll likely be able to go faster longer term. It is alright to do some quick hack jobs at time just to see if something would work, you'll need to remember to clean up later, though.

As postulated earlier you or your successor will bump into hygiene once he needs to maintain the work you've done. I believe maintaining a proper hygiene is one of the key ways in which we can make software maintenance cheaper.

Conclusion

I hope this post gave you some idea why I believe software hygiene is important. It is alright to write trash at times as long as you are aware of it and don't make that a habit. In the realm of software sometimes the best way to attain knowledge is to write some code just to throw it away. If you want your software to be maintainable and fun to work with long term, keep software hygiene in mind, however.

Thoughts on Static Websites and CSS Frameworks

During the last few months I've done quite a bit of work with GitHub Pages and CSS frameworks, namely Bootstrap and Skeleton. GH Pages is just the perfect way to host a light static site. By default it provides support for Jekyll, a static site generator. You can use it to host vanilla HTML if you want so you are free to use whatever generator you want.

Jekyll is quite good at what it does. It has its limitations, though. Implementing a site with complex navigation using it can be an exercise in frustration. Probably the biggest project I've implemented using this combo is the site of my co-op. I wrote an article about the design process that you might want to study. Overall it was a nice learning experience.

Around a week ago we had a local meetup. This gave me a chance to capture some of the experience gained in a few talks. In this post I'm actually going to discuss only two of them. I'm saving the third one for a later post.

Static Websites - The Final Frontier

I admit the title of this talk was somewhat cheesy. For some reason I decided to use a Star Trek theme for the talk so the title seemed quite apt. What do static websites and Star Trek have in common anyway? In my view old is new and new is old again. Technology works in a cyclic manner. Old ideas get replaced with new ones and then become trendy again. I believe building websites in a static way is one of these.

Even though static sites are static by definition (ie. the server doesn't generate some snippets "on the fly") it is possible to develop some quite interesting features by relying on JavaScript. For instance you could fetch some social data (ie. tweets, RSS) without too much effort. If you want to take this one step further, you could treat this sort of data as "static" as well by rendering that data on the server say once per hour using cron.

The presentation below will give you some more insight to the topic. It's based primarily on a few case studies. There's a little bit of theory included as well.

Static Websites - The Final Frontier

View more presentations from Juho Vepsäläinen

Bootstrap vs. Skeleton

On retrospect I should have made this talk Batman vs. Joker themed... Oh well, perhaps next time. Bootstrap and Skeleton are just two of the many CSS frameworks available. They provide nice basis for comparison, though, given they have quite a different focus.

Generally CSS frameworks encapsulate some common CSS related woes and make it a lot easier to get started. In this case both frameworks provide responsive layout even. It probably won't be ideal from usability perspective but likely a lot better than you could do on your own in a tight schedule.

Responsive design progresses from desktop to mobile. Lately an opposite way of thinking, mobile first design, has gained some popularity. It will be interesting to see if that affects the frameworks somehow. In a way thinking about mobile specifically makes sense. You just cannot leave it to luck and hope it works. Due to the wide variety of mobile devices available this isn't unfortunately an easy problem to solve well.

As there is a lot of discussion available on the pros and cons of using CSS frameworks I won't go into that. Suffice to say that using them can definitely make a difference. Consider giving at least a few of those a go just to see if you get anything useful out of them. For me just getting a useable grid layout was a huge thing.

For now I've settled with Bootstrap and Skeleton. Skeleton is just perfect for simple projects while Bootstrap provides plenty of room for growth (lots of functionality!). They are not ideal semantically, though. Apparently the semantic grid system ought to provide a nice solution to this although it provides just the layout.

You can find the presentation slides below. There aren't too many of them but hopefully I managed to get to the core of it.

Bootstrap vs. Skeleton

View more presentations from Juho Vepsäläinen

Conclusion

I hope this post gave you some idea how static websites are relevant even today. Sure, it might be a blast from the past but perhaps a bit surprisingly you don't need a fancy CMS to create a simple site to serve you well.

If you haven't used a CSS framework before I recommend picking up some of those and giving it a go. I have to admit I was a bit skeptical at first. After the initial period of puzzlement I've managed to see the value they provide. They're particularly useful if you don't happen to have a huge team of coders to help with these thing though I've no doubt they'll be handy in a team environment too.

Partial Application is to FP as Inheritance is to OOP

While developing suite.js, a testing tool of mine, a had an epiphany of sorts. Partial application is actually more or less equivalent of the concept of inheritance in object oriented programming. In other words you go from general to specific. This little insight made me rethink the way I construct my functions.

If you don't know how partial application works yet, don't worry. It is simply a mean to construct new functions that perform some specific task. The classic example goes something like this. Suppose you have a function "add(a, b)". Using partial application you could construct a specific one such as this: "var addTen = partial(add, 10)". Now only parameter b remains free (ie. addTen(12) yields 22).

As suite.js relies on partial application quite heavily, this means that in order to test some function I'll need to make sure the parameters have been ordered from general to specific. I simply lock the generic bit and test the specific one using a suite. I know it's a small thing. Still, it's cool to have small epiphanies like these every once in a while.