Voice Steam

Remember the old saying “Once you know a thing’s name, you control it”? That wisdom is encoded in one of the most important aspects of the Scrum team software development practice: having a backlog. A backlog is, simply put, a gold plated TODO-list.

I’d like to explore the possibility of generalizing that concept -”having a backlog/TODO-list is the most important thing” – to life as a whole. That is, a system where you can add TODO items for everything you want do in life might be a good idea.

For that to work practically, one must be able to categorize each item (house, garden, car, project X/Y/Z, ..). So each “item” has to be taggable/categorizable. I prefer taggable, because it’s not as hierarchical or black/white as categorization.

So you could add items:

• fix lawn
• media server PC
• democracy flyers

.. each taggable with text strings:

• fix lawn [garden, home, good weather]
• media server PC [home, indoors, money to spend]
• democracy flyers [politics, indoors, time to spend]

All those tags would create a wordcloud, which could be an important way to navigate in the system. One question that arises is Which sort order? Sorting is important as a way to prioritize what to do soon, and what to do later. But since we’re talking different contexts here, not a single (as we are when developing a product in Scrum), we have to think a little extra. Should we sort per tag? That would mean a lot of maintenance. Maybe simply sort issues themselves, and then use that information when viewing a tag/context?

Implementation note: I think this system would fit well as a Web2.0 JavaScript App with lots of interaction bling. That is, trivial to add/remove/rename both issues and tags. And of course easy to search (either using freetext search “google style” or by clicking a tag in the tag cloud).

Bonus: One thing that I use personally a lot when writing down TODO-lists is “dependency arrows” or “impediment arrows”. That is, an arrow from B to A means that A must be finished before B can be done. But that might be polishing the shue before there are laces.

I’m proud to announce my first project-specific URL: pytddmon.org!

Please visit, and by all means if you feel like it try pyTDDmon out. And gimme some feedback – either on website, pyTDDmon or both

I’ve started learning about the 2D-games-development environment called LÖVE at love2d.org.

Basically, it wires together lots of “de facto standard” multimedia libraries (like SDL/OpenGL, OpenAL, DevIL) and ties it up with the minimalistic scripting language Lua (visit lua.org).

I really like the idea, and have brought up the “Hello World” on my screen in less than 5 minutes from visiting the page.

Now the downside of this is the syntax of Lua:

function hypot(a, b)
  return math.sqrt(a*a + b*b)
end

While that doesn’t look so scary, I’m not fond of long keywords (function) nor words-as-end-markers. It gets especially visible/cumbersome if you have a couple of nested levels of control code:

function myfunc(a, b)
  if a>b then return end
  while a<b do
    if a==b then
      for i=0,4 do
        print(i)
      end
    end
    a = a + 1
  end
end

I like Pythons syntax much better:

def hypot(a, b):
    return math.sqrt(a*a + b*b)

The second example in Python:

def myfunc(a, b):
  if a>b: return
  while a<b:
    if a==b:
      for i in range(5):
        print i
    a = a + 1

Some might say I’m crazy, but then you haven’t coded that much in both these languages. While I can’t say I’ve coded *much* in both, I do have at least some weeks of effective time in both. These little things do make a difference.

So this is a project idea: write a simple translation program from a Python-influenced Lua dialect, into pure Lua. Let’s end files in this new language with “.love” just for the sake of the newly discovered LÖVE library. What the translator would do is simply translate “def” to “function”, and keep track of when an indentation-block ends, so it can add the appropriate “end” keywords a la Lua.

You up for it?

The last few weeks a lot of programming languages have been piling up on my “would be nice to look more into” stack. I simply haven’t got the time at the moment for that kind of nerd excursions, but I’d like to jot them down:

• Cobra Language. Basically targeting the .NET/mono platform (but I saw Java platform support was on the way), this is a Python-influenced static+dynamic language which I think has a lot going for it. Uses C# as an “intermediate language”, so the compilation process is Cobra->C#->IL. The downside right now seems to be lack of IDE-support (syntax highlighting+code completion is a really nice feature if you’re in a static language). What I really liked about Cobra was the built-in code-contracts + unit testing support. Plus a really fancy “bite-your-tail”-installation process: The Cobra compiler is written in Cobra, and when you download the .zip it contains a script that compiles+installs the whole system, using a “prebuilt/minimalistic” version of the compiler.
• Boo. Quite a lot of similarities to Cobra, being a Python-inspiread .NET-targetting static+dynamic language, but no built-in unit-testing/code-contracts. Also, it doesn’t compile to C# but IL directly. Compared to Cobra it’s more mature with a bigger developer community and some real-world projects using Boo already.
• LuaJIT. I know some Lua already, it’s possibly the tiniest C-embedding language I’ve seen. LuaJIT is simply a really optimized just-in-time version of the ordinary Lua interpreter, making it a super-fast dynamic language (actually almost competing with C in some cases). The downside of this seems to be lack of Unicode support plus the language might be a little too minimal for a big project (but I’m not convinced on that argument). Nagging point: arrays are indexed from 1!
• Rebol. This is something different! It’s a “all batteries included”-approach to programming. It’s designed by an real old-school Guru: the developer of the “exec” functionality for AmigaOS, Carl Sassenrath. REBOL is a kind of modern-day BASIC, if I may say so, focusing on being readable/grokkable also for newbies. I like a lot of the “democratics” surrounding this, with the stated purpose of making programming accessible to more people. REBOL’s got a code demo which is one of the most impressive pieces of “compressed source” I’ve ever seen, cramming Worm+Tiles+FTP and 8 other small programs into one page of code!
• D. This is a more traditional approach: it’s essentially a “better C++” – for real, not just a saying – like C++ compared to C. Built-in unit-testing/code-contracts, neater-than-C++-syntax plus a more thought-through “big picture” on what does belong and what does not in a (real-world) programming language. D impresses me more and more the more I read about it.
• Haskell. This is an old playmate of mine, since University years. I love the syntax and thought-world that is pure functional programming, but I’ve never done a “real-world” program in Haskell (read: complete app/game). I’d like to re-visit Haskell, especially trying out TDD in Haskell.

I’ve been thinking about creating JavaScript 2D simulations on this blog for awhile. It’s such a simple language, and nowadays computers/browsers can keep up with drawing OK graphics without too much work from the programmers side.

Anyway, today I read a description of how competition between companies in a market work, and how it tends towards monopoly. Monopoly is an ‘emergent behaviour’ in the ‘dynamic system of competition’, as a teacher of Dynamic Systems Theory might have put it.

I don’t have time to implement this experiment/visualization/simulation just now, but I drew a picture (above) to remind myself how it would work.

The idea is that of a two dimensional “field“ in which “organisms” move around, looking for the “sun“:

• The field represents “the market”. Different locations represents different “products”.
• The sun represents people buying stuff in the market – what things are popular for the moment.
• The organisms represents companies, and what kind of product they produce (their location).

The sun moves randomly, eg. along line segments, at some certain speed.

The companies also move randomly, but the speed is defined by the size of the company. The size is also a measure of how much “resources” it has (money simply put).

When companies/organisms bumb into each other, they fight. The winner is determined by a random number game, the bigger company has more chances of winning. A is the winner if RND(0,A+B) <= A. The resources from the loser is consumed by the winner, and the loser disappears.

Companies close to the sun gain resources. Companies far away from the sun lose resources at a constant pace.

New companies should be created continously (at a certain pace), with a predetermined size and random location.