Archive for March, 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…

 

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
.

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.
     

    Documented scrolling
  • 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.

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?

 

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#

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.

 

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?

 

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!