Javia blog

I just participated to the first MoMo event to take place in Poland, Mobile Monday Warsaw. There were about eight presentations, of which I most enjoyed the NFC talk by Florian Resatsch from Servtag, and the MRIA (Mobile Rich Internet Application) talk by Alex Nerst of fring (both are start-up companies). The event was well organized, and represented a great opportunity to introduce a new product or make some local industry contacts. It seems MoMo will happen again in Warsaw in the coming months, and hopefully it will also get adopted in other Polish cities (like Krakow).

Congratulations to the organizers!

I describe here a simple technique that can be used by touch buttons (on a touch-screen interface) to improve, over time, the accuracy of the user touches.

Each button keeps track of the place where the user touch occurs. The touches which are close enough to the button centre are deemed sure touches, meaning that the button is pretty sure that the user wanted to touch this particular button and not a neighbouring one. For example, the button can use an embedded smaller circle or ellipse, called the sure area, and all touch that occurs within the sure area is a sure touch.

Each button averages all its sure touches that occur over time. When a certain number of such sure touches is accumulated, their average is compared with the ideal button center. If a systematic bias is detected (e.g. let’s say that the user generally touches with 3 pixels above the button center), the button records the bias and corrects it in future touches. (alternatively this can be seen as the button moving its center to the actual place where the sure touches occur in average).

The adjustment also affects the definition of future sure touches, as a touch is first corrected before being checked for happening within the sure area.

After the adjustment, the button continues to keep track of new sure touches as they occur, and to make new adjustments as needed.

This technique is most effective when every button keeps track of its own correction parameters. For example, a button which is located at the top of the screen may have a different bias (and thus need a different correction) than a button located at the bottom of the screen (or buttons located left - right may need different correction, etc).

This technique allows the interface to ‘learn’ over time the touch habits of a particular user (and to optimize itself for that user); but the interface is also able to adapt to a new user (if the device, for example, changes its owner).

For this technique to work, UI elements (such as buttons) must have access to touch events from outside their visual area on the screen. What the dynamic adaptation achieves is a separation and translation of the touch area of the button independently of its visual area.

The technique as described above supports the translation of the touch area, but can be easily extended to handle other transformations (such as dynamically growing the touch area of a button when the distribution of the touches shows too many touches close to its border, suggesting that the button is too small for the particular user).

When the touch area of buttons is segregated from their location (visual area) and is mobile (can move or grow/shrink), conflicts may appear between neighboring buttons. How to elegantly handle such ‘touch area conflicts’ is left as a thinking exercise to the reader or implementer.

I just released version 1.3.0 of the Arity library, with a major addition: Complex Numbers. In addition to basic operators on complex numbers (like addition, multiplication, division), all the standard function are supported: trigonometric & hyperbolic, logarithm, exponential & power, factorial (Gamma), and even combinations, permutations and GCD. It is nice that many analytic functions behave better on the complex domain than on the real domain: for example, the logarithm is defined for negative arguments, asin() can take arguments greater than 1, and a negative number can be raised to any power (which results in NaN on reals).

Ever wondered how much is: e^(i*pi), log(-1), i!, i^i, sinh(i*pi)? You can download the arity-1.3.0.jar, and evaluate any expression like this:

java -jar arity-1.3.0.jar "e^(i*pi)"

An essential trait of Arity is that it works on MIDP devices (mobile phones) which have limited RAM & CPU. As such, it has a lightweight and efficient implementation. For example, the Complex class (implementing the complex operations) is done in a way that avoids new object creation, which is different from some other Complex Java libraries I’ve seen.

Enjoy!

I’ve just run my second marathon, this time in Krakow instead of Warsaw. In the 5 weeks before the marathon I have run a total of 4km, so I can say that I had zero training — I was wondering whether I’ll be able to finish the marathon at all.. and yes, I did it. I ran slowly, with a total time of 4:51 (half time 2:10). The weather was very cold, windy and rainy, I had to eat bananas all the time to keep up the body heat. It wasn’t easy, but I can say that the satisfaction of running it to the end (without training) was great.

Still, if you plan to run a marathon yourself, I recommend at least three 21km runs prior to the marathon — this can save you from a lot of pain and even injury during the real course.

Yesterday I ran the Warsaw Half-Marathon (21km) with time 2:00:58 (two hours and one minute). It was a very nice event, the weather was great (in fact I’ve got a bit sun-burnt during the run) and the running was not painful, quite the opposite. I improved my time from last year’s half-marathon with about 9 minutes.

What was particular this time was that I trained… almost not at all. All my training this year was one 10km run and one 9km run (the reason being that the weather was rather cold this spring, while I enjoy running above 10 Celsius; not to exclude pure laziness though).

Given my lack of training, I was afraid I won’t be able to even finish it — it’d be enough to run a bit too fast in the beginning, and I’d be dead at 15km. But everything went well, I could maintain an even rhythm all along, running with about 10km/h without any breaks. I didn’t notice the two hours going by, it seemed as if it were a mere 15minutes. And the weather was great.

The blog was pretty dead lately, except for some really good comments I got on past posts on MIDlet signing — I was quite busy at the day job, and still am. But I thought I’d share the news in a tiny post:

I’ve taken out the arithmetic engine from Javia Calculator, re-written it, cleaned-up the API, packaged and released it under Apache 2.0 (open source):

Arity, the Arithmetic Engine for Java. Enjoy!

It works for both JavaME (MIDP) and normal Java (SE). I’m rather happy with the API and the code, it turned out elegant, compact and (as usual) very efficient. Hope you like it..

JSON is the new XML.

JSON, the “JavaScript Object Notation”, is a very simple notation for representing hierarchical data. It achieves what XML was supposed to do, and in a very simple way.

While the XML spec is hundreds (thousands?) of pages, the JSON spec fits comfortably on one page. Although the name suggest an association to JavaScript, JSON is in fact language-agnostic. There are JSON libraries for almost any language out there.

Sample JSON fragment:

{
"name":"John",
"tel":["+16051231234", "+48885003300"],
"address":{"street":"Dyamond 8", "city":"San Francisco"}
}

JSON has elementary values (strings, numbers; e.g. “foo”, 10), arrays marked by square brackets (e.g. [2, 4, 8]), and maps (also named ‘objects’) which contain key:value pairs between curly brackets (e.g. {”name”:”John”, “age”:”10″}).

Because of its simple and uniform structure, JSON is very simple to parse (this is a major advantage over XML). JSON is more compact then XML. JSON is more ‘pure’, more elegant than XML. And because of its ability of representing arbitrary complex hierarchical structures, JSON is just as powerful as XML.

While XML had all the hype, JSON is quietly getting the job done.

Follow-up: quite funny, only one day after I wrote this article, there was a similarly-themed post on CEO’s blog: JSON for data exchange (vs. XML).

The problem

Let’s consider the classical ITU-T 12-key phone keypad:

There are two main ways to enter text using it (for example when writing an SMS): multi-tap, and predictive text input.

Predictive text has its own set of advantages and disadvantages, but I won’t discuss it here.

In multi-tap you push a button multiple times to select a letter from a given position — for example, to type ‘c’ you push the button containing the letters ‘abc’ three times. Multi-tap is popular and easy to understand, yet it’s very inefficient. The UTI-T letter layout (i.e. buttons with ‘abc’, ‘def’, and so no) is a lousy one for text input, and the explanation is historical: in the beginning, the phones had letters next to the numbers in order to allow to dial phone numbers that were presented as words (as in: Call 1-800-FLOWERS or 1-800-GOT-JUNK). So initially, the task was not to enter text, but to dial phone numbers presented as text. And it turns out that the letter layout that was chosen for that task is not at all efficient for text input.

The fix

First thing, let’s make use of the “1″ key — put letters on it to un-crowd the 4-letter keys (e.g. “7″ has “pqrs”) . We still have the three bottom keys (*, 0, #) to put space, symbols and digits switches.

Letter Frequency

We also use the fact that in a given language, the different letters are not equally important — some letters are used much more frequently than others. For example, in English, the top-9 letters (ETAOINSHR) account for 70% of letters used, while the bottom-9 letters (YPBVKJXQZ) account for less than 8%. The obvious thing to do is to place the most-frequently-used letters on the first position on the keys, so that they are easier to type.

One may observe that the letter frequency is language-specific. While this is obviously true, it also happens that there is a large amount of similarity in letter frequency among Latin-alphabet languages from as diverse families as Germanic (e.g. German, Dutch, English), Latin (e.g. French, Spanish, Romanian) and Slavic (e.g. Polish, Czech). Surprisingly, there is a great deal of overlap of the most frequent letters in all Latin-alphabet languages. This means that using letter frequency we can come up with a layout which is good not only for English, but for many languages (a similar situation exists with the Dvorak keyboard layout).

For example, doing an informal frequency-weighting between English, French, German, Spanish, and secondarily Polish and Romanian, I came up with these top-9 letters (in order): EATINSORD. What’s to note is that H, which is rather frequent in English but rare in all the other languages, has been dropped in favour of D, which is frequent in many languages, and not too bad in English either.

So, based on frequency, we categorize the 26 letters of the Latin alphabet in 3 groups: the top-9 which will be placed on the first position, the middle-9 which are placed on the second position, and the bottom-8 which are on the third position on the keys. These groups are:

Bigram Frequency

With multi-tap there is a problem when two successive letters (in the text) happen to be on the same key. In this situation usually the user has to makes a small pause before advancing to the next letter.

For example, to type “ba”, you push twice the “ABC” key, make a pause, and push once more the same key.

This pause is annoying and slows down typing, so it’s good to reduce the number of cases when it’s needed. This is accomplished by putting together on the same key letters that appear seldom in succession. For this we use the bigram frequency, which is the frequency (in a language) of two-letter pairs.

An additional optimization is to eliminate the ‘rotation’ when multi-tapping the same key. Once the last letter on a key is selected, and the user pushes once more the same key, the typing automatically moves to the next character instead of ‘wrapping around’ to the first letter on the key in a circular fashion. The benefit is that after the last key on a button there’s no need for the same-key pause.

Let’s consider a key with 3 letters, let’s name them A,B,C. They are on the key in this order, A-B-C. In this situation, the frequency of the same-key pause for this key is given by: f(wait)=f(AA)+f(AB)+f(AC)+f(BB)+f(BC), where f(AB) denotes the frequency of the bigram AB.

On each key we choose one letter from each of the three frequency categories (most-frequent, middle, least-frequent), as to minimize the same-key wait based of linguistic bigram frequency.

Physical placement

Once we have the groups of letters for each button, we attempt to optimize the physical placement to increase the ergonomy while typing. There are many factors involved here (e.g. how does the user type, one hand or two hands? thumb or index? etc). I attempted to minimize the amount of finger movement between successive letters (because it takes a longer time to move the finger a longer distance) — again by using bigram frequency. Also, I tried to make the layout memorable (the first letters form pronounceable words on rows), and to place the most frequent letters (EAT) on the easiest to reach keys.

The Layout

A tentative layout resulting from these considerations is below. While it may still benefit from some improvements, it’s already much better than the classical UTI-T layout.

I call this layout ATI SER NOD, from the first-letter (the most frequent one) read by rows.

In Java, a class literal is a construct of the form String.class, which returns the Class object that corresponds to the named class. You can use this to test the exact class of an object, like this:

boolean isInteger(Object obj) {
  return obj.getClass() == Integer.class;
}

(A similar goal can be achieved by using instanceof, even though the semantics and the performance are not exactly the same.)

If you try to use the class literal on CLDC 1.0, it won’t work. You get at compile-time the rather funny error message

class file for java.lang.NoClassDefFoundError not found.

The explanation is that, up to and including Java 1.4, the class literal is emulated this way:

static Class class$java$lang$Integer;

static Class class$(String className) {
  try {
    return Class.forName(className);
  } catch (ClassNotFoundException e) {
    throw new NoClassDefFoundError();
  }
}

boolean isInteger(Object obj) {
  return obj.getClass() ==
    (class$java$lang$Integer != null ?
      class$java$lang$Integer :
      (class$java$lang$Integer = class$("java.lang.Integer")));
}

So the innocent-looking Integer.class is translated into a bunch of code, which can throw a new unchecked exception, NoClassDefFoundError. The problem is that CLDC 1.0 doesn’t provide this exception class, so you get a compilation error.

The solution? Use instanceof if possible. Another solution is to use a static final member initialized by calling getClass() on a dummy instance.

static final Class INTEGER_CLASS = new Integer(0).getClass();

The OpenMoko mobile phone, with a completely open software stack, is available starting today for $300. http://openmoko.com/

A template is used to generate a text string based on some data parameters. A simple template for a letter:

Dear ${name},
please pay us ${amount} dollars.

You use a template like this:

letterTemplate = Template(templateString)
letter1 = letterTemplate(name='John', amount='100')
letter2 = letterTemplate(name='Tom', amount='200')

The template can be more powerful than simple text substitution, by using loops, conditionals, etc.

Hello ${name},
you ordered these ${len(items)} items:

{{for (i, item) in enumerate(items):}}
item ${i+1}: ${item}
{{end}}

Calling the template with some parameters

print template(name='Joshua', items=['bottled water', 'milk', 'icecream'])

generates this output:

Hello Joshua,
you ordered these 3 items:

item 1: bottled water
item 2: milk
item 3: icecream

How difficult is it to implement such a template engine? 60 lines of python code:

import cStringIO as StringIO
import re

_reExpr  = re.compile(r'\${(.*?)}')
_reCode  = re.compile(r'(?:\n *)?{{(.*?)}}')

class Adder():
    def __init__(self):
        self.indent = ''
        self.o = StringIO.StringIO()

    def incIndent(self):
        self.indent = self.indent + '  '

    def decIndent(self):
        self.indent = self.indent[:-2]

    def write(self, txt):
        self.o.write(self.indent + txt + '\n')

    def getvalue(self):
        value = self.o.getvalue()
        self.o.close()
        return value

def pairify(seq):
    it = iter(seq)
    while True:
        yield (it.next(), it.next())

class SimpleTemplate():
    def __init__(self, string, origin = None):
        string = _reExpr.sub(r'{{_o(str(\1))}}', string)
        parts = _reCode.split('{{}}' + string)[1:]
        adder = Adder()
        for (code, txt) in pairify(parts):
            code = code.strip()
            if code:
                if code == 'end':
                    adder.decIndent()
                else:
                    firstWord = code.split(None, 1)[0]
                    if firstWord[-1] == ':': firstWord = firstWord[:-1]
                    if firstWord in ['else', 'elif', 'except', 'finally']:
                        adder.decIndent()
                    adder.write(code)
                    if code[-1] == ':': adder.incIndent()
            if txt:
                txt = txt.replace('\\\\', '\\\\\\\\').replace('"', '\\\\"').replace('\\n', '\\\\n')
                adder.write('_o("' + txt + '")')
        source = adder.getvalue()
        self.code = compile(source, origin if origin else source, 'exec')

    def __call__(self, **varMap):
        output = StringIO.StringIO()
        varMap.update(_o = output.write)
        exec self.code in varMap
        content = output.getvalue()
        output.close()
        return content

UTC (Universal Time Coordinated) is basically the same thing as GMT (Greenwich Mean Time). It is the zero-offset time zone.

As the world gets global, it gets confusing to use all the different timezones. It would be good to have a uniform system to name the time — and UTC is the best candidate.

UTC is already used by airplane pilots when they communicate time — because the planes travel often between timezones, and you don’t want some pilot or control tower to get confused in the time-zone names and time translation.

The local time system that is in use now has the advantage that the time (in the local time zone) corresponds to some degree to the sun position on the sky. In general you expect that 8:00am is in the morning (sunrise), and at 1:00am you expect that it’s dark.

The drawbacks of the local time system become appearent when people travel or communicate between timezones: a traveller has to adjust his watch when travelling, and continously make mental transformations to compute the time in the other time zone. Whatsmore, were there a single (unique) timezone, we could drop the timezone concept altogether, and only talk about time (or Earth time, when need comes).

Also the communication between people is now global — instant messenger, VOIP calls, skype etc. More and more people talk between timezones. It’s easy to see the babel scenario when co-workers use different time-zones each to name the time. For example:

A: What about having the meeting at 9:00 PDT?
B: Sorry, I have to leave at 18:00 CEST.
C: 18:00 EEDT works fine for me.
A: Ok, what about 8:00 PDT then?

Here is the plan for the global switch to UTC:

1. Eliminate Daylight Saving Time (Summer Time) in all time-zones (have a single time throughout the year in each timezone).
2. Merge close-by zones: Eastern Europe (EET, e.g. Romania) and Central Europe (CET, e.g. Germany) would adopt U.K. time (UTC); The United States would merge into a unique time zone (e.g. PST or EST). This should reduce the global number of time-zones to about half a dozen.
3. Start communicating the time both in the local timezone and in UTC (in order for the population to get used to UTC).
4. Abandon the remaining timezones, everybody adopts UTC only.

Of course, an ambitious endeavor, to unify the timezones. To put it in perspective, is it more difficult than the human flight to Mars? Or is it easier than the power-plug unification?

On the plus side, I think it would be enough for some major countries to adopt UTC (China, India, US, European Union, Russia, Japan) and the others will follow.

Among the first things I’ve been imprinted with at Google, is that Google is a very secretive company. I’m not allowed to tell almost anything about [the inside of] Google. I don’t even know how I could ever post anything mentioning the word Google on my public blog, but given that I’ve read public blogs of other googlers, I imagine that just blogging may not be a reason for immediate firing. Just for caution, I’ll try to restrict myself to saying only positive things about Google (and this does not imply that there are other-than-positive things to be said about Google) — self-censorship is an interesting attitude.

First, I should stress that there are plenty of great things about Google — the problem is that many of these are already well known (not to mention the food).

My first contact with the inside of Google was through the interviewing process (when I was recruited). I can tell that I was positively impressed by the interviewing process: most of the questions/tasks were relevant and challenging, and the people conducting the interviews seemed compentent and smart. I also had the impression that they were looking for objective hints in order to evaluate my skills (as oposed to subjective judgement). As a simple outline of the interviewing process, I started by sending my Resume (CV) by email to Google. After this followed two phone-screens, and afterwards, four in-person interviews.

What can I say, I’d wish to become as good an interviewer as some of the persons who interviewed me. But there is one small thing that keeps me from being completly extatic about the recruiting process at Google: about a year and a half ago, I sent for the first time my resume to Google. It was not exactly the same resume, and the layout was different, but it was essentially describing the same person (me).

Back then, I got back the standard refusal email, we have no oppenings matching your skills at this time or something like this, but I think that the real message of the email was: based on your resume, we decided it’s not worth proceeding to the phone-screen phase. Meaning that the recruiter was so confident that I’m a bad candidate, that it didn’t warrant a phone-screen test.

I don’t really believe that I improved that much between then and now. I rather think that I experienced a glimpse in the recruitment process: either Google hired a bad candidate now, or the recruiter hurried to drop my resume back then — I hope it’s the last. Of course, Google (like some other companies) is more concerned about avoiding a bad hire than about losing a good candidate — or in other words, a false-negative is preferred to a false-positive. From the employer perspective, it’s preferrable to err on the side of caution; what I’m surprised is that my resume was judged so bad that I didn’t even make it to the phone-screen.

PS: if you’re interested in a software development position at Google, you may be better-off sending your resume (CV) to a Google employee you know for them to refer you, rather than doing a spontaneous application. And second, Google is hiring in (extended) Europe and Russia, so don’t be put-off if you don’t live in the US.

Temperature

I am an european, and I’m travelling in the United States right now. Many things are different: the power voltage is 120V instead of 220V-240V in Europe. The frequency is 60Hz instead of 50Hz in Europe. The power plug is different, having two thin blades instead of two round pins in europe. This is un-convenient, as somebody coming from Europe with a laptop, mobile phone, battery charger, etc. needs a plug adapter if he’s lucky (if the device can take either 120 or 240) or a power adapter if he needs to tranform the voltage. Of course, this creates a whole market for the manufacturers of plug-adapters. When I once suggested that we (i.e. the whole world) should standardize the power plug and voltage (that is, to have a single kind of plug that works everywhere), somebody asked than what would all these companies that specialize in plug adapters do…?

In fact, the different power and plug is not present only in US, but also in Canada and Mexic. In Europe, everybody uses the normal power voltage and plugs, except United Kingdom, where the voltage is normal (230V) but the plug is specific (different from both the european and the US one). What’s interesting is that in India, which was once a British colony, the power voltage and plug are the same as in continental Europe (not the UK plugs).

In this world where people are travelling more and more often between countries and continents, this plug mismatch problem is silly. We need, we have to standardize on a plug that works everywhere, and on compatible voltage for electronic appliances. Now the question is: who should make the change? the answer is simple: let’s keep the most popular system in place (if there is a dominant system), and the countries that don’t use it already would switch. In other words: first, the UK should adopt the european plug (they don’t need to change the voltage or frequency). Second, the Northern America should switch, first the plugs and next the voltage/frequency.

On a side note: Do you think such a change is difficult? yes perhaps it is, but of course it doesn’t match the United States’ apptitude for change: a few monthe ago, the US changed the daylight saving time (summer time) hour system, getting out of sync with much the rest of the world. This seemingly small change had huge costs, but the politicians justified it by the large electricity savings they expected the different hour change to bring. As the power and plug standardization would also bring large savings in plastic, manufacturing, energy, and human dis-comfort, it looks like nothing could stop America from jumping on it.

Oh, but it’s more. Afther adopting a world-standard power system, the US could continue with adopting.. for example.. the metric system? And the Celsius temperature scale?

Of course, the natural question is, why have not these standardization steps took place already? and why would they happen now? The answer is that the US, or the (North) American continent is no longer an island. Of course, people have always travelled far away, but now there is an explosion of travel and an implosion of distances (and it’s just the beginning). What would you think if you lived in a house that had different power voltage and plugs in every room?

So, let’s imagine that the enterpresing US does it all: the switch to 230V, 50Hz, european plug, metric system, Celsius temperature. And they say: we’re done, what’s to do next? And everybody starts to think what else is left to standardize?

The Sun WTK is finally available for Linux again, you may now download the WTK v 2.5.1. The last WTK version which was available for Linux was 2.2, after that WTK was windows-only, and now by popular demand the Linux version is back.

The WTK is the primary tool for JavaME (MIDP) development, i.e. for writing midlets to run on mobile phones.

Last Sunday I participated in Warsaw’s half-marathon. I’ve run it to the end, 21km, in just under 2 hours and 5 minutes; that is an average speed of ~10.1km/h. I was lucky the weather was good, warm and sunny.

All in all, it was a great experience, and I’m really happy I participated. I would recommend it to anyone to run a half-marathon, at least once. And it’s not that hard: I’ve only had 2 weeks of training (running in the park) prior to the course. For two days afther the half-marathon, my legs muscles were hurting a bit..

My wife waited for me at the finish line. We were expecting I’d take 2h30min, and she was surprised by my performance
I’ve got a medal (everybody who finished got one), and there will also be a nominal dyploma mentioning my time.

And a tip for prospective long course runners: you may run as slow as you want, as long as you keep running (not stopping or walking). If you get tired, or you can’t breath enough, slow down the pace as much as you need, but keep running — this is the most efficient way to gain time (not stopping).

Let’s consider this hypothetical scenario:

A core-IT company is recruiting highly-skilled IT professionals. Every recruiting candidate must fill a number of standard forms, for example:

• non-disclosure agreement (NDA)
• code sample agreement
• self-identification form
• employment application
• bank account information
• itemized expenses sheet

Some of these forms are accompanied by corresponding explanatory documents, which explain how and why to fill the forms, etc. (these accompaniatory documents are just for the information of the candidate, they don’t have to be filled or returned).

And now, let’s propose two realistic ways of implementation:

Scenario A

The recruiter send an email which has attached a zip file containing a mix-and-match of a dozen of Word and Excel and PDF documents. The candidate (an IT professional) tries at first to fill-in these documents electronically, on the computer (in order to print them already filled-in), but quickly realizes that they were not designed to be filled on the computer. They are made for ‘pencil & paper’ filling, and trying to fill them on the computer is a pain, not worth the effort (imagine editing text in a jpeg image, to get an idea).

So that’s what the IT professional does: prints them all, and proceeds with the totally inhabitual activity (for an expert touch-typer) of hand writing, taking care to respect the ironic indications that appear on the documets, like this:

Name of Candidate (please print): ________

To translate, in this context please print means: please use all-capitals while hand-writing — no, it doesn’t make reference to using a printer device.

Having finished the labour-intensive activity of hand-writing (potentially going through a couple of iterations), the candidate signs the documents and admires the finished work: what an interesting font I have..

Note: of course these paper documents have a penchant for redundancy: the candidate has to fill his name, address, etc, repeatedly on each document.

The candidate takes the bunch of papers with him, and presents them to the recruiter, who enters the paper-written data into the company’s recruiting information management system.

Scenario B

The recruiter provides the candidate with a ‘candidate ID’, which the candidate uses to log in on the restricted-access recruiting web site.

On the web site he finds a (single, comprehensive) web form that he fills in (in the browser, not on paper, btw). When he submits the web form, his data is registered in the recruiting information system, and a number of nice PDF documents are dynamically generated, all personalized and already filled with his data (name, address, etc).

The only thing missing on these generated PDF documents is the candidate’s hand-written signature, so he prints and signs them (talking about digital signatures in our situation would be too large a leap…)

Later the candidate presents to the recruiter the signed documents. The recruiter only has to deposit the papers in the archive, because the data was already entered in the information system (it happened when the candidate submitted the web form).

Well, that’s it. What scenario would you bet is used by our hypothetical high-IT company, for recruiting high-IT professionals?

Today I had some fun with Python and the result is a cute icon generator (inspired from 9-block patches and indenticon).

The images are dynamically generated so you’ll get a fresh set at each reload:
http://blog.javia.org/icons/medium

They are also available in large http://blog.javia.org/icons/large and small http://blog.javia.org/icons/small sizes, enjoy

I’d like to thank the blogs that linked to my article “Assembly Java”, a post written with a certain amount of irony, as I can’t consider its so-called hints and tips good advice myself. This was the very first publicly read article from my blog and it marked, so to say, my debut in the blogging society.

First C. Enrique Ortiz mentioned my post on his Mobility Weblog. David Beers, on the Software Everywhere blog, wrote about Optimization vs object orientation followed by a concise conclusion, pointing to the right middle ground between high-level design and low-level optimizations. He makes the point very well, [..] don’t start thinking of Java as if it were assembly language or you’ll miss out on the advantages it still holds over C for many kinds of mobile development. Edoardo Schepis questions whether is still there any Java ME Programmer Thinking in Object and warns against optimization extremists; his post is an entry on this week’s Carnival of the Mobilists. And most recently, Thomas Landspurg on the TomSoft blog writes about J2me mobile development practices.