The pictorial representations of text: QRcodes

Quick Response codes. I think this is a passing fad, but, right now there seems to be some interest in 1D and 2D barcode like pictorial information ciphers. Hence my two pennys.

QRcode applications are one of the more popular uses of Augmented Reality systems. AR provides possibilities for really interesting use cases.

(Go! Google! Explore! :) )

QRcodes (and other 1D/2D barcode-like image formats) are useful in several ways, always as pictorial representations of textual information. 'Text to Image' encoding, if you will. The fundamental is that I can take any piece of text and encode it as a picture which can be read using a QRcode reader. Google's example implementation uses this to encode calendar events, contact info including email and phone number (a very cool use case, I must say - my visiting card can carry my QRcode), URLs and even WiFi network credentials! I have a link to this implementation later in this post.

The most common use, however, is to let a QRcode redirect you to a URL. Here, for the purposes of example and for self-recursive trumpet touting brag boast is the QR code to this blog:

What you'd typically do is switch on the QRcode reader in your mobile device, point it to this image and as soon as the three boxes (see the top, bottom and right) match the QR application's markers, it will direct your mobile browser to the URL of this blog.

Here's another:

This one actually takes you to my fiction/non-tech-rants blog-site. I am shameless.

Okay, you can read more about QRcodes all around the place. Here's some stuff to give you a head start:

If you are looking for an open source library that does everything QR (and barcodes and more!), look no further than Google's own 'Zebra Crossing' (ZXing) project:

If you are looking for a QR code generator, here's a simple one (based on ZXing):

and here's a more comprehensive, more advanced QR code generator from Google (again using ZXing):

...and of-course the token Wikipedia article:

There's two more links to consider:

1. Denso-Wave's (the creators of the QRcode format) site on QR codes: http://www.denso-wave.com/qrcode/index-e.html

2. A tutorial that I found useful (there's bad english in there, so snobs beware!): http://www.swetake.com/qr/qr1_en.html

The Denso-Wave site is recommended reading! tells ya all about versions, the amount of info that can be encoded, levels of error correction etc.

Good Stuff!

Printing:

This is the fundamental interaction that QRcodes empower. I spot a QRcode in real life and can immediately access the digital information that it serves. QR codes work like real life hyperlinks! Neat stuff!

Stands to reason that printing a QR code must be given due consideration. Of the different materials and processes, owing to their hard edges and high contrast, I think these codes lend themselves to screen printing (and digital printing) processes really well.

Typically what works best for printing is a vector image of your QRcode: InkScape and Bee Tagg help (Bee Tagg also has a very interesting alternative pictorial cipher that is based on hexagons. Its called, bee tagg - what else!).  However, both of these are limited to the "re-direct to a URL" usecase, they do not seem to support free-form embedding of text. Sigh!

However, in the bitmap world, what worked best for me was Photoshop. QRcode images are just a lot of boxes, if you resize them in Photoshop things turn out fine, except in some cases there may be slight blurring of edges. To remedy this, I just check "Resample Image" in the Image Size dialog box and select "Nearest Neighbor" as my algorithm of choice. So, you can use Photoshop to increase the size and resolution of the images that any of the generators (above) give you and print them up just fine!

I have not tested the printing of QR codes on curved surfaces. Not tested how well they can be read from various applications that is. You can still decorate your coffee mug or t-shirt with a QR code if you want to, how well these are read by a mobile device is what I am unaware of. Do let me know if you have any test results.

However, I think it is just a matter of time that there is a better image format that suits a wider array of applications, printing on straight and curved surfaces, supports greater error correction and is even more pleasing to the eye! This is why I think QRcodes and such like (as we see them now) are just a fad. There could be, for example, subtle variations of color, tone, edges etc - invisible to the casual observer's naked eye - encoded into regular images! Now that would pretty-fy things a lot! I can have my URL encoded into my logo, or my contact info encoded into my passport photograph. That is where I think all this should be headed.

But till such a time comes, enjoy looking at zebra images and thinking of all the coolth it serves. :)

---

By the way, if you are looking for a QRcode reader for your mobile, you are looking in the wrong place (...hahaha!), you should be looking at your mobile's app market place.

cheers :)

To learn a new programming language when you already know another, that is the problem.

I had an old approach and I have, over time and serendipity come up with a new one. This post discusses the old approach. The next one will talk about the new approach.

Introduction

By learning a new programming language, I do not mean "pure" programming stuff - semantics, grammar and syntax; rather, learning stuff that you can apply in a fairly real world scenario - this also means doing menial tasks etc.

The idea is that if you were to waterfall from "semantics and syntax" to "application", the learning process will become too boring and too long to be productive. So, we need an approach that can:

1. Fast track the learning (even if by a small bit) and keep the interest alive

2. Force you to understand the essential parts of the language

3. Result in something that has more value in the real world than just the language learnt. You should be ready to build some applications with the language, work in a professional setting and be able to rely on your new skills "on-the-job". Being competitive, mind, is a different ball game, that will come later.

It was by a neat chance that I bumped into this excellent post: 15 Exercises for Learning a new Programming Language.

[The same post is also available here.]

Although some of the comments on the post look really dubious, even the post itself seems to be the only good thing on the blog, the post is a gem. Kudos to the author!

Each time you learn a new language on your own, there is always the problem of knowing when enough is enough (it last happened to me with Ruby, a few months ago). So one would need a measure to determine that what has been learnt is enough to start swimming and that the rest can be learnt "on the job", as you go forward.

Typically all I've ever recommended is to build a medium scale project in the language you are learning. It struck me, while reading the post, that there was another approach. A more fun way, breaking the larger chunks into smaller, funner material. It also highlighted the flaws in my approach. I have since adapted the new proposed "fun" approach, added a few extra steps in it and am good to go.

To properly understand the updated approach, let me first type in my old approach and the logic behind it:

My (old) Approach

Keeping in mind the language and the platform, build a medium scale project. Search the web for possible ideas, but the project must have/do the following:

0. Install the bloody thing:

You'll not be comfortable with the development environment from the word go, but, you need to be comfortable enough doing the regular tasks: punching in code, compiling and running the programs etc. See if there is an eclipse or NetBeans plugin available. Google to see the other IDEs commonly used for the particular language. Try and stick to free/open source here.

My experience is that lack of sufficient proficiency in this area becomes a very big initial barrier to learning. So attack it with full force and ensure that you are comfortable with the environment before you start exploring (I know, it sounds paradoxical to start with!). Put your head to the task and just get it over with. Know the compiler command line and common deploy/execute options.

1. A graphical UI, with atleast one tabular display of formatted data:

Even after almost 20 years of work in this field, GUIs are still a challenge. From basic HTML/Javascript to native windows, Java AWT, Python and even ActionScript, no matter how simple they make GUI programming, there is always a nuance to catch.

Events, coordinate spaces, z-ordering and screen refresh - each a typically tricky aspect.

2. Create/retrieve data from a database:

This to me is the dumbest, foolishest part of learning a new language. It gets hard to configure at times and can be really confusing. Prime example: JAVA - don't you just hate it when as a novice you have to struggle with "drivers" and "connections" and such like?

I do not regard SQL as a language. It takes a day to learn it. Granted there may be nuances between SQL server, MySQL and Oracle (fck! spare me!) but that is all they are: fine details, that you can learn as you go.

So with SQL and your new programming language, you should be able to create a random database.

You'll have to learn to "connect" to a database driver/engine/manager/whatchamacallit, supply the SQL query to it and finally execute the query and output the results or confirmation.

Popular choices: Employee database (programmer, manager, employee), Accounts database (Chart of Accounts, Journal entries, create a balance sheet), Library database (book ID, details, locator), Shopkeeper's, Doctor's etc etc.

In case you are onto something like ActionScript or JavaScript, you'll have to rely on some of your previous programming experience for this part. If you can't figure a database out, just forget it and move forward.

3. Some form of sorting and searching:

[...and this was a weak step, but, most pseudo-programmers get by anyway - they delegate all algorithmic jibber-jabber to custom libraries, open source projects, google searches and/or SQL - they never develop an appreciation for the concepts. Even if you are one of these, do try this step, it helps.]

You need to have some idea of how to get your algorithms right. The boundary conditions, the speed, the limitations. The "Off-by-one" errors are the kind that I see coming up most often with most programmers. The loops run a cycle too long or a cycle too short, the comparison is not valid on the boundaries, adding an extra 1 results in invalid value-space etc. These errors are even more frequent

Not SQL based, but sorts and searches in the language you are learning. Even if this is just simple, you need to know the different ways you can do this.

4. Networks, HTTP, native code and remote objects:

You need to know how to talk to other environments. This is where you do it.

ActionScript should be able to get and set data from the HTML page/JavaScript method calls, JavaScript calls to the server, AIR calls to the native system, Python native code, Java and C talking to each other, remoting in .NET and so many other things lie in this domain.

Just think it this way: Pick up a feature in your project where something in the new language you are learning will talk to something else in one of the languages you already know. Simple.

If your language can handle HTTP, then try to understand how you can harness it. Try to add a feature that uses HTTP, even if it is simplistic.

5. Text formatting:

HTML based or native, have a fairly funky scenario where you display formatted text. One of the good ways would be to create a report on some of the statistics from your database and display it with proper formatting.

6. Multimedia [optional]:

It's a "nice to have". If your language can load/support images, audio and video, then throw some in. Just for the heck of it. It is important to know how you can load large files, manage streams of data and just plain render these on screen.

7. Data handling - Binary, text-string, streams :

Today, you need to handle binary data, JSON, XML/SOAP etc.  Seriously. So try to factor in some data throughput (maybe binary data write to a location of user's choice, save the UI layouts or read json/xml configuration strings or create application event logs or save user preferences etc) in your project.

8. Automated testing and build management:

This may seem like overkill, but, reality is that if you cannot test it, you cannot deliver it, period.

Explore if you have unit testing frameworks available for your language, or try to write small tests on your own. Ensure that you do some test-writing before you declare your readiness for the rest of the world.

ANT, Maven, Hudson, Make and such like also help. What is even better that their working does not change much from language to language. It becomes, after a while, extremely important to know these well.

All set? Develop. Around mid-way on such a project, you will cross the threshold of knowing enough about the language. Finishing the project will just add value to your learning.

In the next post, I'll share the newer, funner approach.

There may be more ways of doing this. There may be areas that I have missed, so do enlighten me. :)

Till the next 'un then!

Shaurya

Mouse-overs and hovers are out

At least they are on their way out.
Think about it, Tom Cruise, Minority Report. Given that kind of interface, how would you do a mouse over? How would you work out a hover?

You can't.

Now comeback to reality.
Think iPad, Think iPhone, Android, Storm, Touch etc. Think more about all the haptic interfaces. Think of all the tactile gestures. Hovers? Nah!

Press and hold might work for now, but really, who are we fooling here. Hovers are on their way out. On their way to not being such a preferred information dissemination medium anyway. Maybe they'd still work on the desktop, but, how many desktops are around these days? How many days before a desktop changes to something new as well?

You'll have to re-invent yourself, if you want to be ready for what comes next.

A very senior colleague (who is also a client), was discussing products and design, when his words gave me this insight. You can fart about stuff, you can resist a shift. But, either you are out of the game or in for a change.

S.

Flex 4 is here!

Sigh!
...and just like that...FLEX 4 is here!
:)

1. http://blogs.adobe.com/flex/archives/2010/03/flex_4_sdk_and_flash_builder_4.html

2. http://www.adobe.com/products/flex/

Check it out!

Go! Play!

:)

Shaurya.