Rant on The Concept of Task Scheduler

<rant>
A few days ago; browsing Wikipedia; a small little detail caught my eye.  The .NET framework is finally getting a means to schedule tasks.  Task schedulers are nothing new (they have a fairly long history), the most prominent at the moment are Intel's Thread Building Blocks and Apple's Grand Central Dispatch + Operation Queues.

In general, the idea is very simple.

Threads + critical sections + error-prone humans writing code = race conditions + deadlocks + other "joys".

Ok.  That's not good!

The race conditions are never a good thing.  What we want is to get rid of race conditions (or eliminate their likelihood).  Race conditions arise from bad use of critical sections, such as two threads mutually blocked for each others' held resource.

Eg.  Thread A needs fish and thread B needs bread.  Thread B has the fish and won't relinquish until it has the bread.  Thread A has the bread and won't relinquish it until it has the fish.  Deadlock.

Eg.  Thread A should complete it's tasks first, but thread B manages to get started ahead of time due to a programming mistake.  Race Condition.

For deadlocks, we just need ensure that a task only starts when it has all it's resources available, and when it ends it doesn't keep a hold on any resources.

For race conditions.  We do the same; make sure that the order is properly specified.  Rather than specify a list of things to do with convoluted gates keeping everything running in order; we tell the underlying system what the order is as a tree of dependencies.

Grand Central (from my quick reading) helps with the former and a bit with the latter (it uses semaphores).  Operation Queues and Intel Thread Building Blocks focus on the latter (I'm more familiar with this model of operations).

I'd go into details of the specific APIs; but that can be found all over the web - and more coherent than I'd ever manage to write it.  And the APIs are moving targets, the concepts not so much.
</rant>

Rating Software Goods

<rant>
Normally, when rating a piece of software, I think numbers.  How many features?  How fast?  Kitchen sink?  It's starting to dawn on me that this thinking is what leads to abominations that Visual Basic is so well known for - forms with countless features.  Quickly wired up - frais-du-jour!

So my thinking is starting to shift towards: how can we quantify the usability of a user interface?  Looking at the runaway success of the iPhone's UI - there must have a way to assign a metric?

In the physical world, we'd call it the quality of the product.  Something made of cheap parts is expected to die sooner than something made of quality parts designed to last.  It's common sense - in a sense.

How do we build a UI?  Maybe the construction will lead to the quality questions.  Hmm, Windows Forms, drag a few text boxes, connect it to an Access database - and voila - instant abomination!

Wait, a quality UI....  That requires thought.

Recently, my thinking is that a good UI is like a good book.  A good book does not need a manual to read - in and of itself consists of the manual.  Some books are technical in nature demanding a certain background - just like certain software demands more knowledge of their users.

A good book does not confuse the reader by overloading them with information.  Neither does a good UI.

A good book will have information that is easily accessed.  So does a good UI.

A good book will have a consistent writing style.  So will a UI be consistent.

A good book requires a lot of forethought and consideration as to how all the chapters will flow.  A good UI, I'd argue, requires just as much thought.  Blindly throwing text boxes is the equivalent of a rough draft of a book where ideas are present without any links or structure.

For example, a good book will usually try to use a person's intuition into a given matter before burdening the person with the technical aspects.  Therefore, once the technical aspects are presented, the reader just needs to learn terminology as the concept already makes sense.  UIs generally miss the boat in this regard.  And that's a challenge to resolve...

Note:  I'm aware of the click count as a metric in web pages.  But I'm inclined to say that UI design trumps click count.  And good UIs don't require that much effort on the user (the comment is circular on purpose).
</rant>

Rant on Rapid Prototyping of Software

<rant>

I tend to vote for throwaway prototypes.  Something whose initial purpose is to test something, whose design doesn't really matter.  Where the prototype is not intended to become the final product.  My reasoning is that organized code actually distracts from getting the goal done.

Why?  because a prototype is supposed to answer some form of feasibility question.  If the prototype is designed to become the entire system, then something's wrong.  It could, in retrospect, become the final product - but this shouldn't be planned.

Why again?  agility.  If you're testing the stability of  the algorithm of a physical system, do you need to run it in the final application?  Most likely no - you know the performance characteristics of the algorithm and any computational limits that are imposed.  The goal is to write, as quickly as possible, an application to display the results and to set up the system with harsher conditions than what is expected in the final application.

Expanding on this idea - if the code is expected to be used as-is - maybe the programmer might spend extra time organizing the code, making it legible, documenting.  Actually, a prototype just needs code and a person that understands it.  Organization is over-rated - whatever gets the code written the fastest is most important (why use accessor functions when variables can be directly accessed?  why comment if the algorithm will be quickly swapped out?  why worry about aesthetics of the visualization when the goal is to observe stable and correct behaviour?

Again - let's consider a user-interface.  A very touchy subject, as reading a user's mind and knowing what's best for them is actually harder than it seems.  A good user interface does not need a manual as it is intuitive  (that's a comment on the current state of UIs though - if training on a UI is needed - something's wrong in my opinion).  I believe it more to be a hit or miss situation - UI will either be good or bad.  It's like throwing plenty of things at a wall and seeing what sticks.  Now - if we create a prototype designed to evolve into the final product, then there is a layer of organization which implies assumptions.  There is structure.  There is documentation.  Comments.  Plenty of work that has the real potential of actually being trashed rather than seeing the light of day.  It should be done as fast as possible just to ensure that users can test.  It doesn't even need real data - just a realistic progression so that users can judge of the ease of use.

What could change in a UI?  Buttons need to shift around.  Sub-windows?  Lists?  Custom controls?  Special effects?  Each of these could be added and removed at will.  A good UI should have several test versions.

Then - what happens when a prototype has discovered the path to follow?  We pillage what's salvageable and good, as quickly as possible.  We document.  We comment.  We organize.  And tackle the next challenge.

Isn't a small amount of spaghetti code to prove a concept worth it if concepts get validated or disproved quickly as opposed to developing a large framework?

As in quickly - a prototype should not take more than 4 hours.  It should be focused.  If the prototype includes building a functional version of everything - then maybe you aren't building a prototype...

</rant>

Rant on Particle Systems

<rant>

Particles are nice.  They are beautiful.  They add flair and detail through a series of simple rules.

My experience with particles has lead me to the following impressions (that will most likely evolve over time)


Soft edges on particles are required for realism - or any attempt to appear real.  Hard-edges give a cartoon-like feel.  Which, if you're looking for something original, might be just the thing.


Additive Blending looks very nice.  The continual layering of thin clouds of smoke adds for a combined amount of detail that would be hard to match any other way.  Also, the order of composition doesn't matter anymore as everything is summed.  Again, remember that different blending modes will greatly alter how your particles are presented.  Unusual modes aren't necessarily bad.  Try, fail, enjoy the results!


Expansion and contraction of individual particles over time can help particles cover more of an area as they get sparse.  Good for clouds of dust or vapour.


Reduced resolution of rendered particles won't make much of a difference.  (There's an article in GPU Gems 3: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch23.html)  That is, if your particles are diffuse.  If you're looking for hard-shading and a toon-like feel - then this isn't the wisest choice.


External forces to make the particles sway in a given direction, or conform to the rules that underly the physical objects found in the rest of the game might make sense.  Of course, doing the opposite can be interesting!


Random direction, speed, and time to live add variety to what would be a purely predictable system.  And it's this added variety that makes the particle system come to life.  Or so I believe.


Density is important.  The more particles - the better.  That's why I prefer simple soft-edged particles.  Like circles.  Textures could be used to add a bit of extra detail, or a different feel.


Most importantly, don't be scared to try stuff.  There isn't really any wrong way to do particles - unless if you're searching for some popular already-existing effect.

</rant>

Rant on Application UIs for OS X

<rant>


Six years ago, tired of Windows development, I switched to Linux. Linux I enjoyed - especially the ability to feel like I could customize anything, tweak anything, and know how to restore the system when I did a bad tweak. Yet running Office under Wine wasn't dependable enough and Google Docs just weren't ready for what I wanted to throw at it. Then there's the issue that interacting with the outside world requires some form of Windows. Dual-booting. Virtualizing.


Then - I wanted a nice laptop. At the time, Apple was the only one making laptops with some form of UNIX pre-installed. Command line + X-Windows + supported UNIX OS. What was there to not like? So I budgeted and saved for an OS X laptop. A good ol' G4 Powerbook.


This machine did exactly what I wanted. Interacting with the outside world was impossible though. I admit - I still can't use my machines for most places that require professional development. But that wasn't an issue before; the machine did exactly what I wanted. It ran Photoshop and Office (with the added bonus of all the software being officially supported on the platform).


My initial approach to the platform was the same as I'd use a Windows or Linux machine. Linux is surprisingly more similar to Windows than OS X - interface wise. Instead of stating what I don't like (it's a matter of preference, others I talk to have completely different opinions), I'll state what I enjoy:


One - Expose is your friend. Do not mess with Expose. Without Expose - I wouldn't be able to so easily navigate all of my open windows. Admittedly, it's not as fast as application switching under Windows (where I memorized the tab order of the apps, and quickly shifted among apps - under OS X it's different so it took some adjusting). I can't go back to not using Expose. As a result, I prefer interfaces that open multiple windows, and use Expose to quickly switch among windows in different applications.


Two - Everything is a document. The icons in the title-bars of windows are documents. They can be dragged, copied, and probably even trashed. Everything can ideally receive something through drag and drop, or be dragged and dropped somewhere... For example, if I'm working on a texture in a Photoshop window, I should be able to drag the Photoshop window's icon into my xcode workspace to copy the texture into the resulting bundle. It's surprising how much can be dragged into the terminal.


Three - The application icon is like a button. Most apps (except for a few exceptions) should display some form of window when there are no windows and the application icon is clicked. Essentially, as a user, there's no difference between clicking the icon to launch an app for the first time or clicking the icon when there's no window. When there is a window, they should all come to the foreground. Quitting an application is, for the most part, an optional task. I find myself leaving plenty of stuff running for no reason.


Four - Colour tells of application activity. Please don't play with the colour of the windows. OS X tends to make most of it's icons monochrome when they're in the background. And it actually helps me focus on the correct window. This also acts as an indication to when I actually use the menu-bar on top (active window determines what the menu items are).


Five - Use sheets whenever possible for Modal windows. It's common sense. Modal windows as a sheet provide a visual feedback to the user that a given window can't be used until I handle the issue at hand (like an unsaved document). Or else the user is looking for a window in expose without any hint to which must be selected since a few can't be interacted with due to a modal window waiting to be confirmed (I'm aware that in some cases, sheets aren't always enough - but that should be the exception, not the rule).


Six - Bundles. Have a folder of information that should stay together? Put it in a bundle. Advanced users can still browse the bundle and destroy the contents to their hearts desire, but regular users see the folder as a single file. Just add the .bundle extension to any folder and see it add a step to actually mucking around with the content.


Seven - Most importantly: http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/XHIGIntro/XHIGIntro.html


This rant doesn't serve as a replacement for Apple's official documentation. It's just a series of complaints that I have with some applications. An application that lives in its own sandbox is much less useful than an application that strives to provide communication channels with everything else in the OS while doing an excellent job at a single thing.


I wrote this to say I appreciate the way OS X - for the most part - allows me to do things that 'just make sense'. And when I tried a certain application (that fixed all the flaws now - so no use in singling it out) - some of these UI notes weren't implemented correctly - and the App felt like it was pasted on to the OS - as though it didn't belong. You could call it a foreign port.


</rant>

Art and the Museum - part 1

In this short opinion piece where I try to make clear certain ideas in my mind, I'd like to argue that the museum itself is no longer a representation of culture but a chapel to an artistic elite whose work builds upon itself.  Rather, culture is delivered to the masses through magazines and glowing screens flashing content.

First, let's theorize why people don't go to the museum?  Could it be that it's inaccessible?  To understand a work requires understanding of the social context and inspirations of the artist.  Something that anyone should be aware of since it's their cultural history, right?  Yet, I doubt anyone can argue, that these culturally weak people know their culture - and know it well.  It's the culture of the new and commercial.

And that's an easy culture to learn.

The artists, on the other-hand, create "thought-experiments", testing boundaries, seeing what are the limits of the fabric of society.  Creating things out of the ordinary, imagining the impossible and wanting to build the impossible.  Driving the future and making people question the present and past with their works.

Reality is not as clear-cut as above, but it's a first attempt at re-ordering thoughts that have been bothering me for quite a while.  I'll blog more until the ideas get ironed out.

Sonic the Hedgehog 4: Episode One Thoughts

Even though this looks like a good game (see http://www.youtube.com/watch?v=0CrgO5c-9m8), I worry. 

The games from the Genesis were nice and quick - the story happened as 10-second non-narrated blips between animated sprites.  Looking at more recent games (closest is Sonic Rush) - it's riddled with story - getting into a level for the first time requires reading a few paragraphs of text.

The other difference is that the older games felt as though there was much more to explore.  I can't count how many times I replayed the first Sonic game running at the bottom of the levels, top of the levels, middle of the levels, etc.

I'm interested - but skeptical.  I'm not against change - but the above two points will be part of my main criteria when deciding if it's worth purchasing.