Bring It On

As production costs rose up there were fewer and fewer companies making movies. Small studios just couldn’t keep up with the “big boys”, paying expensive actors, shooting on exotic locations and integrating all those cool looking special effects.

Along the way the quality of movies went down too. Since the damn thing costs so much, nobody wants to gamble with a huge investment and we usually get either a sequel or a “by the book” release that brings nothing new to the table. The movie industry is in a sad state at the moment and we have yet to see how if ever will it recover.

Up until recently, it looked like the same thing is going to happen to the gaming industry. The times when a single developer or a small team of friends in a “garage” could build an AAA title are long gone. Modern games cost as much as modern movies and as a consequence we get the same kind of crap – rehashed ideas and boring sequels. The bar is just too high for a small developer let alone a hobbyist.

Not any more. In a relatively surprising move, Microsoft has announced and even started shipping a beta of the XNA Studio Express. Not only is the product free, is based on an already impressive Visual Studio Express line of products, but with it comes what appears to be a very decent API, XNA Framework. Even better, the games produced by XNA Studio Express should run on the PC but also on Xbox 360!

This post on the XNA Team Blog goes into more details on the XNA Framework. The talk is quite high-level so anyone can follow the material.

Great news for small development houses, hobbyists and consumers alike – we should see a lot more original titles, some of which might even not suck. Kudos to Microsoft for lowering the bar for game production and leading by example.

I was under impression that once created a virtual hard drive for VMWare (Workstation) cannot be resized. Not quite.

What you can’t do is resize a hard drive of an VM which is a base for clones without getting rid of all clones and snapshots first. Then just run this command (extending the drive to 16GB, replace myDisk with the name of your disk and 16 with the number of GB you need)

vmware-vdiskmanager.exe -x 16Gb myDisk.vmdk

It’s not finished yet. The problem is that the partitions on the virtual drive are still the same as they were. What you most likely want to do is to resize the partition(s) to match the disk size. If you’re on Windows XP, this might be tricky – the built-in disk manager will not allow you to do this from a GUI.

Fortunately, there is a very elegant solution that’s very easy to use that I mentioned before – GParted. Download the CD image, burn to CD, boot the VM from it and resize the partition.

Note to self: next time create a VM with a large disk size – it expands anyway and only consumes as much real disk space as necessary.

I remember when during this winter holiday season I tried to explain to a friend of mine how weird functional languages are… I used Haskell as an example of a functional language since it is one of the more pure functional languages out there. The first thing I mentioned is that the language does not allow for side effects. Differently put, it means that the constructs you are used to seeing like this

int i = 0;
i = 3 * i;

are not possible in Haskell. He was completely confused – how can one get anything done in a language like this??

Turns out it’s not that difficult, but you do have to change the way you think significantly. The immutability of variables is one of the primary reasons why many developers don’t like XSLT – it just does not fit the way they’re used to think.

Once you get past that point and assuming you are not afraid of recursion (there’s a lot of recursion going on, even if in the shape of pattern matching) you’ll be fine.

Until just a few years ago, besides from bragging rights (knowing yet another computer language), it did not get you much knowing a functional language – it’s not like recruiters are asking for functional language developers in droves. However, the situation will have to change because of something I wrote recently about (multi-core processors): in order to get more performance for your app, you will have to develop for multiple threads.

Just this one feature – immutability of variables – makes multi-thread programming a lot easier with functional languages. I am not saying that all of the sudden you’ll start developing desktop applications in Haskell, but you might end up developing modules in F# if your primary development is .NET based.

Prepare for the inevitable and start learning a functional language today.

I think by now most of the developers agree on the value of the concept of iterators. Instead of looking “inside” collections in order to traverse them we can use a separate concept of iterators and do what we need without knowing anything about the way the collections are implemented.

The iterator is basically a simple concept and is usually expressed as an interface that various implementations conform to. In early Java versions, the iterator was called Enumeration and had two methods:

boolean hasMoreElements(); // returns true if there are more elements to traverse
Object nextElement(); // returns element that iterator is “at” and moves to the next

This is very similar to how early .NET versions designed iterators. In .NET the iterator is called IEnumerator and has one property (syntactic sugar representing a “get” style Java method) and two methods:

object Current; // get current element iterator is “at”
bool MoveNext(); // move to the next element and return false if no more elements
void Reset(); // go back to the beginning of sequence

As you can see, the difference is negligible. The only thing the .NET added was the capability to go “back” to the beginning without having to create a new iterator.

Later Java versions introduced Iterator, another interface to model iterators and this is where things start to stink. Here’s how Iterator looks like:

boolean hasNext(); // like Enumeration.hasMoreElements
Object next(); // like Enumeration.nextElement
void remove(); // removes element iterator is “at” (?!?)

The last method is problematic because it destroys the whole concept of “iterators are the means to traverse the collections”. If you look at all the other libraries that support iterator concepts, you’ll see that remove is usually a method on a collections that accepts an iterator. There is no need for remove method on an iterator.

But wait, there’s more. How do you iterate a List in Java? By using ListIterator (which at least derives from Iterator so not all is lost). ListIterator adds six more methods – things like previous (to move back in the sequence), add (add an element to the end of the sequence) etc. This is wrong – it fragments the concept of iterator (you never know which interface to use) and adds unnecessary methods to the iterator interface.

You could argue that adding something like previous is a good thing - after all, how would one go at iterating backwards if there was not a method like previous? And you would be right – if indeed the bi-directional iterator was deemed necessary, it should have been added to the base interface, not just to the ListIterator.

Contrast this to the latest .NET iterator related concepts. The iterator is still the same (with slight improvement with the introduction of generics) while a few new keywords (yield return, yield break) were added to simplify the creation of iterators (I wrote about it recently). The new keywords are supported by a compiler generating a small state machine so no extra work for the developer nor the need to change anything regardless the iterator concept. Don’t forget – since the very beginning, you could do the very frequent foreach style iteration in the .NET for the same reason – the compiler would generate the code using IEnumerator for you.

The rule of keeping it simple apparently did not ring as true with Java folks as it did with Microsoft. Having a single iterator concept while still improving the language(s) and iteration is possible as the .NET clearly shows. Why Java chose the way it chose is beyond me.

Some people have started just recently thinking about how multi-core CPUs will change the way we developers create applications. Me, I’ve realized it after the article The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software (published at the beginning of 2005) by Herb Sutter, a C++ guru and an architect at Microsoft. Definitely worth a read and some pondering.

In order to use the multiple cores we have and will have the need to start executing code on more than one thread at a time. But this does not come for free – now all the objects/resources accessed from multiple threads need to be protected from access from more than one thread at a time. To do that, all Operating Systems and all programming languages offer constructs for locking.

A detailed analysis and a good tutorial on the .NET (C#) threading is here.

A good example on how not to implement thread safety is Java’s Vector. Just do a Google search on “Java slow Vector” and you’ll see what I mean. Most of the methods in Java’s Vector are synchronized, thus an expensive lock is taken on each call. There is a great two-line snippet in the .NET tutorial linked above that shows why this is not a good idea (the intent is to inset element in a list only if the list is empty):

if (!myList.Contains (newItem)) myList.Add (newItem);

If the thread gets preempted between if expression and the block, the list can still contain some elements because another thread can add them. It does not matter that Contains and Add could (in a naive thread-safe implementation) both be internally protected with a lock. Differently put, the thread safety of collections cannot be implemented properly in the collections library, but by collection user – that’s you.

If you’ve successfully ignored the multi-threading issues, it’s probably time to start improving your skills in this area. 4–core CPUs should be available as soon as this year with 8–core and 16–core CPUs just around the corner.

The free lunch is over indeed.

Just bought a digital photographic camera for the first time (!). The reason for not doing it earlier is that I had digital video camera for years...

I chose Canon Digital IXUS 800 IS (European name), a.k.a. SD700 IS Digital ELPH (US name). The camera is incredibly small and has all the features you’d expect from a modern ultra-compact. Full review at Digital Photography review is here.

Anyway, here's how the view from my office/bedroom looks like:

Hey, I’m lazy – I still run this blog on an ancient (in Internet time) version of the .Text blogging engine. In fact, I wanted to “upgrade” to Community Server (CS) at least twice, but the conversion process has not been as smooth as I’d want it to, plus the configuration is generally a nightmare if you have only a single blog and don’t want or need the rest of the CS features.

The other reason is that I’ve already integrated two “plug-ins” in the .Text that would most likely require some work to fit into the CS and here I am - still running 3 years old codebase. Having this in mind the .Text engine works surprisingly well…

Back to the point: if you’ve tried Internet Explorer 7, you have noticed that going to the RSS feed directly presents a nice HTML page rather than a plain XML view Internet Explorer 6 shows. The screenshot to the left shows my feed inside the Internet Explorer 7 beta 3. Note two things – you can sort entries by more than just a date and you can filter posts by the category. I have clicked on a Ruby category and got back 3 posts out of 10.

Filtering by category does not work by default with the .Text. The reason is trivial – for some reason even though the .Text supports categories they are not listed for each post in the main feed.

You can subscribe to a separate category or look at the posts only for a separate category, but the main feed will not contain them. It’s trivial to fix this though assuming you still have a copy of Visual Studio 2003 around – download the source code of the .Text project, and add the highlighted lines to Syndication\BaseRssWriter.cs in the Dottext.Framework project:

protected virtual void EntryXml(Entry entry, BlogConfigurationSettings settings, UrlFormats uformat)
{
  this.WriteElementString("dc:creator",entry.Author);
  //core
  this.WriteElementString("title",entry.Title);
  //core
  this.WriteElementString("link",entry.Link);
  this.WriteElementString("pubDate",entry.DateCreated.ToString("r"));
  //core Should we set the 
  this.WriteElementString("guid",entry.Link);

  // emit categories too
  CategoryEntry ce = Dottext.Framework.Entries.GetCategoryEntry(entry.EntryID, true);
  if(null != ce)
  {
    foreach(String category in ce.Categories)
      WriteElementString("category", category);
  }
  // rest of the method...
}

Took me just a few minutes to find the right place and fix this because the code is very readable – well done Scott!

If you are impatient and just want the answer, it’s: no.

Now onto the discussion…

When Sun announced generics for Java inevitably people starting comparing Sun’s solution to Microsoft’s who was at the time also working on introducing generics to the .NET languages (C# and VB.NET). There is a fundamental difference in the approach the two companies took – Sun decided not to change the JVM^* while Microsoft went on and changed the CLR.

The most visible consequence of the decision whether to change the VM is reflection – once compiler is done, you can’t reflect over generic types in Java, but you can in C# or VB.NET. There are other differences, but this is the most visible one.

The other consequence of this decision is that you can’t compile .NET generics code so that it can run on older versions of the CLR, but it should be possible with Java. Sort of. Actually – no.

There was an undocumented switch -target jsr14 (instead of -target 1.4) in the beta versions of Java 1.5 compiler where you’d say to the compiler to generate code for 1.4 version and it worked, but this was subsequently pulled. The full discussion on the Sun’s Java forums is here.

The $1M question is: why didn’t Sun change the VM then? Why bother with no changes to the VM?

Here’s the answer, pulled straight from the thread on the forum I just linked to above:

    Because we want to continue running old class and source files with J2SE 1.5.

Ahem, Microsoft changed the CLR yet was still able to run old code on the new CLR.

I think Sun made the bad call here. Not because you can’t cross-compile 1.5 compliant code to older versions of JVM, but because they’ve decided to stick with the minimal changes to the VM. I don’t see any benefit while clearly there are drawbacks, including the confusion with cross-compilation.

^*This is not entirely correct, but is a common misconception, I presume because of the way it was explained by Sun during the process of introducing new features of version 1.5.

I don't really need Windows Live Writer - I've already bought BlogJet, quite a nice web blogging tool that works perfectly for my .Text based weblog. But I can't resist testing a new free tool either :)

I wonder how many sales BlogJet's author will lose because Writer is free and is a part of Microsoft's new Live brand so it might appeal to wide (Windows blogging) audience...

Apart from yet another UI that's almost like one of the versions of Microsoft Office and somewhat like one of default Windows XP styles (but enough different to make it slightly irritating), Writer seems to work fine.

I am mostly impressed with the Web Preview feature: it looks like Writer imported all my CSS and/or analyzed my web page and is dynamically inserting the content of the new post. OK, I'll test image posting while I'm at it - here's how a preview of this post looks like (at the right). Unfortunately, Writer supports only GIF and JPEG images but not PNG (?!?).

Actually, Writer looks and feels a lot like BlogJet and seems to have almost exact feature parity. If I had to pick a tool now, not knowing about BlogJet or wanting something for free, I guess I'd take Writer any day over all kinds of web blogging posting interfaces.

I love Joel’s Business of Software forum. Real entrepreneurs with real day-to-day issues discuss all aspects of their business giving other aspiring µISVs a ton of valuable information.

But guess which post generated the most answers in the recent history? A simple question (I paraphrase):

    I sell a windows desktop app written in VB6. It’s time to move on; what should I pick – VB.NET (C#), C++ or Delphi?

The debate showed that even though some of us claim that we developers are not religious, I say we all are. It’s just that we believe in languages and IDEs instead of something else.

What I find truly funny is that the question was well articulated, yet many recommended the tools they use and feel comfortable with regardless of how different and strange these tools would be to the person who posed the question.

Would you really recommend C++ as a language of choice to a guy who only did VB6? I wouldn’t. Yet, C++ got at least 3 votes.

In the end it looks like Delphi got the most votes. Can’t say I’m surprised – several of the utilities I use or used on a daily basis are written in Delphi. Looks like a nice language and IDE for a one man shop.