User interface prototyping and especially Throwaway prototyping is an essential step in developing a user-friendly and useful interface.

Usually, user interface prototyping starts with a low fidelity, paper-based prototype or even a raw sketch drawn during a brainstorming session. Once the main idea is generally accepted, a high fidelity version must be produced.

I used to do this using Visio or even Photoshop but realized that it’s really time-consuming to create a good-looking consistent interface, so I started looking for other ways of producing mockups.

The first thing I tried was using Visual Studio and actually creating forms. Turned out that mocking up using Visual Studio is just as time-consuming as using Visio or Photoshop, plus, I am not really a drag-and-drop enthusiast, always preferring hands-on descriptive coding so I thought about trying XUL or XAML, both XML-based languages that can be used to describe user interfaces.

Using Visual Studio, or any other IDE for that mater you are tempted to use the mockup later. That’s a bad idea, as prototypes are meant to be thrown away.

XUL and XAML aren’t really so much different. I’m not saying that you can just copy some XAML and expect it to run in as XUL but still, the languages are quite similar. I prefer XUL because it doesn’t bring any overhead except for a Gecko-based browser (like Firefox or SeaMonkey, which you should already have), while rapid prototyping with XAML requires Visual Studio .Net (or the Express edition).

I’m just going to demonstrate XUL for rapid prototyping by using a simple bookmarks dialog. Here’s the ugly sketch which I drew on the back of an envelope:

XUL prototyping:
I generally use SciTE(an excellent text editor) to write the XUL and load it into Firefox but there is an easier way – you can use the Live XUL Editor to see your changes in real time.
Writing XUL is pretty straight forward, especially using a good reference such as XULPlanet.

The result:

The source:
You can view the source as html or as XUL (with Firefox or SeaMonkey).

What do you use for your user interface prototypes?

One of the most important factors to take into consideration when setting deadlines is that, for a programmer, an eight hour work day doesn’t actually mean eight hours of coding.
This is a mistake that a lot of project managers make when setting deadlines for tasks. Even worse, this is a mistake that many programmers make when they estimate future work, thus perpetuating the project managers evil deadline strategy.

If you are just a programmer in a normal team, and depending on chosen technologies and organizational overhead, at least a quarter of your day will be filled with non-code-producing activities. If you are a tech lead, even more of your time will be lost in administrative tasks or programmer assistance.

What non-code producing activities am I talking about? Well just think about it!

* Reading your emails. Sounds like a 5 minute job right? Wrong. It takes one or two minutes on average to read an email. What if you receive 70 emails? 20 are spam. You still have 50 to read. It takes you 100 minutes. You answer 10 of them. You just lost 2 hours of your time.
* Reading issues. I suppose you have an incident tracker. You can loose an hour just by reading incidents, setting priority, thinking about fixes, etc.
* Helping your peers. You can’t say no to a peer that needs your assistance. Especially if you are tech or component lead. Scratch off two more hours.
* Why not have a meeting or two. Necessary. Scratch two more hours.

The list can go on, but I’ll stop here.

The point is this. Next time you set a programmer’s deadline or you ask him for an estimation think about the fact that “an eight hour work day doesn’t mean eight hours of coding”.

One of the best lessons to learn, not only in software development but also in everything you do, is “don’t give up“. Never. It pays off. Really!

This is one of those things that you have to teach yourself, each and every day. If you get hit, hit back, harder.

Why I am writing this? Well, I am writing this from my laptop, which until 20 or so minutes ago had no wireless connectivity; basically it was offline (yes, the dark side). The wireless access point was visible, so I knew it had to be some configuration issue that I had to fix.
I’ve been trying to fix it for a week now, every day, for about 10-20 minutes. I’ve never spent more than that because I know that after the first 10-20 minutes, if the problem seems simple, you may loose a couple of hours and still not get it fixed, and I value time. If you leave large time gaps between tries, you have a better chance of fixing it, especially if it’s not really an urgent problem, like using your laptop at home, where you also have one or more functional desktops . Okay, back to the point!

“Don’t give up” or “Never quit!“, lessons that prove their worth daily for millions of people. Why not you?

When running in a console window, pressing CTRL+Break signals the JVM to print out all stack traces of currently running threads.

If your application runs as a service (or linux/unix dæmon) you can’t press CTRL+Break, so you have to signal the JVM yourself to produce the stack trace. You can do that on linux by signaling a QUIT to the process, or by using jstack and the PID.
Good news, Java SE 6 on Windows comes with jstack. Yupee! .

So next time you need a thread dump from a java application running as a service just get the pid, fire up a cmd and run jstack <pid>.