Turning ideas into applications

If you're anything like me you'll frequently come up with ideas for neat applications. For me, turning those ideas into code is the challenge. It's not that I'm incapable of writing code - I have more than enough experience to write simple applications. The problem is that I lack the enthusiasm and energy to complete my projects.

Looking back over the projects I have completed, I notice a pattern. In order for me to complete a project, one of two criteria must be present:

• I need to be paid. Money is a great incentive. Think this is shalow? you're probably right.
  
• I need to be working with other, like minded individuals. There's nothing more rewarding than working with a bunch of intelligent people who are as excited about the product as I am.

For commercial projects, the former requirement is enough to get me to do my work. For open source projects however that is a luxury don't have.

So, getting back to the original problem - how do I turn a half baked idea for an application into an open source project with 2+ developers? Traditionally the process has been something like this:

1. Have brilliant mind-blowing Earth-shattering revolutionary idea.
2. Start writing code.
3. When code gets slightly usable, create a sourceforge project and advertise project page like crazy.
4. Hope that some like minded developer notices it and wants to join in.

There are several problems with this approach. First, sourceforge is littered with projects that have 0% activity. These ghost projects have long since been abandoned by all the developers (I swear they're not all mine!).
Second, you only have a chance of attracting new developers to your project after you've written a good chunk of the code. This forces new developers to learn the code that has already been written, and prevents them from offering any input as to programming style, programming language, libraries, code organization, feature list development strategies etc. etc. Personally, I think that one of the best parts of working on an open source project is having the opportunity to makes these kinds of decisions.

It seems to me that what we need is an ideas forge. Imagine a place like sourceforge, but for ideas. There would be facilities for advertising ideas, giving feedback on existing ideas, hosting design documents, holding discussions etc.

Unfortunately, ideaforge is an... idea.. Now all I need are some talented programmers to help me create it....

KDE 3.X: The good, the bad...

I Love KDE. With the final KDE4 release just around the corner, I thought it'd be good to note down some of the best and worst features in the 3.X series.

Why KDE?

I use KDE exclusively on all my Linux boxes. Why? It just... feels better. I've tried several alternatives - XFCE (which I like very much, but it lacks some of the features I need), WindowMaker, Fluxbox (great on a low-end PC), Enlightenment (supposedly the nicest looking window manager for Linux), and Gnome. Gnome is, of course the main competitor for number of users. It's the default window manager for the Ubuntu project.

With so many other choices, why choose KDE? There are two main reasons:

1. It is incredibly configurable. There are so many options I could spend a whole day setting up a new install. Some people say that this is a bad thing, and it certainly is for a novice user. Who wants to be bombarded with configuration screens? However, I consider myself a power user and enjoy the added flexibility.
   
2. KDE features brilliant integration between it's apps. Thanks to the KPart technology (Think OLE done right for Linux), it's very easy (from a programming perspective) to embed one application ( or "KPart" inside another.

The Good:

As far as I'm concerned, the best featured of the KDE 3.x series are (in no particular order):

• Window Management. I personally Love the "Keep Above Others" option - it allows you to keep a window above all other windows on your desktop. Some windows applications can do this, but I've found that they don't play nice with the Alt-Tab task switching when they do.
  
  In KDE, this feature is part of the window manager. Application programmers get it for free! You can also do the reverse ("Keep Below Others"), or enable full screen mode (no prizes for guessing what that does!).
  Another useful feature is te ability to customize the behaivour of any window - either just once, or every time that window is created. For example, I may want my IRC chat client to always start at a specific place on the screen, have it stuck to the bottom of the window stack, and disable thew window decorations. With KDE, this is all taken care of by the window manager. Neat huh? but we're just getting started...
  
• Kate is a brilliant text editor for KDE. I use it for all my programming (well, sometimes I'll revert back to vim). Out of the box it supports syntax highlighting for hundreds of languages, code folding, and a whole lot more. you can download plugins to extend the editor too. One of the main reasons I use it above other text editors is the built in Konsole (thanks to KPart). This is so increadibly useful i can't imagine life without it.
• Other KDE applications that I use every day and love include Konversation (IRC client), Konsole (guess), and Amarok (best music player you ever did see!)

I'm aware that other window managers may have similar features, especially the larger ones, like Gnome.


The Bad:

Nothing is perfect, and KDE is no exception. Here are a few of the things that I don't like about KDE.

• Konqueror. Konqueror is KDEs default web browser, file manager, and a whole lot more. My main gripe is that it's trying to do too much at once. When you think about it, browsing the web and browsing your hard disk are two very different tasks. Konqueror tries to achieve this balancing act by working in "modes". Sometimes it looks like a web browser, and some times it looks like a traditional split-pane disk browser.
  
  The web browsing features are okay (I especially like the fact that typing "gg: foo" in the address bar searches google for the word "foo"), but why try and compete with Mozilla firefox? The first thing I do on a new KDE installation is install firefox and remove all the konqueror shortcuts. Firefox is already well known amongst computer users. Why not put more energy into integrating firefox with KDE?
  
  The disk browsing side of konqueror is rather tragic. My main gripe is that by default, clicking on something opens it. A single click! Users migrating from windows will find this very confusing. If you just want to select something you have to hold down the Ctrl button.
  
  It seems that in KDE4 the disk browser part of konqueror is being split out into a separate app called Dolphin. I can't wait! Now if we could just ditch the rest of it...
  
• Lack of Xinerama support. I run a dual (and sometimes triple) head setup at home. KDE has very limited support for Xinerama. For example, I'd like a window decoration button that lets be move an application to the next / last / other screen, even if it's maximised. Ultramon for windows gives me this, and it's very handy. Several applications will always display their "fullscreen" mode on the first display only, which is a real pain (especially since my first screen is my laptop).
• The K menu needs a lot of work. Mine tends to get cluttered very easily. It'd be nice to have some easy way to organise applications into frequently used groups.
  

All in all, I'm not complaining. If I had more time I'd try and improve KDE myself, but I'm rushed off my feet as it is!

Book Review: Begining Game Development with Python and Pygame

I love Python. I Love Pygame, and I love programming. What could be better than a book that combines all three?

These were the excited thoughts that were racing though my brain as I was looking for a suitable money sink on amazon. The book's subtitle is "From Novice to professional", and I wasn't expecting much. You see I have a tendency to buy books that I don't really need. I already know a fair amount about programming with Python, and I've used the Pygame library on numerous occaisons. So why buy the book? I was hoping that the book would stimulate me to finish one of the hundreds of half-completed game projects on my hard disk.

The book has 12 chapters in total. The first three are a gentle introduction to the python programming language and the pyGame module. The next four chapters are the meat of the pyGame related matter. Most of the pygame modules are covered here. Finally, there are four chapters covering 3D aspects and OpenGL.

As you may already have guessed, I'm not overly impressed with this book. My main gripe is that the content doesn't reflect the book title. For example, Apress (the publisher) have included a little diagram on the back of the book (I appologise for the poor image quality):


To me this indicates that the book in question assumes a working knowledge of python. Why then the four chapters introducing the programming language? Similarly, the last four chapters of the book are about OpenGL and 3D game programming, which bear very little relevance to PyGame, which is primarily concerned with 2D applications. The books chapters also seem a little jumbled together. For example, there is a chapter on playing sounds in the middle of the 3D chapters... where did that come from?

The chapters that were on topic were pretty mundane - the reader might have just browsed through the superb PyGame documentation.

Overall, this book probably isn't worth buying if you want to learn how to use Pygame, just read the online documentation. If you want to learn Python or OpenGL, there are better books out there. This is a book with great potential. If the author had stuck to the subject matter this book would have been a lot better. A few constructive criticisms then:

1. Lose the Python into and the OpenGL stuff. People will buy this book because it has the word "PyGame" in it. We don't care about OpenGL, and we already know how to program in python!
   
2. Make the example a little more meaty. At the moment almost all the examples demonstrate simple pieces of the pygame library. Some examples that demonstrate how these pieces are put together to form a playable game would be nice!

I did actually enjoy reading the book, it wasn't a complete waste of money. I'd give it 5/10. It was enjoyable to read, and did contain some useful information, even if that information was present in a better form on the web.


Now, If I could only get around to finishing that game.....

Filthy Lucre in the United Kingdom

As I sat on a train in Waterloo train station today I noticed that two large credit card companies were touting the end of cash as we know it. The first is the mastercard "CASH" billboards (sorry, I couldn't find a photo online). The second is VISAs "paywave" system.

I would like to take this opportunity to point out to both credit card companies that cash is not dead. The main reason is that card machines are still not universal. I come from a country where every store, no matter how small accepts bank cards. In the UK however, it seems that only larger stores bother with electronic bank cards. I suspect that the banks are behind this.

Let's not introduce yet another form of payment before we've made the current forms universally available! Drop bank charges for companies wanting to accept credit cards (after all, it must result in fewer bank tellers handling cash, which can only be a good thing, right?), and lets make electronic purchasing
universal!

Programming without Requirements?

I had the opportunity to catch up with some old college friends of mine recently. We all graduated together, and we're all working as programmers in a variety of industries around the world. I work in broadcast automation, another friend works in publishing, another in engineering.

Eventually we began talking about our jobs. What struck me was that none of us are happy with the way our programming is being directed. Let me be a little more clear...

In college we were all taught that requirements determination is a fundamental step in producing quality software. This makes sense - after all, how can you write good software if you don't know what it needs to do before you start writing it?

Unfortunately, none of my friends feel that requirements determination is given the focus it deserves. It is, of course entirely possible that we were unlucky; three is a very small sample size to make sweeping generalizations about the entire programming community. However, I'm going to do just that!

All three of us had been in a situation where we were being asked to program something without having a very good idea of what the required outcome was. As it turns out, I am in this situation right now (Actually, I'm writing this blog entry as a venting mechanism so I can sleep tonight). I'm being asked to write a plug-in module that will take me at least a month of solid programming. What does it do? I wish I knew!

Don't get me wrong - I have a rough idea of what it needs to do. However, I have no formal requirements, no use cases, no user stories, no access to the target environment or system, no protocol document, and no access to anyone who knows any more than I do. Frustrating? you bet.

I understand that in a project-driven environment sometimes some of the requirements may change - I accept that. However, I really think that there needs to be more attention paid to the period of time before any code is written, so that hopefully programmers can spend less time writing code, less time fixing code that was poorly written, and more time drinking beer!


If anyone has similar stories, or can tell me that I'm being naive, I'd love to hear them (for the record, I don't think that naivety is such a bad thing - sometimes it takes a little innocence to spark changes for the better).