March 31, 2006
Gabbly: chat done right
I just came across Gabbly... Very slick.
It's a chat application that gathers all the current visitors of the same Web page. The concept isn't exactly new, but my hat's off for technical execution. It's very slick and super easy to set up: just tag the domain name of your destination after http://gabbly.com (e.g. http://gabbly.com/testng.org) and you're in business.
Of course, the real challenge is to make it viral: right now, only people who use that redirected URL will join the channel. You can embed the application on you Web page, though, so that's a start...
March 30, 2006
Jaxx... oh my
I couldn't resist reading an article opening with "I want to break free from the GridBagLayout: introducing Jaxx".
I should have known better...
Here is the value proposition of Jaxx: you describe your Swing applications in XML and you code your Java logic inside these XML files. Yup.
I have two problems with this:
- Jaxx does nothing to rid your of GridBagLayout. If you
need complex layouts and you want to stick with the javax.swing
packages, GridBagLayout is your only hope.
- Java code in... XML files? Now that's a great idea. Java developers are finally getting hooked to IDE's and Jaxx offers to take these away from us. No more refactoring, no more completion, awkward formatting... Now that's a winner.
I understand the value of describing interfaces in an XML file, but at least, please make sure that I can keep writing my logic in good old Java files.
As for GridBagLayout, do yourself a favor and forget everything you ever learned about it. Either use JGoodies or SWT's fantastic GridLayout.
March 29, 2006
These arrows are dead to me
Scrollbars are one of the most important inventions in computer user interfaces. They have been there since day one of the "Windows Icon Menu Pointer" paradigm, and interestingly, have hardly evolved since then. Here is a very quick overview of the history of scrollbars:
- Proportional scrollbars were a very important innovation that many operating systems and UI toolkits took quite a while to implement them (Mac being the first offender). When a scrollbar is not proportional, its "thumb" never changes size, regardless of whether you are currently looking at 1% or 90% of a document. But history has judged and proportional scrollbars are the norm now, even on cell phones. I believe the reason why Apple and other vendors were reluctant offering proportional scrollbars was because they were afraid the user would be confused. It was a legitimate concern but Windows (and to some extent, Motif and other X Window managers) quickly demonstrated that not only were users quite capable of handling the visual information, they actually asked for it.
-
Another improvement that we saw through the years is to group the arrows
together. Very few user interfaces ventured there (AmigaOS was one of
the courageous ones), and yet, the idea is very appealing: why put the
up and down arrows so far from each other? They have a clear icon that
shows their purpose, so the additional information carried by their position
in the scrollbar doesn't really add that much and forces the user to move
the mouse quite a bit and click on a very narrow button when they was to go
back and forth between two positions. Unfortunately, grouped arrows
never made it in the mainstream and I don't know of any popular operating
system that features them. Quite sad.
- Another very useful innovation that hasn't received as much exposure as it should is what I call "documented scrolling". It can be seen in a few Office programs (the screenshot shows PowerPoint) and Acrobat Reader. The idea is very simple: as you move the thumb after clicking on it and keeping the button pressed, a small tooltip follows your move and lets you know in what part of the document you will land if you release the button. Very effective, yet marginal.
The reason for this post is my recent realization that I hardly click on the arrows any more when I need to move through a lengthy document.
First of all, clicking on these small arrows has always been a challenge that scores very poorly on Fitt's law scale. Clicking on small areas of the screen is hard, especially if your mouse needs to travel over a long distance to get there.
But what is mostly causing this phenomenon is the constant improvement in pointing devices and techniques that have happened these past years, in order of discovery:
- Keyboard shortcuts. Very important, but hardly used by regular
users, and sometimes even abandoned by power users because they only work
well under certain focus conditions. If you have ever pressed "space",
expected the document to scroll down and realized that your cursor is in a
text field, you know what I mean.
- The wheel. One of the best UI inventions of the past decade.
It is by far the most intuitive way to scroll a document and it is
universally cherished by power and regular users alike. There is
simply no way to misunderstand how the wheel works. Note however that
it does require certain focus conditions to be met as well, just like
keyboard shortcuts, but the good news is that you can fix this problem by
using the same device you are trying to operate (as opposed to keyboard
shortcuts, which might force you to leave the keyboard, move the mouse,
click somewhere and then move your hands back to the keyboard).
- The trackpad, which is very efficiently standing in for mouse scrolling
on laptops. The trackpad in itself doesn't really help you scroll
through a document, but a few innovative ideas have been implemented
recently by manufacturers that make scrolling with them a breeze, albeit to
the price of some extra complexity. I know of two such methods:
- Side scrolling. Put your finger on the right hand side of the
trackpad, keep it pressed and move your finger up or down. This
method is very effective and traditionally found on Thinkpads.
- Double finger touch. Touch your trackpad with two fingers simultaneously, keep them in contact with the surface and move them up or down. This method is a bit more intuitive than the one above because you can touch any part of the trackpad to enable it.
- Side scrolling. Put your finger on the right hand side of the
trackpad, keep it pressed and move your finger up or down. This
method is very effective and traditionally found on Thinkpads.
With all this in mind, it's hard for me to come up with a reason to click on any of these tiny arrows any more, and yet, I see a lot of people do this on a regular basis. The arrows are definitely not going away, so maybe software vendors should come up with way to make them a bit more friendly, such as maybe magnifying them as the pointer comes in their vicinity?
How about you, how do you scroll through long documents?
March 24, 2006
A programming language for 2010
I just came across a fascinating presentation called The Next Mainstream Programming Language (see links at the bottom).
It was made by Tim Sweeney, the founder of Epic, a video game company that created Unreal.
The title of the presentation is actually misleading, because the topics addressed by Sweeney in his presentation are not exactly about the next programming language but more a reflection on the programming requirements of the video game industry with hard number and real code. What makes this presentation much more special than other typical talks trying to explain that "performance is really important and you need to squeeze as much power as possible in your code" is that Sweeney has obviously thought a lot about the bigger picture behind these problems, and as a consequence, he offers some startlingly insightful suggestions to address these problems, mostly coming from... Haskell.
That's right, Haskell.
Now, Haskell is not exactly known for its speed, but the concepts that it allows to express turn out to be a very fitting match for the challenges of video game programming.
He breaks down game development in three distinct kinds of code, in increasing order of FPU usage:
- Gameplay simulation: can run with lower animation speed and typically involves C++ and a scripting language (0.5 GFLOPS).
- Numeric computation: low-level, high performance code, almost exclusively C++ with a strong functional slant (5 GFLOPS).
- Shading: generates pixels and vertex attributes, runs on the GPU, "embarrassingly parallel" and done in a homegrown scripting language called HLSL (500 GFLOPS).
They use no assembly language. Ever.
Here are some of the other points found in this presentation:
- No languages today capture integers correctly. What he means is
that languages do have integers, of course, but most of the time, users
really want a very distinct subset of integers (iterating over a loop,
bounding an array, verifying certain conditions) and that if these
constraints were enforced by the language, a lot of bugs could be avoided.
- There is a wonderful correspondence between features that aid
reliability and features that enable concurrency.
- Lenient evaluation is the right default.
- Purely Functional is the right default.
- The Java/C# “exceptions everywhere” model should be wholly abandoned.
All dereference and array accesses must be statically verifiable, rather
than causing sequenced exceptions
- By 2009, game developers will face CPU’s with 20+ cores, 80+ hardware threads, 1 TFLOP of computing power and GPU’s with general computing capabilities.
Some of these assertions are quite bold and usually heard from hardcore language zealots without any justification, but Sweeney has plenty of hard data and convincing examples to make you think really hard about the implications of these ideas. Besides, he can hardly be called a Haskell zealot: not only does he say "Haskell family: [syntax] quite scary :-)", he also has a slide explaining why Haskell is not his favorite language. But he knows to see beyond the surface and pick up the concepts that matter to make his job easier.
I have always argued that a lot of advances in user interfaces and programming paradigms have been driven by video games and game developers. This presentation is making my point better than I ever could.
Note that you don't need to know anything about advanced graphic concepts to find this presentation interesting.
Links: pdf, PowerPoint.
March 16, 2006
A fond farewell to C++
I recently attended a presentation of C++0x by Bjarne Stroustrup. It wasn't pretty.
C++0x is the next version of the C++ specification and it's scheduled to be final in 2009. Yes, you read that right: 2009.
"Well, okay, I guess that with such a distant deadline, the changes to C++ are going to be completely revolutionary, right?"
Right?
Not really.
If you are a hardcore C++ developer, I'm sure you will welcome these modifications, but anyone with a simple passing (or forced) interest in C++ will be less than impressed and will probably shrug the whole effort away and go back to using gcc while avoiding templates because they are still buggy in that implementation.
So, what's going on with C++? Here is a quick rundown (obviously not exhaustive).
- Make the language easier for beginners, for example by providing easy
ways to convert ints to strings.
- Get rid of the maddeningly mandatory space required between ">" signs for
templates. It's about time users, and not compiler authors, got the
last word on that one.
- Scoped macros, one of my favorite features: you
can now clearly delineate where your macros apply and when they become
undefined with... well, macros (#scope / #endscope). The intent is
noble, but rescoping existing macros is probably not going to happen, so
this change will only benefit new macros.
- "Admit the GC as a valid implementation technique". I am quoting
this directly from Stroustrup's slides because the phrasing is too precious.
It looks like there is something to learn from "next generation languages"
(Java, C#) after all...
- Type inference, woohoo! In C++0x, variables can declared with
auto. Now we're talking 21st century.
- Better runtime type information, dubbed XTI ("Extended Type
Information"). Reflection for C++... Well, as much as possible
anyway.
- Template typedefs. A long overdue good idea that will make templates (and related errors) a tad more readable.
As you can see, nothing that is really going to help C++ programmers raise the level of abstraction where they are currently stuck: no closures, no LINQ, no new keywords, and still this unavoidable exposure to all these low-level details that fewer and fewer people care for these days. Why do I even need to know about the existence of iterators when all I want is to work on every element of a collection?
I wrote my last line of C++ about nine years ago, so my exposure to Java, C# and Ruby these past years has undoubtedly made me very biased, but I have to say I found all the snippets of code that Bjarne showed absolutely dreadful to read. Coding conventions have never been the forté of C++ programmers, but with the advent of templates, partial specialization, traits and other advanced programming techniques, C++ code has become a terrible alphabet soup mixing lower case, upper case, all caps, camel case, *, & and [] and const appearing sometimes left and sometimes right, underscore sometimes followed by a capital, other times by a lowercase character or an all-caps word, etc...
Now, to be fair, you need to remember that from day one, C++ has been submitted to extremely strict constraints that have had a very strong impact on its design. I certainly give credit to Bjarne and the C++ committee (which I used to be a part of) for never forgetting their users and keeping in mind that breaking the slightest feature in the language will result in millions of lines of code breaking across the planet.
Having said that, it's becoming increasingly clear to me that C++ is turning into a niche language, and if you want to start a new project, you'd better have some very good reasons to pick C++. Chances are very good that Java, C# or Visual Basic will fit the bill in 99% of the cases.
Good bye, C++. I'm looking forward to reusing my C++ brain cells for concepts that will help me tackle the software challenges of the next twenty years as opposed to not forgetting to insert a space in my code or remembering to free the memory that I'm not even sure I allocated in the first place.
March 13, 2006
Privacy exposed
Do you document your private methods and fields?
I do.
I realized this not long ago when I was trying to use a field, forgot exactly what its type was, put my cursor on top of it and waited for the tooltip to appear.
Now, why would you want to add JavaDoc comments to parts of your code that will be skipped by JavaDoc? For your IDE, of course.
In theory, you should never need this since the class and the name of your fields should be self explanatory, but there are times when real comments come in very handy. Compare:
List<Account> m_accounts;
with
Map<String, List<Method>> m_groups;
Again, this example is a bit borderline. When your types become a bit contrived such as the one shown above, you should probably consider creating a class to hold them:
public class GroupMap extends Map<String, List<Method>> {
or even better, use composition instead of inheritance to make sure you only expose in your API what you really need. Still, this practice is sometimes overkill, especially when this private field will only be used in one class.
Exposing privates is something that is very Java-y. I remember being quite surprised the first times I read Java code. Not only were implementations and interfaces mixed up in one class, the private fields were shown at the top of the class! C++ programmers usually put the private parts of their classes at the very bottom of their code in order to focus on the important (public) part of their class, and you tend to browse header files more than the real implementation when you are trying to find out how to use an API.
It took me a while but I finally got used to it. I still think there are pros and cons to this practice, though:
+ When you read a class, seeing the private fields first might give you a better sense of how the class works.
- Very often, the first thing I'm interested in when I read the code of a class is its constructors, and private fields get in the way of this information.
Still. At the end of the day, if you see some Java code that is not immediately obvious to you, the simple fact that you're wondering whether you should add a comment or not means you probably should.
How about you, do you document private methods and fields?
March 10, 2006
Losing my marbles again
I will always remember the first time I saw Marble Madness.
It was around 1984 and my main computer had been an Apple ][ (then ][+ and then ][e) since around 1979.
One day, I walked past a computer store that seemed to be attracting a lot of people. I made my way through the crowd and stared in disbelief at the beautiful game that was being shown. My jaw dropped at the resolution of the screen, the vibrant colors, the unbelievable animation and the mystifying musical score...
Of course, I had heard of the Amiga. Who hadn't? But at the time, the Atari 520 were all the rage for their cheap price and abilities that far surpassed those of the Mac Intosh.
This was going to change soon.
Days after seeing Marble Madness, I was still dreaming of the mesmerizing images that were etched in my memory, and deep inside, I knew that techno-lust had put an abrupt end to the relationship with my beloved Apple ][.
I was fortunate enough to have parents who understood the value of computers, so it only took a few months of bargaining to convince my Dad to buy an Amiga 1000. Quite a purchase at the time, but the potential was just too good to pass up.
Needless to say that I absolutely had to try this Marble Madness clone called Rolling Madness 3D. This game has pretty much been coded and drawn by one person called Luca Elia, who reproduced the game on Windows on OpenGL. Even though today's technology certainly makes this kind of game easier to program than 25 years ago, I still have to bow to Luca's skills: Rolling Madness 3D is extremely faithful to the original (including the music) and he even threw in a few personal touches, such as a few extra views.
Thanks, Luca!