2008 July | Polymath Programmer

Featured demo – The Seeker

July 14, 2008 By Vincent

Today’s demo is a special one. It’s titled “The Seeker” by Still the demogroup.

It’s special because it’s the most thought provoking demo I’ve seen in a long time. First, some administration: Download the demo. It’s about 9.67 MB and 4 minutes in length.

I understand that to run the demos on your computer, you usually need a high-end graphics card and the latest card drivers. You also need to download the demos, which in some cases, can be pretty large.

So I’m delighted to tell you that there are online video hosts for it! I’m actually quite surprised myself. Now you can forget about pesky computer settings and just watch the video for it. Here are two links:

Capped.TV is a video host specifically for demos, and I only just found out about it. Still, running the demo on your computer is the best way to get the full experience.

About the thought provoking part, while you’re watching the demo, ask yourself these questions:

what is the ribbon seeking?
what does the black substance wrapping the ribbon represent?
do you identify with the ribbon, that is, you’re seeking something too?

And the music is awesome. Full of longing and suspense and triumph. You should watch the demo even if it’s only for the music.

Filed Under: Curiosita Tagged With: demo, seeker, still

Mind Trap – Locked in stasis

July 11, 2008 By Vincent

[This is a continuation of the story in part 1 and part 2]

Ryan heard grinding stone behind him. He turned and walked towards the noise. A man-sized opening had appeared beside the left statue. Ryan jumped quickly past the statues, and peered into the opening.

It was dark. The inner walls appeared to be impeccably smooth. And there were steps leading downwards.

“More stairs?” Ryan stuttered. Then he realised it’s considerably colder, and the cold seemed to coming from down there.

He was about to take out the flashlight when he had a better idea. Ryan bounded back into the large room, and took one of the burning torches from its bracket. Then he came back in front of the opening. Taking a deep breath, he held out the torch for illumination and walked down the steps.

It was almost suffocating. Every step Ryan took plunged him deeper into icy cold air. His hands clutched the torch handle, the warmth from the flame enveloped him in a small protective bubble.

Ryan lifted his head at the sound of his shoes crunching snow. He had reached the bottom of the stairs, and entered a large circular cavern. The light from the torch barely filled the cavern, and ambient glow reflected off the icy walls.

A frozen lake filled the centre of the cavern, thin layers of snow in patches across the surface. Long icicles hung precariously above, almost threatening to fall and break the lake surface. A path circled the lake to the left, ending at the foot of what appeared to be another flight of steps on the far side of the lake.

Ryan started walking.

His breath came out in misty clouds and his legs jiggled every few steps from shivering uncontrollably. His hands wrapped tightly around the torch as his life depended on it. The torch flame was the only thing keeping the cold at bay.

“It’s on you if he dies.”
“I know what I’m doing.”

Ryan was halfway around the lake when he heard a crackling sound to his right. Turning slightly, he saw a jagged split in the air, hovering in the centre of the lake, spilling forth blue light. Then it disappeared as a huge icicle crashed through it, and exploded into pieces as it hit the frozen surface.

A growl sounded in the air, somehow thickening the cold even more. It was also brighter; the lake had started to glow with an orange light. Then the lake surface exploded, and Ryan crouched down to shield himself from the flying ice and stinging water.

The air immediately felt warmer. Ryan opened his eyes and saw a fearsome creature standing close to the edge of the lake near him. It had a lion in front, a goat in the middle, and a dragon at the back, flames bursting out of the serpents mouth in short spurts. It was also looking directly at Ryan.

“A chimera?”

The chimera stepped forward. Ryan backed up a little. Sensing something about to happen, Ryan sprinted towards the exit. Which was lucky, because the chimera breathed a stream of fire where Ryan was a second ago.

Realising its prey escaping, the chimera bounded after Ryan. Ryan slid and fell to the floor. The chimera jumped at him, lion’s mouth open wide, and Ryan thrust the only weapon he had in his hands out, shutting his eyes to avoid seeing his inevitable death.

When it didn’t come after a few seconds, he opened his eyes. The chimera was frozen midair. Ryan’s torch was inside the chimera’s mouth, its flames feebly flickering inside.

Ryan was wondering what happened when a sense of deja vu overcame him. A memory of him solving the puzzle in the large room with 3 statues. A memory of him standing before a lion statue. And pressing the lion’s tongue.

The chimera shimmered and then vanished. Ryan held out the torch a few moments more. Then he picked himself up and ran for the stairs at the exit.

Author’s notes

No puzzles this time. I couldn’t come up with anything good, and I didn’t want to leave Ryan stranded. So I’ve decided to just continue with the story. The original plan had 5 episodes, so there’s 2 more (this is the third).

I’m not sure if anyone noticed, but in the last puzzle episode, there was this hint:
935
9351246780

If you matched the number with the position of alphabets, 935 becomes “ice”. “i” is the 9th letter, “c” is the 3rd and “e” is the 5th. The plaque in episode 2 had this hint, so there’s “ice” at the top of the plaque, and a drawing of fire just below it. Sort of a hint of the chimera to come, the ice lake trapping the fiery beast below.

Then there’s the 3 statues of lion, goat and dragon in episode 2. Linking the solution from before into this episode was a stroke of luck. I was struggling about how Ryan could defeat the chimera…

Filed Under: Curiosita Tagged With: chimera, fiction, ice cavern

Flights of fantasy and realms of reality

July 10, 2008 By Vincent

Imagination is more important than knowledge
- Albert Einstein

During a stint some time back, I casually asked a co-worker what he thought of “Charmed”, the television series. I had to explain the concept of magic and witches to him. In the end, he said he’d much rather watch or read fictional stories based on real life, like law or police work. I couldn’t get through to him about the joys of simply asking “What if?”.

“What if you could fly?”
“What if you could stop time?”
“What if you could move objects with your mind?”

What if.

I’m going to give 2 extremely broad generalisations. Here are my observations. Asians (or maybe just Chinese) in general, are less daring to try new things. The general advice is to be realistic, more down-to-earth. Once in a while, a small spark of innovation occurs, possibly out of sheer luck, and progress is made. This probably don’t match the Asia today.

The Western world seems more willing to reach for the sky, indeed, for outer space. Leaps of faith, jumps in industrial progress and quantum bounds in science and technology.

Like I said, those are very broad generalisations. I admit that I’m a little sheltered here in Singapore, so the situation east and west of my longitude may not be as what I perceive them to be. So here’s what I do know. The education system in my country consistently churns out good students, even outperforming American students.

The thing is, parents here are, shall we say, extremely concerned about their children’s education and future. I’m actually appalled at the activities a typical 8 year old goes through. Aside from school, there’s extra tuition and lessons for English, math, Chinese, science, ballet, swimming, music and even brain development courses (I think it’s Montesorri or something). Where’s the time for fun? I’m not sure what happens in your country, but that’s what’s happening here in Singapore.

Yet we don’t have Nobel prize winners. I read in another report (can’t find the reference) an observation. The Asian countries have, on average, better students. But the Western countries, particularly America, have on occasion, brilliant students. The really bad and the really good live near each other, like some cosmic balance act.

Where am I going with this? I believe the key is imagination. My countrymen may be better at math and science on average, but the Americans landed on the moon.

So, now, finally, bringing it back to something relevant. Programming is an act of creation, of imagination. Maintaining existing code requires you to imagine yourself in the shoes of the programmers who wrote that. Writing new code requires you to imagine how the finished program is going to look like.

If you keep sticking to what’s done before, then that’s what you’ll get. More of the same. But if you indulge in your flights of fantasy, of imagining the possibilities, of trying something else, then maybe, just maybe, you’ll get something different, something awesome.

Are you ready to leave your realm of reality?

Filed Under: Curiosita Tagged With: fantasy, imagination, reality

Are we becoming simpler?

July 9, 2008 By Vincent

Genki Takiuchi is worried about the consequences if CAPTCHAs are broken.

Our activities on the Internet is [sic] too simple to recognize ourselves as human beings. There are only click, click, click many clicks and sometimes typings. Needless to say about clicks, nowadays, even typings are easy to be imitated [sic] by using algorithms of a sort of Markov-chain.

The Markov chain algorithm mentioned refers to a process where a word is looked up in a database of words. The next word following this current word is determined by probabilities based on the language used (the common one being English). And so on and so forth, until a complete sentence is formed, which may not make sense to a human, but computers can’t really tell the difference. Then again, lorem ipsum‘s don’t make much sense too…

Imagine the irony of creating artificial intelligence complex enough to pass the Turing test, yet we are simplifying our behaviour to the point where we’re indistinguishable from infant bots.

What exactly happens during the clicking and flitting from site to site? It appears to be something commonly attributed to (though not confined to) an age group known as Generation Y (born roughly between 1980 to 1994). If you belong to this group, I’d love to hear your thoughts on this.

Because Takiuchi is concerned. So am I.

Filed Under: Curiosita Tagged With: captcha, generation y

Create database user or store as table record?

July 8, 2008 By Vincent

Recently, someone posted a database user question on the Dream In Code forums. The gist of the question was, if you had to maintain a number of users for a web application, and each user needs an ID to log in, what’s the preferred method of doing it?

2 options were given. The first was to create an individual database ID for each user. The second was that all users use the same user ID to log in.

What I had in mind was, the database connection string. If individual database IDs were created, then when each user log in, unique connection strings are used to connect to the database. From what I know, this doesn’t scale very well, since the database throttles at a certain number of connections.

So the individual database ID case was no good. Having all users using the same ID would work. But there’s no personalisation, or you need some work to separate each user. Unless personalisation wasn’t an issue. Then there wouldn’t be any need to log in. I was a bit perplexed with the second option…

So I suggested that user IDs be stored in a database table. A database user ID is created specifically for online user log in’s. Every user has a unique ID to log in, and when logging in, the special database ID is used to form the connection string. Then the ID-password pair is used to verify against a table storing the user IDs.

Passwords would be hashed and stored in the database table. When a user logs in, the given password is hashed and compared with the one stored in the table.

This way, there’s only one unique connection string, and if I understand it correctly, it can be cached and reused, for better responsiveness.

I’ve dealt with both cases. In my work, there’s a department who handles the database. My applications are open only to internal users, and someone decided that user IDs must be controlled at the database side. And so each user has their own database ID. When logging in, the authentication process is handled by the database.

Basically I pass in a user ID and password. If a connection goes through, the user ID and password are valid.

This is sometimes infuriating, because my users are a fluid group. Some existing staff leave, or some new staff joins, and I have to ask the database department to update the list of IDs. The infuriating part is when a user asks me how to use the application and after some questioning, discover that she’s a new staff. Help desk support sometimes require me to question some of my assumptions…

The thing is, even though that department is handling the user IDs, I still have to keep a list of the IDs in a database table. The reason? User access. Certain users have rights to certain pages. The only way to control that is at the application level, not the database level.

On the other hand, I also maintain web applications where the user IDs are held in a database table. Maintaining the user list is as simple as an insert or a delete statement. There’s really only one database connection ID. This allowed me to easily scale the applications in terms of users.

I imagine the huge web sites such as the social media sites store users in a database table. I think creating thousands of database IDs is inefficient. Maybe I’m wrong. What do you think?

Filed Under: Programming Tagged With: database, user id

Forget about writing perfect code

July 7, 2008 By Vincent

Recently, I went to the games arcade and saw a bunch of people crowding around a game machine. Must be some friendly tournament going on. So I went to take a look, since if there’s a crowd, it’s likely the players were good.

The game was Tekken 6. One fellow consistently beat the other. Then there’s this battle where the better player defeated the other with nary a scratch. A perfect score. And this triggered some distant memory I had…

Street Fighter

When the game was out, it was the hottest thing among my friends (this was around 1990). I happened to own a console machine (find out more in a previous post), which makes one of a more “prestigious” level (you have to read that previous post to get the context).

So a close friend wanted to hone his skills, and we played on my console. Let me tell you this. I suck at fighting games initially. Probably still do, but we’ll leave it at that…

Anyway, when we were practising our moves, the first thing he did was fire a projectile at me (his favourite character was Ryu. Whose wasn’t?). I’d defend myself, because I was too scared (or inept) to successfully jump over the projectile. And I’d get hit. And a small fraction of my health bar disappeared.

After a few practice sessions, I asked him why he always fired something at me at the beginning of the battle. He’s much better at the game than me, and it’s obvious that he’s letting me get a few hits on purpose.

His reply? “So you’re not perfect.” When you have a perfect health bar, and you defeat the opponent, you get bonus points. Plus the feeling that you rock.

I was disturbed. “I’m not perfect?”

Be obsessive in the right areas

Accept that your code can have flaws. I’m not talking about glaring inefficiencies or obvious errors. I’m talking about the code being good enough to do what it’s supposed to do, and you fussing over it to make it better, at the expense of other productive tasks you can do.

I’m currently the only programmer dealing with user interface related coding (I’m in a small team). This usually means users call me as a first line support.

Time, tasks and temper forced me to come up with my own way of prioritisation. This meant programs and code had to only be good enough, not perfect.

I still write code as best as I can. I just don’t obsess over its quality because I already know it’s good.

Turn of tides

The players were feverish on the controls. One of them was launching attacks in a flurry, forcing the other into a defensive pose. The defender crouched a split second too late, and got hit consecutively. He jabbed back but was blocked. Then the attacker launched into another series of blows, pinning the defender against a wall.

The attacker did a move and it didn’t connect. The defender took advantage of this and started a whirlwind of counterattacks.

Hit, connect, hit, connect.

The attacker was on the floor, and the defender swept the floor with his leg, and hit again. Made a jump attack, and the attacker wasn’t ready.

Hit, connect, hit, connect.

With another series of moves, the defender threw the attacker onto the wall and finished the battle.

Ultimately, in a fighting game, having a perfect health bar isn’t the goal. Winning is.

Filed Under: Programming Tagged With: perfect code

Any more orders?

July 4, 2008 By Vincent

There’s this diner I frequent, where after you order your food, you get a number tag. Then I sit down at a table and wait. When my food’s ready, someone serves it and they’ll ask, “Any more orders?”.

I’ve got everything I ordered, so my answer is “No” (what other answer could I give?), and the server takes the number tag away. My answer was a “No”! The diner actually wanted their customers to say “No” to them? This probably goes against some fundamental principle of Seth Godin‘s.

Here’s a suggestion: Write your boolean checks in the positive whenever possible and relevant.

If you’re concerned with error checking,

if (bError)
{
   // handle error
}

If you’re concerned with success results,

if (bSuccess)
{
   // where's the champagne?
}

An if (!bError) requires me to think “No”.
Worse, it’s like a double negative equivalent for if (bSuccess)

So, any more orders?

Filed Under: Programming Tagged With: boolean check

What do you think of when declaring variables?

July 3, 2008 By Vincent

I’m interested in what goes through your mind, even before the declaration code is written. The moment you decided you need a variable, what do you think of? Let me give an example comparing C# and VB.NET code.

Note: This is not another language war incitement. This is an article on self-discovery and self-understanding.

In C#:

int iNumberOfApples;

In VB.NET:

Dim iNumberOfApples As Int32

Personally, the moment I decided I need a variable to keep track of the number of apples, I think “I need an integer”. Sometimes, before I’ve even thought through the whole thing, this appears in my code editor:

int

Then I decide on what name to give. When I play RPGs, one of the hardest parts was to give my hero a name. I’ve been known to falter for 10 whole minutes before giving that scrawny protagonist something to call himself. This quaint custom of mine carries over into my variable namings, though I’ve had much success in culling the time spent to seconds instead of minutes now.

VB.NET on the other hand makes me write this first

Dim

Then I have to think of a name.

Dim iNumberOfApples

By this time, I can’t even remember what I wanted to use the variable for… oh yeah, it’s an integer.

In this respect, I prefer C# over VB.NET. Other than that, I write the two languages in similar ways. Yes, I am aware that Javascript variables are typeless when declared. My point is that I can write the code for saying “I want a variable” first.

// Javascript
var iNumberOfApples;

I haven’t had much contact with other languages (note to self: go read some). For example, I don’t know how Ruby looks like… oh wait, here it is. It’s one of those languages where you can use a variable immediately without declaring it, right?

So what do you think about at the moment you decide a variable is needed?

Filed Under: Curiosita Tagged With: variable

It gets compiled anyway

July 2, 2008 By Vincent

I feel I misrepresented my intentions in a previous article. In that article, I gave a code example:

int i;
char c[3];
i = 0;
c[i++] = ‘a’;
c[i++] = ‘b’;
c[i++] = ‘c’;

Christopher commented that the code gets optimised by most modern compilers (can you see any inefficiencies in the code?). I agree with that. There was a time when I studied and adhered to basic code optimisations. Practices such as unrolling small for loops and simplifying boolean check conditions. I still do the basics (out of instinctual habit), but it’s not that big a deal anymore.

Computers have gotten to the point where small inefficiencies don’t really matter anymore. High computing speeds overshadowed any minor stalls. Compilers are also smart enough to reduce inefficient code in the first place.

So why did I cite that example? Because you haven’t had the benefit of Moore’s Law.

Imagine taking over someone else’s code and after wading through reams of code, you found that essay of a function could be reduced to a single line of code without loss of understanding nor purpose. Imagine how much effort it took you to understand all that code before you understood its purpose. If you’re lucky, there would be comments and documentation. If you’re luckier, those comments and documentation would even be relevant and up to date.

In human-first programming, you’re not just creating software for the end user, you’re also writing code for another programmer to read. The compiler doesn’t care how obfuscated the code is. It can read it just fine. You, on the other hand, might have a little trouble with the code.

Just because the code gets compiled anyway doesn’t mean you can be sloppy.

Filed Under: Programming Tagged With: code legibility, optimisation