TOKI WOKI. 

Some projects become real, oth­ers never see the light of day. This one is more of an abortion.

Six month ago I’ve been con­tacted by an archi­tec­tural firm to pro­vide some con­sult­ing on a project of theirs (I’m not going to name names, you’ll under­stand why). The goal was to find ideas to make a building’s front more inter­est­ing. The build­ing being a place to help and pro­mote Hip-Hop culture.

So I started work­ing on it and came up with ideas and con­cepts. The archi­tect I was in con­tact with seemed pretty happy with it and every­thing was look­ing good.

Until I no longer received any answer to my e-mails… Our last inter­ac­tion is now 5 month old and I think time has come to mourn. What I came up with can be inter­est­ing and since it involves an Open­Source project, here are a few bits about it.

At that time I was dis­cov­er­ing  GML (Graf­fiti Markup Lan­guage) and Evan Roth’s work. Bor­deaux hosted Les Grandes Tra­ver­sées and all of this really inspired me. So I thought of a mash-up between GML’s #000000book (black book, open archive of GML tags), a player of my own (Okr), the build­ing itself and Twit­ter. Here’s the doc­u­ment I pre­sented to explain what I had in mind.

The steps are:

1. Cre­at­ing and send­ing a graffiti;
2. Receiv­ing data;
3. Con­vert­ing it to an image;
4. Pro­ject­ing it on the building’s front;
5. Photo-shooting of the front;
6. Send­ing to Twitter;
7. Online con­sul­ta­tion.

After a few e-mails with Jamie Wilkin­son (heads up!) I started work­ing on the core classes writ­ing GMLPlayer and GML­Cre­ator. The goal was to pro­vide both a way to dis­play tags and to create/upload them. I then built a UI around all that (a Flex one, after notic­ing Min­i­mal Comps didn’t work the way I expected).

iframe: <a href="http://toki-woki.net/p/Okr/">http://toki-woki.net/p/Okr/</a>

Note: you’ll also find the app on its ded­i­cated page. Try search­ing for “dasp” or “hello world” for exam­ple and play with the set­tings (the 3 top sliders).

Unfor­tu­nately it is only after cre­at­ing all this that I real­ized the project would never become real… So I sim­ply stopped work­ing on it. I am well aware that some parts of the code is a bit raw and could be opti­mized and I haven’t built the creation/upload fea­ture into the UI yet. Don’t know if I will, but the project is Open­Source so feel free to give it a spin! I also share my ini­tial attempt and a pixel ver­sion in case you’re interested.

Pretty happy that — even if not fea­ture com­plete — Okr made it to the GML project gallery, yay!

And just because a project will never see the light of day doesn’t mean it doesn’t need a proper logo, right?

I just wasted a few hours on under­stand­ing how to update an AIR app from the 2.0 name­space (or ear­lier) to the brand new 2.5 one. As you may know, two new tags have been intro­duced (“ver­sion­Num­ber” and “ver­sion­La­bel”) to replace the old “ver­sion” one.

To avoid break­ing things you have to cre­ate an inter­me­di­ary app ver­sion that will smoothly switch from 2.0 to 2.5, here’s what you can read on the release notes page:

In order to be able to update from ver­sion 1 to ver­sion 2, an inter­me­di­ary update step must be added as fol­lows: appli­ca­tion ver­sion 1, pack­aged with AIR 2 and using the 2.0 name­space gets updated to: appli­ca­tion ver­sion 1.5, pack­aged with AIR 2.5 and using the 2.0 name­space. This ver­sion of the appli­ca­tion must include the ver­sion of the Appli­ca­tion Updater SWC/SWF included with the AIR 2.5 SDK. This gets updated to: appli­ca­tion ver­sion 2.0, pack­aged with AIR 2.5 and using the 2.5 namespace.

Where “appli­ca­tion 1.5″ is the intermediary step.

All of this looks quite sim­ple but really it isn’t; or at least it wasn’t for me. To be really explicit here are my 3 appli­ca­tion descrip­tors and the update descrip­tor (ver­sion num­bers changed to match Adobe’s example).

Appli­ca­tion descrip­tor – Ver­sion 1 (pack­aged with AIR 2.0):

<?xml version="1.0" encoding="utf-8" standalone="no" ?>
<application xmlns="http://ns.adobe.com/air/application/2.0">
	(...)<version>1</version>(...)
</application>

Appli­ca­tion descrip­tor – Ver­sion 1.5 (pack­aged with AIR 2.5):

<?xml version="1.0" encoding="utf-8" standalone="no" ?>
<application xmlns="http://ns.adobe.com/air/application/2.0">
	(...)<version>1.5</version>(...)
</application>

Appli­ca­tion descrip­tor – Ver­sion 2 (pack­aged with AIR 2.5):

<?xml version="1.0" encoding="utf-8" standalone="no" ?>
<update xmlns="http://ns.adobe.com/air/framework/update/description/2.5">
	(...)<versionNumber>2</versionNumber>(...)
</update>

Update descrip­tor (PHP script receiv­ing the caller’s cur­rent ver­sion as “cur­rentVer­sion” GET variable):

<?php
header("Content-Type: text/xml; charset=utf-8");
echo '<?xml version="1.0" encoding="utf-8"?>';
$currentVersion=array_key_exists('currentVersion', $_GET) ? (float)$_GET['currentVersion'] : 1;
$isNewNamespace=$currentVersion>=2;
$ns='http://ns.adobe.com/air/framework/update/description/'.($isNewNamespace ? '2.5' : '1.0');
$version=$currentVersion>=1.5 ? 2 : 1.5;
$versionTag=$isNewNamespace ? 'versionNumber' : 'version';
?>
<update xmlns="<?php echo $ns ?>">
	<<?php echo $versionTag ?>><?php echo $version ?></<?php echo $versionTag ?>>
	<url>http://www.your-site.com/update/your-app-<?php echo $version ?>.air</url>
</update>

Not that sim­ple, right? And this is not only annoy­ing to the devel­oper, but also to the end user. He will be noti­fied of an update from ver­sion 1 to 1.5 and when he’s done he’ll get prompted about the new-new ver­sion (2): bang, another update process.

If you’re curi­ous of how I send the app’s ver­sion to the update descrip­tor, here it is:

_appUpdater.updateURL='http://www.your-site.com/update/version.php?currentVersion='+App.getVersion();

The App class is avail­able in my as3bits repository.

Some help­ful links on the subject:

• Update AIR 2 or ear­lier to AIR 2.5 Appli­ca­tion Updater framework
• Updat­ing AIR applications
• Release notes for Adobe AIR devel­op­ers 2.5

I hope this helps!

iframe: <a href="http://toki-woki.net/p/golden-ratio/">http://toki-woki.net/p/golden-ratio/</a>

I wrote a quick and sim­ple golden ratio tool (ded­i­cated page). Basi­cally it helps you find “golden ratio neigh­bors” for a given num­ber: every num­ber in the list divided/multiplied by its neighbor = φ.

Pretty straight­for­ward but could come in handy. I’m aware it could be improved; if you have suggestions…

When I moved in I bought an IKEA Ramvik table and while trav­el­ling this sum­mer I had an idea (don’t ask why): dec­o­rate its top with Lego bricks used as pix­els. Here are the steps I went through. If you don’t care about those steps and want to see a nice time-lapse video, scroll to the end of the article!

Lego bricks

First things first. What are the Lego brick sizes and col­ors avail­able? Oddly enough this ques­tion is not that eas­ily answered. Prob­a­bly because Lego’s site is crappy, or because nobody really cares… I even­tu­ally found Brick­ipedia which hap­pens to be a much richer resource than the offi­cial ones. Every­thing I was look­ing for was there: the Lego “unit” is 8 mil­lime­ters and the color palette is pretty sim­ple.

Table specs

Know­ing my table size I had var­i­ous options, depend­ing on the “pixel size” I’d choose. Of course the num­ber of bricks (and the price) would also vary. So I cre­ated a dynamic spread­sheet on Google Docs that’d do the cal­cu­la­tions for me… Here it is, with all the options pos­si­ble (French, sorry).

iframe: <a href="https://spreadsheets.google.com/pub?key=0AmyvU-n2aOBpdG5oNUN6UW0xcUJ4a2E3eXFrTTJIVnc&amp;hl=en&amp;output=html&amp;widget=true">https://spreadsheets.google.com/pub?key=0AmyvU-n2aOBpdG5oNUN6UW0xcUJ4a2E3eXFrTTJIVnc<span class="amp">&amp;</span>hl=en<span class="amp">&amp;</span>output=html<span class="amp">&amp;</span>widget=true</a>

I chose the 4x4 option, quite cheap and still offer­ing a cool num­ber of pixels.

Design

36x16 pix­els of free­dom, that’s it. I tried lots of dif­fer­ent designs, from lo-fi pho­tos to pixel-art draw­ings. I decided to go for a Heavy Oblique Futura.

Actual size:

Look­ing good.

The Lego palette

I set my type to white, on a black back­ground. The anti-aliasing process cre­ates gray-scale pix­els to smooth the curves, which is great, but Lego bricks aren’t avail­able in all col­ors! To have a real­is­tic pre­view of what it would look like I had to cre­ate a Pho­to­shop Color Table match­ing Lego’s gray-scales (if you’re inter­ested, just ping me [UPDATE: here they are]). Here’s a com­par­i­son between Photoshop’s default gray-scales (left) and Lego’s palette (right):

You may notice that Lego’s black is a lit­tle bit light and the grays are yellowish.

Time to order bricks!

Already? Nope, not that fast. Before order­ing I had to know exactly what to order, that means count­ing the pix­els. Well, I’m not this kind of guy. I’m a devel­oper; I hate repet­i­tive chores, you know.

So I fired up Flash Builder and came up with Palet­te­Counter a sim­ple, Open­Source, app to count pix­els of each color. I also added some kind of “assem­bly instruc­tions gen­er­a­tor” to help us build it. Handy.

Time to order!

Really? Yup. I placed an order on lego.com’s Pick A Brick and received it a cou­ple of weeks later. Yay!

Let’s do this

I’m not going to describe the process (that hap­pened this sat­ur­day), just have a look at this time-lapse vid. 1020 pics shot in about an hour, yummy. Thanks to Céline and Julie for help­ing out!