Swing Does Components Better Than Component Libraries Do

I'm currently trying to get a handle on Macromedia Adobe Flex using the free, open-source Flex SDK. Flex is a set of tools to create flash-based "applications" using XML UI definition and Actionscript for everything else.

It seems that Adobe has adopted some Microsoft conventions for programmatic UI creation and management. In particular, components in Flex have a long and convoluted lifecycle. In Web Forms, I never understood why I shouldn't create child controls in my Control's constructor; Flex's UIComponent has a createChildren() method. I still don't know why I shouldn't create child controls in the constructor.

In my Swing programming, on the other hand, I don't seem to run across these problems. As far as I know, a Swing component has one and only one step in its initialization process - the constructor. That certainly makes things simpler. I don't have to wonder "What happens if I put this here?" or, more commonly, "Why does this thing not work? Oh, somebody messed up the initialization code."

Actually, most of my frustration here is directed to ASP.NET 1.1. Things may have gotten better in later versions (though I doubt it), and I don't really know how good or bad it is in Flex land. Still, this dredged up bad memories for me. Thick base classes suck!

Why Inheritance Is Bad

3D graphics programmers, if there are any that read this blog, are familiar with gimbal lock. The Wikipedia article makes an analogy to compass directions. If you tell somebody at the north pole to face south, which direction are they facing? You have no way of knowing, because south loses its meaning at the north pole. At any other place on the planet, your location and direction are completely independent. At the poles, direction has no meaning in the cartographic coordinate system. Two previously independent variables have now become linked.

In programming, when you derive from a base class, the classes are in a state of gimbal lock. We can vary the subclass as much as we want without affecting the base class. However, a change to the base class will not only affect our subclass, but every other subclass out there. Suppose that our base class provides some core data processing functionality, and its various subclasses encapsulate different data sources. So far, so good. We've managed to avoid duplication. If we come up with a new data source, we can simply create a new subclass. However, what happens if we want an existing data source to send data to a different set of processing rules? A class would need to have more than one base class, except in a way different from normal multiple inheritance. No programming language that I've seen can support this scenario.

A hallmark of good object-oriented design is that classes have one and only one responsibility. Why is this important? It makes the code simple, it makes the code testable, it decreases coupling, it might increase cohesion, and it's just plain nicer to read. When you derive from a base class, your class has all of its explicit responsibilities, and the responsibilities of each of its ancestor classes. In our example, each subclass is itself responsible for knowing the ins and outs of a particular data source. Since they all derive from a common base class, they are also responsible for knowing how to process the data. This example only deals with 2 responsibilities, but real systems deal with hundreds.

Remember that inheritance is often used to represent taxonomies. You might have classes such as Animal > Mammal > Giraffe or Widget > Button > Pushbutton. You might say that things on the right are defined in terms of things on the left, but that's not exactly true. A giraffe doesn't have lungs because it's a mammal; we call it a mammal because it has lungs. Using inheritance to describe something (using, for example, interface inheritance) makes a lot of sense. Using inheritance to define something doesn't.

Adventures with the Scriptaculous Ajax.Autocompleter

I had a chance to use the Scriptaculous autocompleter control at work the other day. Since we are using Ruby on Rails, it was easy enough to use text_field_with_auto_complete() to generate the relevant HTML.

The client noted that it was difficult to enter a new word if it was too close to an existing word. For example, he would type "expensive", and the system would suggest "not expensive". When he would hit Enter, it would replace what he had typed with "not expensive". This is because the Scriptaculous control doesn't support the case where no item is selected - one item is always selected, and it defaults to being the first item.

I decided to have a peek at the source code. In maybe 15 minutes, I had managed to convince it that "nothing selected" is a valid case. Unfortunately, I didn't refactor the code in any way - now every autocompleter behaves this way.

Scriptaculous uses prototype's Class.create() to generate 2 classes: Autocompleter.Base and its sole subclass: Ajax.Autocompleter. From the source code:

Autocompleter.Base handles all the autocompletion functionality that's independent of the data source for autocompletion. This includes drawing the autocompletion menu, observing keyboard and mouse events, and similar.

I appreciate their desire to re-use code. Unfortunately, the use of inheritance has caused the whole mess to suffer some sort of object-oriented gimbal lock. It's easy to create a new Autocompleter that gets its data from a different source; it's much more work to create an Ajax autocompleter with different behavior.

If I have some time (that is, when I'm not busy complaining about something), I might see if I can refactor the scriptaculous source to further separate the data source of an autocompleter from its interaction controller, using some method other than inheritance.

Ruby in LISP clothing

As it turns out, Ruby's syntax is somewhat flexible. As an example, parentheses are sometimes optional when calling a method.

puts "Oh hai!"
puts("Oh hai!")

link_to_remote "Go there", :url => { :controller => :there, :action => :go }
link_to_remote("Go there", { :url => { :controller => :there, :action => :go } })

The only time the parentheses are needed is when the invocation would otherwise be ambiguous:

link_to_remote h text, :url => { ... }

(h is the HTML escaping function. link_to_remote may actually automatically escape the HTML, but I'm not sure.)

Ruby can't tell what the user is trying to do. The normal way to fix this is to add some parentheses to the call:

link_to_remote(h(text), :url => { ... })
link_to_remote(h text, :url => { ... })

however, it is also possible to use LISP-like parentheses with the same result:

link_to_remote (h text), :url => {...}
(link_to_remote (h text), :url => {...})

Which is better? Certainly one of the first pair is more conventional. For some reason, though, I found myself migrating to the second pair. I suspect it's a combination of

• I try to avoid using parentheses in method calls in Ruby as much as possible
• LISP is awesome
• I have done some Objective-C programming, in which you [object send:message]

Consistency on Rails

The Ruby on Rails crowd makes a big deal about consistency. They claim that Rails is easy and fast for development partially because it favors convention over configuration. I guess the thought is that you don't need to write any configuration. Plus, once you've worked on a few Rails apps, you pretty much know where everything is.

So far, I've found a lot of that to be pretty much true. Migrations, routes, controllers, views, database configuration - there's a place for all of them, and they're pretty much exactly where I would expect them. However, I've often found myself struggling when actually writing the code. I'm either going to the documentation constantly, or even peeking in the Rails source. (It turns out that some options to methods aren't documented, and the rails plugins that we are using have poorer documentation than the core).

I only have 2 small examples at hand, but I could write about many more annoyances.

• link_to and link_to_remote both seem similar on the surface. One will generate a normal hyperlink that will navigate the browser; the other will generate an AJAX link that will interpret the resultant response as either HTML to be embedded or Javascript to be executed.
  
  Both allow you to specify the url using :controller and :action. However, they have very different signatures, and it trips me up everytime.
  link_to "Help", { :controller => :help, :action => :sample }
  link_to_remote "Help", :url => { :action => :help, :action => :sample }
  Did you see that? The only difference between the two is that one requires the URL-related options to be packaged in a hash named :url, while the other disallows the hash
• When using the form helper methods such as text_field and text_field_tag, you must be careful. Here is an example:
  text_field :post, :name <input id="foo_bar" name="foo[bar]" size="30" type="text" />
  text_field_tag 'post[name]' <input id="foo[bar]" name="foo[bar]" type="text" />
  As you can see, if you change from one to the other, you might need to also update you RJS files (or remember to set an explicit ID). This would have all been avoided if text_field had simply generated id and name attributes with the same value.
  

Rails certainly has its good points, but the small details are sometimes infuriating.

Dream Programming Language: Optional Interface Methods

Yet again, I find myself disliking abstract classes. I was creating a subclass of Java's OutputStream called PathalogicallyBufferedOutputStream (for testing purposes). I wanted to implement flush, which Eclipse nicely autocompleted to look like this:

@Override
public void flush() throws IOException {
// TODO Auto-generated method stub
super.flush();
}

That gave me enough pause to wonder... do I actually need to call the super method. It seems that I have 2 choices:

1. Check the documentation
2. Read the source code

Fortunately, Eclipse makes it easy to browse the JDK source code. It only took 2 seconds to verify that the base implementation, in fact, does nothing. Without Eclipse, I probably would have ignored it.

The no-op method stub is in the base class so that consumers of any OutputStream can indicate when the bytes that they have written so far form a semantically meaningful chunk. Somebody might be waiting for some data; this allows you to get it to her. The problem that I have as a deriver of OutputStream is that, without source code or good documentation, I have no idea whether I should or should not call the base method. This is not a problem with JDK-provided classes, but it could be a real bear with a third party library.

Some people might claim that you should "always call the base method". If course, that raises the question of at what point one should call the base method. Should you call it before or after your code? Perhaps you call it in the middle. I prefer to assume that I never have to call the base method, because I shouldn't be deriving from concrete classes, and I like to assume that method that I am overriding is simply a stub that I am free to customize.

If I were designing a language, I would want some notion of "optional interface methods." I want methods that I can declare on an interface (or perhaps an abstract base class) which implicitly have a no-op implementation. If I choose to implement one in a subclass or interface implementor (because I want to be notified when something happens), I would get the benefit of code completion. The caller is not burdened with the need to check to see if I've implemented the method, and the implementor is not burdened with the uncertainty of whether or not to call the base method.

Why Message Passing?

Back at the end of March, I was starting some work on Ruby on Rails. I thought that a good April Fool's Day joke would be to release "Lua on a Luge" or "Lua on Skiis" (somebody came up with something even better). As the people that I work with know, I'm a big fan of Lua. I appreciate the things that it does well (prototype-based programming, and having very simple, consistent syntax). Even more interesting, though, are the things that it doesn't try to do:

Lua does not try to help you write programs with hundreds of thousands of lines. Instead, Lua tries to help you solve your problem with only hundreds of lines, or even less. - Programming in Lua - Preface

In any case, Lua doesn't directly support multithreaded programming. Normally, this would be fine. However, I've worked on some .NET and Java web apps that:

1. Spawn a background thread to do some work
2. Handle multiple requests at once
3. Share some object / data between all of the request-handling threads

What kinds of things might we share? We might share configuration information, we might share connection pools (of connections, or threads, or whatever), we might share session information. Anything that is shared must be concurrency-safe.
Java and .NET provide synchronization mechanisms. Lua does not.

I started to think about various ways to solve this problem. One could expose a C threading library to Lua. You could expose both the thread management and synchronization primitives. Then, you could only share objects that are specifically written to use that threading library. You might also be able to inject metatables into arbitrary objects, but that would only go so far.

Then I realized that I already knew a better approach. If we relied on simple message passing between Lua processes, we could avoid the need to synchronize every shared objects - no objects would actually be shared (we might copy all values that get sent along on a message, or restrict the kinds of values that may be sent on a message).

It would probably not be as efficient as Erlang's message passing.  Also, I don't know of any Lua implementations other than the reference implementation and World of Warcraft's implementation, but I doubt that either support lightweight processes (instead, both implementations provide coroutines).  Incidentally, Ruby on Rails is currently not thread-safe (other Ruby web frameworks apparently are, according to the Mongrel FAQ). At least one Rails guy thinks that it should remain that way (see slide 115).

Dream Programming Language: No Static Fields

If I were to implement my own OO programming language, static data would be the first thing to go. I can't find any compelling reason to keep it around.

Something that people may or may not undestand is that static really means "global". Seriously, I wish that languages like Java and C# simply used global as the keyword instead. Static methods are simply global methods that have a long name with a period in the middle (well, I suppose they are also scoped and are subject to access control). Static, final references to immutable objects are just that - they're global constants. Keeping a single definition of PI around is generally a good thing. And, you guessed it, static fields are simply global variables in disguise.

"But!" I hear you say. "But I need static fields to implement singletons!" Why do you want singletons? Sure, you might think that you will only ever want a single instance of a class. I think you're wrong. What happens when you want to do some unit testing? What happens when the requirements change.

At one point, I'm sure that Windows assumed that it had exactly one display. If singletons had been widely used then, I would not have been surprised if there were some singleton which kept the display's information (in actuality, it may have simply been a global variable). Today, we might not only have several physical displays, but we might also have multiple active windowing sessions on a single Windows server. How about mice? Surely, a system has no more than one pointer. Well, that's kinda true, but my coworkers and I wish that we could get a second pointer on the screen for our pairing sessions. What about my Wacom tablet? And my friend prototyped a game that was controlled by using two mice. Singletons are the antithesis of what the Dependency Injection folks have been telling us.

If I were designing a language, I would want the programming language to encourage good programming practice. Since I'm the one designing this language, I get to choose what is good and bad. And I say, "down with singletons!"

Message Passing

Anybody who has tried to do multithreaded programming in Java, C#, or most any C-based language finds that it can quickly become nightmarish. Deadlocks, race conditions, lock management - all of these issues will occur. In Java, all threads are able to share objects. As a result, the programmer is responsible for ensuring that his objects can't be put into an invalid state. Java provides per-object monitors to enable this. However, working with such monitors can be a nightmare. Using notifyall when you should have used notify, or forgetting to add the synchronized keyword to a method declaration, or incorrectly assuming that a class was thread-safe when it wasn't; these are all examples of simple problems that can cause your application to fail (perhaps only sometimes).

Erlang, on the other hand, does not suffer the same problems. Instead of sharing things, Erlang processes (which are the Erlang unit of concurrency) do not share anything. As a result, the need for synchronization goes away. Erlang processes send messages to each other. Each process has a mailbox. Each process can retrieve and process messages from its mailbox. You can imagine that a message is copied when it is put into another process' mailbox, but in actuality, since data in Erlang is immutable, the system is probably able optimize that away.

One of Java's founding principles was that manual memory management is complex, and thus easy to get wrong. Far simpler was to provide a system where the programmer didn't need to worry about such things. Erlang does for concurrency what garbage collection did for memory management - it removes that responsibility from the developer. Instead of asking every developer to handle any threading issues that might arise, it provides an abstraction that hides all of them. Behind the scenes, Erlang's mailbox system does whatever synchronization it needs to do in order to be completely thread safe.

Of course, Erlang's approach isn't perfect. Just as Java's garbage collection can sometimes allow memory to leak (when you are holding onto a reference longer than you need to), Erlang's system could still be susceptible to problems such as deadlocks. However, it is less likely to occur, and should be more obviously solvable when it happens.

Erlang's approach is so radical, yet so simple, that it's definitely worth learning more about. I hope to see Java and C# projects adopt Erlang's philosophy when appropriate. In performance-critical applications, manual concurrency management might be the way to go. For most purposes, though, the safety provided by Erlang's approach outweighs any negative side effects.

GameStop culture

Unlike some people, I actually have a decent GameStop nearby. The people who work there are intelligent, useful, and just generally pleasent. I was there tonight, picking up a copy of Condemned, which I have heard good things about.

In any case, the clerk was telling me that its sequel is also good, and noted that it is more of a horror game (Condemned being more of a thriller). As I was leaving, he suggested that, if I beat it in less than a week, I could trade it in towards its big brother. I thought he said something about full credit.

This struck me as odd. Here was a Gamestop employee essentially offering to loan me a game for a week, with no risk to me. Well, I suppose I would be turning $17 of hard currency in GameStop store credit, which is good for them, but it still seems odd. Then again, their whole business model is odd.

On the other hand, perhaps I simply misheard him.

Ruby on Rails after 3 days

I've been learning Ruby on Rails at work for the past 3 days. I had never really worked with Rails before, though I had certainly read enough to form misguided opinions about what was good and what was bad. After some hands-on experience, I have a better idea of what I do and don't like.

Routes

Routes are Rails' way to find the handler for a given request. You can establish routes by editing routes.rb. I don't know whether this is common practice, but an advantage of using a Ruby source file over XML is that you can use Ruby language and library features. This makes it easier to add conditional or generated routes, something that the Rails REST support does with abandon.

Routes are also 2-way. They are also used when you want to know the URL to a particular controller/action. This makes virtually impossible for your URL recognition and URL creation code to get out of sync.

RJS

RJS is Ruby's javascript-generation library. It's used as part of infrastructure for AJAX applications. Most of the Ruby AJAX tutorials that I've seen do something that I consider to be very bad practice - they run code on the server that doesn't need to be. The typical pattern seems to be to use an RJS helper method to emit Javascript that attaches a listener to some other HTML element. This listener then issues an XmlHttpRequest to the server, which produces Javascript code. This code is then sent to the client, where it is eval()'d. While there is nothing wrong with that pattern per se, imagine doing that for something as simple as clearing a text box. Imagine thousands of clients contacting the server just so that they can clear their text boxes.

Of course, in typical Rails fashion, there are many ways to use RJS. Rather than use it in response to a lightweight request to the server, you can also use it when you are building up the original HTML page. This can both simplify your application and also increase its perceived performance. Of course, you need to know that you are able to do this.

Unfortunately, the Javascript that is generated isn't that much different from the original Ruby. Compare this RJS Ruby code:

page['query_results'].value = ''

to this hand-crafted Javascript:

window['query_results'].value = '';

I'm generally against code-which-generates-code, and especially when used to avoid learning a new programming language. Web developers usually end up developing a reasonable understanding of HTML, and those in the Ruby community seem to also be reasonably proficient with CSS. I would hate for them to miss out on a fantastic language like Javascript.

Ruby Itself

Finally, Ruby as a language creates some interesting situations. I find its dynamism to be both a blessing and a curse. It's pretty amazing that Aptana Studio seems to be able to "go to declaration" reasonably well. Of course, this only works for methods which are defined statically, in the source code. Some methods are added dynamically (via method_missing or some other black magic of which I am unaware). I believe that it is impossible to even find out what these are - you simply have to know what methods ActiveRecord may have added to your model objects. I'm sure that this gets easier with exposure.

Incidentally, this very dynamism has spawned some very interesting workarounds. Since the routing tables are stored as data, it's hard if not impossible to see the set of routes by looking at the code. However, there is a rake target to see the contents of the routing table:

rake routes

Similarly, the migration nature of Rails database management makes it quite hard to quickly grok the structure of the database. However, Rails generates a schema.rb file which theoretically mirrors the current state of your database schema. Perhaps not strictly necessary, but awfully convenient.

Conclusion

In all, I'm reasonably happy with Rails so far. It's quite different from previous experiences that I've had developing web applications. In a way, it hearkens back to when I was first learning HTML. It was trivially easy to write some HTML and then see what it looked like in a web browser. The code/test cycle was very small. Rails brings the same sort of simplicity to web application development. Rather than spend time writing code, you spend time learning how to write the code in the correct Rails mindset.

I don't know if Rails will scale well. I don't know if Ruby will be able to keep up. I don't know if ActiveRecord will strangle us or liberate us. However, I do know myself, and I know that I will stay skeptical for quite some time. Hopefully, one day I will realize that I've been happily writing Ruby code for years and find that neither it nor Rails have failed me.

Windows Home Server

I just received my HP MediaSmart Server (actually, the EX470). I've just finished setting it up and playing with it a bit.

Here are some problems that I encountered:

1. To get my VMWare Windows XP instance on my Macbook Pro to see the WHS, I needed to put the network connection into Bridged mode.
2. It didn't initially work with my Airport Extreme base station, but there is a solution (and not a bad solution at that).
   

Here are some of my findings:

1. It appeared to be cheaper to buy an extra 500GB drive (even the exact same drive as is in the server) than to buy the EX475. The drive that is in the first slot is a 500GB Seagate ST3500630AS (Newegg search).
2. It runs IIS 6.0, ASP.net 2.0.50727, PostgreSQL 8.2.1.7007, Firefly media server (build 1.1 svn-1601), .NET 2.0 SP1, and Java 1.4.2_13
   
3. Though it is preferable to administer the server only via the Home Server Console and the shared folders (for adding Add-Ins), it is also possible to remote desktop to the server and get a full Windows shell, start menu and all.
   
4. The HP Photo WebShare web application appears to be written in Java, and is being served by Jetty under IIS using isapi_redirect.dll. If I knew anything about Jetty or about using a Java application server under IIS, I would tell you more. Otherwise, the app looks pretty much crap. It works, but looks very amateurish. Much like most OEM-supplied software that comes pre-installed on your computer. On the bright side, it seems to have an ActiveX control to bulk upload images, which is a very nice (and essential) touch.
   

If you don't get giddy about the idea of an extensible, autonomous, unobtrusive computing henchman in your domicile, then I suppose Windows Home Server isn't for you. But I personally relish the idea of making my home network a little more than a web browsing gateway. I have great faith in the ability for computers to improve the way we live, and I see this as a very small step towards a seemingly distant, but bright, future.

Changing Microsoft Office 2008 for Mac Splash Screen Registration Information

I stumbled around a bit before finding this solution. From some post:

1. Quit all Office programs
2. Delete these files:
   • /Users/<user name>/Library/Preferences/Microsoft/Office 2008/Microsoft Office 2008 Settings.plist
   • /Applications/Microsoft Office 2008/Office/OfficePID.plist
3. Start any Office program
4. Retype your name, company, and product key

It seems that, if you only delete one of them, it regenerates the other.

Memeo AutoSync is extremely slow

I just bought a Western Digital MyBook Home Edition as a backup hard drive. The drive itself is small, pleasing to the eye, and not too noisy. It comes with WD Anywhere Backup, which itself is a rebranding of Memeo LifeAgent AutoBackup (I assume the standard edition). This software is supposed to automatically back up your files as they are changed on your hard drive.

I set the software to backup my WHOLE drive (from the C: directory down, with no exclusions). That's about 208GB of data. I've left it running overnight and over a day at work, and this is the progress so far.



(I didn't take a snapshot of the other screen, which indicates that this process was started at 12:32 am, so it's actually been running for about 19.5 hours at this point, though it apparently was idle for a while)

That's right: after 19.5 hours of work, it has only backed up about 20 GB of my data. At this rate, it will take about eight and a half days to complete. USB 2.0 may be slow, but it ain't that slow! The whole time, it's been using between 30% and 50% of one of my CPU cores.

To be fair, it is verifying the contents of all of the backed-up files as it goes. I do appreciate that. But seriously!

To ensure that it wasn't a problem with the drive, I copied my 1.3GB Guild Wars data file (a single file) to the drive. That took 1'09". I copied my nearly 8GB Unreal Tournament 3 install to the drive (1900 files exactly), and that took 10'21". Memeo copies files at 2% of the speed that Windows Explorer does. Another way to look at it is that Memeo is 50x slower than Windows Explorer.

I recommend that you don't buy Memeo software. They might eventually get it right, but you should wait until then. Western Digital should find a new company to provide their backup software - this Memeo junk just makes them look bad.

Removing Credit Card from Xbox Live

I accidentally charged an old credit card on XBox Live tonight. I started looking around to figure out how to remove the old card. Half an hour later, I stumbled upon the solution. Since it's so obtuse, I will describe it here.

Notes: You must have a Windows Live ID associated with your XBox account, and you must have another credit card tied to your XBox Live account. You will be transferring all charges FROM one card TO another card. This apparently also has the side effect of "removing" the old card from the system. If you need to do something different, like to cancel XBox Live, you might need to call support instead.

1. Go to Microsoft Billing and Account Management. Log in.


2. You will see a list of credit cards attached to your Windows Live ID. Note that this will only work if you have associated your gamertag with a Windows Live ID. (In my case, you can see that I have removed one of my cards).
   
   


3. Click the card you want to delete. This will take you to a screen that includes this:
   
   


4. Choose "Go to payment method information". You will be at a screen that includes this:
   
   


5. Click "Use a different payment method," and select the card that you want to use.

I could make jokes about how Microsoft is just looking for an excuse to keep your money. Instead, I'll joke that they can't design user interfaces. I mean, it's not like anybody else has solved the cancel-a-credit-card interface problem.

Oh wait. This is from the iTunes music store:



Of course, this should be no surprise to any 360 owner. The 360's interface is among the worst things ever created by Redmond. Yes, I think it's worse than Clippy. Quickly - where do you go to get a list of your active downloads? If you're in a game, the only way is by pressing the "XBox" button, and selecting PERSONAL SETTINGS! Clearly, downloads are a setting. There are a number of settings which you change in 2 different places. Themes are one example. Also, the 360 is the only console whose menus are affected by the speed of your internet connection. Quite often, I can't start a game for 30 seconds or more because the menus haven't yet loaded (presumably, downloading ads off the XBox servers).

It's worth noting that the XBox 360 has been out for OVER 2 YEARS! The original XBox was only around for 4 years before the 360 was introduced. This console is half dead, and the user interface is only beta quality. Nice play, Microsoft.

---

Update:

I noticed that Microsoft added an item to their help center in the XBox interface. You can instead go to xbox.com/accounts to manage your credit cards. The interface is a little nicer, though they still dump you back to the old system to transfer your XBox Live subscription from one card to another.

The Dangers of Flash

As I sit here and use my computer (2.4 GHz MacBook Pro), I noticed that the laptop was getting quite hot. I looked up at smcFanControl, and noticed temperatures between 165 and 175 Fahrenheit. The fans had spun up to nearly 6000 RPM (from a base of 2000). Trying to figure out just what was going on, I noticed that Safari was using 66% of my CPU time.

As I closed some tabs, I noticed that my temperature was dropping... fast. In about 20 seconds, the temperature was down to 140-145 Fahrenheit. the fans had slowed as well.

It looks like the problem tab was Verizon Wireless' Chocolate Site. I had clicked the commercial link because I was trying to identify the song. I had paused the movie while I went to some other site to do some searching.

I fired up Quartz Debug, and learned that the entire contents of the HTML document were getting redrawn continuously. That's a lot of pixels to be pushing.

So, if you ever use flash for your website, remember to take it easy on your end user's laps.

Objects, just not Object Oriented

I've been on a real programming language kick for the past year. First, I picked up Prolog again. Then Javascript, then Ruby, then Lua, then Erlang. This is in addition to lots of programming in C#, some in Java, and a little C++ on the side. I'm starting to notice lots of similarities between languages. I don't mean superficial similarities (Java has classes. Whoa, so does C#. Dude...). I mean deeper, conceptual similarities.

As an example, take objects. C++ has objects. Smalltalk does too. Also Java and C# and a whole lot of other languages. However, all of the objects in those languages are bound together by sharing a single class.

Javascript and Lua don't share that requirement. They're still object-based (you have entities which hide implementation and expose functionality), but object's don't necessarily share a common class. In fact, an object in these languages can (and often does) have no class at all.

Further still, some languages have object-like things. Erlang, for example, allows you to create processes. Processes can send messages to each other. Processes can even have private data (since a process is just a function, and functions can always have local variables, processes can have private data). Is this an object? I think so!

Some languages even give you object-like functionality in even stranger ways. Take purely functional languages like Lisp (or Scheme) or ML. These languages let you create "closures". A closure is a function that exists within (is closed to) an environment. In Javascript (not a functional language, but one which supports closures):

function make_add(left_addend) {
  var f = function(right_addend) {
    return left_addend + right_addend;
  }
  
  //At this point, f is bound to left_addend.  Whatever
  //we passed in as left_addend is now known by f.
  //We can return f, and it will correctly remember
  //the value of left_addend.
  
  return f;
}

var add10 = make_add(10);
var add1000 = make_add(1000);

print_to_console(add10(5));
print_to_console(add10(50));

print_to_console(add1000(5));
print_to_console(add1000(50));



15
60
1005
1050

Why is this cool? Well, we have effectively created an entity which has private data. We could go a step further and make 'f' into some sort of dispatch method. It could take, as its first parameter, an operation. So, perhaps we could have this:

function make_number(value) {
  var f = function(operation) {
  if (operation == "add") {
    return make_number(value + arguments[1]);
  } else if (operation == "sub") {
    return make_number(value - arguments[1]);
  } else if (operation == "toString") {
    return value;
  } else {
    return null;
  }
}

var number10 = make_number(10);
var number1000 = make_number(1000);

print_to_console(number10("add", 5)("toString"));
print_to_console(number10("sub", 50)("toString"));

print_to_console(number1000("sub", 5)("toString"));
print_to_console(number1000("add", 50)("toString"));



15
-40
995
1050

Not too pretty, but it should work. Object-oriented programming in functional languages. Who knew?

Big, Bigger, Biggest Design Up Front

This was originally posted at Ternary Software. It is mirrored here because I wrote it and I want it on my personal blog as well as my work blog.

---

Background

Extreme Programming encourages its practitioners to do away with a technique known as Big Design Up Front. BDUF is a software development process that has existed for nearly as long as software development. The general idea is to design a software system completely on paper before writing a line of code (experiments and proof-of-concepts aside). XP claims that this is a bad idea. In my recollection, the XP book claims that you wouldn’t get the design right anyway. You really can’t get the design right until you have finished writing the code.

Reality

In theory, this doesn’t sound too bad. I mean, the best way to understand a system is to try to formalize it in code. You’ll spot all of the inconsistencies and problems pretty quickly. (In fact, I think that’s the real skill that a software developer brings to the table - the ability to analyze a system and find the problems). But still, to do no design up front? Clients don’t come to you with no design. In fact, if one did, would you really take their business?

Prospective Client: Boy, do I have a project for you!
Development Team: Great, what do you have in mind?
Prospective Client: Well, see, it’s a thing. It does stuff. It’s a lot like That Web Site, only different. By different, I mean really different. But I’m not quite sure how. Also, it transforms into a boat.
Development Team: What? That makes no sense!
No Longer Prospective Client: Well, I thought I’d design it as I go.
Development Team: Well, we’re really booked right now, but we’ll call you as soon as we have some free time.

So I suspect that developers, too, need to do some design up front. I can think cases where NOT designing up front has cost us a lot of effort in re-design. Developing a 2-tier system when we knew that the client really wanted a 3-tier system is but one example. (We fixed that problem within a month, but it was still a hassle that could have been avoided). But how much design is too much? The XP book says something about doing “enough” design, but that doesn’t really provide a lot of guidance.

Disclaimer

Now we get into the part that I don’t really understand well enough. These are my thoughts, but they’re surely wrong. My thoughts will probably change with time, and I would appreciate any feedback that I can get.

3 Kinds

Here’s an over-generalization: systems that you design can fall into 3 categories:

1. Systems that perfectly implement the requirements of today with no thought to the future. Any attempt to use them in a way that is different from the original intent will require massive amounts of redesign. I’ve seen a lot of Javascript code that seems to fall into this category. For that matter, a lot of code written on consulting projects seems to fall into this category.
2. Systems that implement any conceivable requirement for the next 5 years. Sometimes, they do a good job of this; sometimes, they fail miserably. Yes, ZZZManager, I’m talking about you! A lot of libraries tend to lean in this direction.
3. Systems that, while implementing the requirements of today, also have a lot of hooks for the requirements of tomorrow. The assumptions that they make (and the hooks that they provide) aren’t necessarily perfect, but it’s not TOO hard to change them to support new requirements. Some really good libraries and really good frameworks do this. When I saw how simple it was to write a Java Servlet, I remember thinking that Servlets strike an excellent balance of providing functionality to the programmer without making too many assumptions.

I would furthermore attempt to characterize those three kinds of designs as:

1. Not Enough Design
2. Too Much Design
3. A design that’s juuuuust right.

The Source of All Design that is Good

Let’s assume that I’m correct in my characterization. How do you get this kind of design? Well, I think it’s a little like Chess. For chess masters, the match is won by the person who can “see” further into the future. I think that good software design comes from people who can (correctly) guess the future. There are a number of contributing factors:

• You yourself. I think some people just naturally think more about the future than others. I don’t think that people who think about the future are better at designing (see Too Much Design). But I do think that it’s important to be thinking about both the present and the likely future.
• Your experience. If you’ve seen a problem before, there’s a chance that you will try to avoid it in the future. I think that experience can help you avoid problems without even realizing that you are avoiding them - you just make really good choices.
• The pressures on your team. I think teams that have some healthy amount of slack time will be more likely to think about things that are a little broader than their current task.
• Your level of attunement. The more in-tune you are with your client and their needs, the more likely you are to guess correctly about their future requirement needs. You need to understand not only their product, but to a certain extent, their business model and their users.

Tips

Those factors are often hard to change. Are there more immediate guidelines for avoiding problems? I certainly don’t know how to avoid all problems, but here are some general thoughts that have helped me so far:

• If, while implementing a feature, you think you will be ripping out the code in a month, you probably need to design a little more. Changing code in a month is OK, but replacing it is scary. Replacing it in 3 years is probably OK.
• If you can’t explain to the client what you are working on and why they need it, you’ve probably designed the wrong thing (i.e. over-design)
• Don’t take shortcuts. If there’s an easy way and a hard way to design a system, make sure that the easy way isn’t really the “really hard later” way. It might be perfectly fine to take the easy approach. In fact, you probably should. Just make sure that you’re not going to get screwed in the near future.
• If you are writing very similar (but also slightly different) code in several places, you probably need more design. For example, you use an Excel writing library in 20 places in the code base, something is screaming to be extracted into its own class (or set of classes).
• If your code has no layers, you probably need to design some more. Just as classes need to be small and simple, so too must groups of classes. If you have a class that is referenced by code in several namespaces, you should wonder why everybody needs to know about him. (Perhaps everyone really does need to know, but you should still think about it).
• If you end up writing a lot of static methods, you need to extract some classes. A few static methods (especially named constructors) are OK, but if you have too many, you’re just writing procedural code.
• If you end up writing a lot of private methods, you need to extract some classes. A few private methods are OK, but if you have too many, you’re just writing procedural code.
• If you know that some of the code that you are writing is more general than your specific task, break it into 2 pieces. Write some of the code in a general way (using Template Method, aggregation, or something cooler), and write your specific code in terms of the general pattern. LISPers (and other functional programming dudes) know how to take this to the extreme. (Every functional language that I’ve encountered comes with a built-in function that can apply a function to every element of a list. Finding the sum of a set of numbers is often as simple as applying “+” to every element of a list). Be very wary of this, however, as this can lead to some scary over-design.
• If you don’t know what you are going to be doing later this week, you can’t anticipate the future. Have a plan.
• If your plan describes what you will be doing for 6 months, you will be using a different plan in 6 months. You’ll probably write code that won’t make sense in that new plan. Spend less time designing, and focus on short, iterative releases.
• If you write code that everybody uses, and which affects code throughout the system, and your code needs to be changed whenever some other requirement changes, you have too much centralization. You’ve designed a fancy system, but it’s going to cause you problems.

Conclusion

Those are all of my ideas for now. Actually, I could keep going, but I would just be rambling more. I want to again stress that this area is very unclear to me, and what I have typed here are only my current thoughts on the subject. I would love to hear other people’s opinions!

On Windows CE, Microsoft, the framebuffer, backwards compatibility, and demons

This was originally posted at Ternary Software. It is mirrored here because I wrote it and I want it on my personal blog as well as my work blog.

---

I spent the better part of today struggling to get some fancy graphics on my O2 XDA Exec (read a review if you are interested in the device). I know that I can use the Windows CE GDI to draw the graphics on the screen. I also know that will be slow. Not necessarily too slow, but certainly not an API that any self-respecting game developer would use. So, moving along, I knew that there was the GAPI - the Game API. It sounded great - provide access to the framebuffer and to low-level keyboard functions. So I read and implemented.

Everything was working fine in the Pocket PC emulator. But on a real device, no luck. It ran, but incorrectly. For one, it pretended that my device had a resolution of 240×320 pixels, which is 1/4 of the actual number. It used pixel doubling to fill the whole screen. On top of that, it wouldn’t draw anything in the leftmost pixel column. I had an ugly blue column extending from the top of the screen to the bottom.

I spend hours looking for a solution. I looked to see if it was a clipping problem, an API misunderstanding, a device issue. I couldn’t find any information. Then, I started reading support forums for other applications. It was there that I discovered that the problem is that, at this point, GAPI is provided on new devices as an emulation library. Apparently, in the Pocket PC 2002 / Windows Mobile 2003 days, GAPI was the way to make games. However, a lot of game developers made a lot of assumptions about transient things like, say, the screen resolution of devices. Microsoft, fearing that high resolution screens would break a lot of existing applications, decided to release a GAPI implementation for more recent devices that doesn’t return a pointer to the ACTUAL framebuffer. Instead, the application gets a pointer to a back buffer. Upon calling GXEndDraw(), a GAPI function whose purpose should be reasonably obvious (it flags that drawing operations are complete), this emulation library flipped the buffers and (on my device), upscaled all of the pixels.

HOWEVER, certain crafty game developers apparently thought that GXEndDraw was a useless function. After all, it didn’t seem to do anything on their Windows Mobile 2003 devices. And, if it doesn’t do anything, why should they take the time to call it? I believe that this is why I was having trouble with Pocket Quake. I plan to try to fix it and then tell the developer.

As for the single unwritable column of pixels, I simply think that this is a bug in the copy of gx.dll (the GAPI runtime library) that is on my device. The pixel doubling routine is probably wrong. I believe this because I think I have solved my problem. I can write all 480×640 pixels, including that annoying leftmost column.

To perhaps save somebody else the time that I just spent, let me share my findings. Microsoft suggests using the GETRAWFRAMEBUFFER escape operation in the GAPI Legacy Support section of “Developing DPI-Aware Applications”. There’s a good example in that article. This seems to be the new way to really, definitely, for sure this time, get raw access to the framebuffer. Until some developer takes too many liberties with it, and Microsoft has to invent yet another hack to keep other people’s applications working.

I should probably just bite the bullet and use DirectDraw. I thought that I had read on the GAPI for Handheld PC’s page that DirectDraw was not supported on the PocketPC platform, but they were perhaps referring to the 2002/2003 platform. I don’t see DirectX dlls on my device, but perhaps they are hiding.

Perhaps I’ve read so many of Raymond Chen’s posts that I’ve started to sound a little like him.

The Double If

This is a anti-pattern that I have started to see when people attempt to think in terms of objects, but don't think in terms of messages. The case is that you have one bit of code that will do a test and will return either a real value or null (in this case, that method is GetParentName). Then, anybody who uses GetParentName needs to either be OK with getting a null back, or needs to test to make sure that the value returned is not null. This code illustrates that anti-pattern:

    class Item
    {
        //Return either a real string or null
        string GetParentName()
        {
             Item parent = GetParent();
             if (parent == null)
             {
                 return null;
             }
             else
             {
                 return parent.GetName();
             }
        }
    }

    void SetupTextBox(Item myItem, TextBox someTextBox)
    {
        string parentName = myItem.GetParentName();
        if (parentName != null)
        {
            //TextBox::SetText(string) will throw an exception
            //if it is passed a null
            someTextBox.SetText(parentName);
        }
    }

A way to fix that is to change the class' interface. Instead of getting values from the class, let's tell the class to tell its information to somebody.

    class Item
    {
        string TellParentNameTo(StringReceiver receiver)
        {
             Item parent = GetParent();
             if (parent != null)
             {
                 receiver.SetString(parent);
             }
        }
    }

    void SetupTextBox(Item myItem, TextBox someTextBox)
    {
        //myItem will do the best that he can do, even if he 
        //has a null
        myItem.TellParentNameTo(someTextBox);
    }

The biggest problem with the second example is that you need to have really, REALLY broad interfaces that are used everywhere. In this example, TextBox would need to be a StringReceiver. In fact, anybody that could conceivably get a string from an Item would need to be a StringReceiver. If TextBox were written so that it is a StringReceiver from the beginning, everything works great. However, suppose that StringReceiver was written later than TextBox. Either TextBox will need to get it retrofitted, or an adapter class will need to be written:

    class Item
    {
        string TellParentNameTo(StringReceiver receiver)
        {
             Item parent = GetParent();
             if (parent != null)
             {
                 receiver.SetString(parent);
             }
        }
    }

    class TextBoxStringReceiverAdapter
    {
        TextBoxStringReceiverAdapter(TextBox textBox) {}

        void SetString(string str)
        {
            textBox.SetText(str);
        }
    }

    void SetupTextBox(Item myItem, TextBox someTextBox)
    {
        //myItem will do the best that he can do, even if he 
        //has a null
        myItem.TellParentNameTo(
            new TextBoxStringReceiverAdapter(
                someTextBox)
            );
    }