JSON

The first format is JSON, Javascript Object Notation. JSON is a simple language neutral (despite its name) readable format that is very small to implement. It is a restricted variant of the native JavaScript literal syntax for objects (dictionaries) and arrays. Basically it excels in simplicity but lacks a bit in features, but people tend to ignore those shortcomings due to its widespread adoption. I will not go into describing it, json.org does a very good job and there are TONS of JSON implementations around.

STON

Sven Van Caekenberghe recently created a variation on JSON he calls STON, Smalltalk Object Notation. STON is basically JSON plus the following:

• Object references, the concept of being able to refer to other previously described arrays/objects in the STON file. This is done by number using the @-sign like “@2″ refers to the second array/object in the file.
• Class prefixing, the idea of annotating arrays and objects (JSON terminology) so that one can instantiate a reasonable class when reading.
• Symbols, simply adding support for a primitive data type for Smalltalk symbols, although I do note – a limited form of Symbols not allowing the same range of characters in them as Squeak/Pharo does.

Then there are a few subtle differences from JSON, like using $’ instead of $” as string delimiter and nil instead of null, but not much else that I can see. Numbers seem to be exactly the same as in JSON, and escape codes inside strings are also the same, obviously by design.

First I admit that I have not played with STON, my comparison is purely in theory. STON has the same basic positive notes that JSON has, it is small, simple and well defined. But are the differences worth it?

JSON is everywhere and there are already tons of parsers for it, probably in every Smalltalk on earth, and of course all other languages too. STON on the other hand is Smalltalk only, and as of this writing probably Pharo only, although I admit it must be simple to port.

It boils down to if the additions are worth it and I don’t think they are. Embedding class names, if needed, could be done in JSON, although slightly inelegantly of course, but one approach would be to wrap each “typed” object/array in an object like this:

ByteArray [1, 2, 3] ==> {"type": "ByteArray", "data": [1, 2, 3]}

I agree, clunky, but on the other hand I tend to think that the parsing end needs to know the semantics and construction of the JSON anyway – JSON is too “simplistic” to be used as a true generic serialization mechanism and trying to turn it into such a beast by adding types and references, like STON does, is IMHO not that useful.

STON looks neat, but in practice I don’t think the benefits outweigh the ubiquity and availability of JSON. Had it been even more different it might have been another story. But if we don’t think we will use type annotations and circular references – then why not simply use JSON?

Literal Smalltalk arrays

The simplest notation of all in the lineup is the literal array syntax in Smalltalk. The example below covers all its capabilities AFAIK (in Pharo/Squeak), please tell me if I missed anything:

#(4711 3.4 16r3F 'string' #symbol #'another-symbol' (nested array) #(one more) true false nil $x #[12 32])

So we have space separated elements and arrays that can nest, with or without #-prefix inside the array. Primitive literals are numbers (full numeric Smalltalk parser, not as limited as JSON/STON), strings (no escape codes, single quotes needs to be doubled), symbols (can handle more characters than STON symbols), character literals, byte array literals and true/false/nil.

Literal arrays are quite nice but they lack the concept of “associations” and thus no simple readable way to represent a Dictionary. And that is a BIG negative. Funny enough, if we added support for literal dictionaries to Smalltalk then literal arrays would match JSON, with a few extras on the side!

Amber has recently added support for dynamic literal HashedCollections using this syntax:

#{'hey'->12 . aString->'123123'}

It is simply a dynamic {} array (was introduced originally in Squeak I believe) but with the assumption that the expressions all evaluate to Associations that are limited to a string as key. This is because it will be turned into a HashedCollection which is the Amber counter part of a JavaScript object, and JavaScript objects are limited to having strings as keys (Sidenote: Amber also has a generic Dictionary without that limitation).

Without a syntax for dictionaries, literal arrays, although nifty and syntactically quite compact, are still limited in expression. And of course, while Smalltalk literals are fairly simple to parse, other languages do not typically know how to do it – and when it comes to numbers, the Smalltalk full range of syntax is perhaps a bit of an overkill if we aim at cross language portability. Having literal syntax for Characters is also clearly of less value, ByteArrays on the other hand are obviously useful.

Sidestory: Adding literal Dictionaries to Smalltalk?

Smalltalk only evolves in micro steps every other 10 years, but with the current onslaught of Pharo perhaps there is an opportunity to actually take a few more such steps.

We will see below that Tirade has added support for “->” as a literal syntax instead of being a message send and as I mentioned above Amber has added a special syntax for dynamic Dictionaries, and that was actually done in order to more easily match JavaScript object syntax when interacting with JavaScript.

So perhaps the Smalltalk/Pharo community could decide to add literal Dictionaries to Smalltalk using the Amber “#{” syntax? In such a syntax the separators between Associations can probably not be spaces, it gets confusing to read:

#{ key -> value key2 -> value2 }

A separator is clearly needed and since we use periods generally for that in Smalltalk it’s a good choice. Syntactically it could lead people to think it’s a dynamic Dictionary, but let’s continue the thought experiment. How would it look? As is customary for #() we can ommit the # inside the array:

#(123 'hey' {key -> value. key2 -> value} 456)

It looks fairly nice. However I do admit that we probably should take a long hard look at all our syntaxes and try to bring some harmony to them. Currently, due to legacy, we have literal and dynamic Arrays using #() and {}. A bit unfortunate since we then use both $( and ${ as delimiters for Arrays and make it harder to find good characters for Dictionaries.

It would be nice to have a symmetric syntax. Ideally the leading # could indicate “literalness” – and perhaps we could use another character to indicate dynamic evaluation? Again, just a thought:

• #() – literal Array
• §() – dynamic Array, expressions separated by periods.
• #{} – literal Dictionary, literals separated by periods, support for associations as literals.
• §{} – dynamic Dictionary, expressions separated by periods, associations created as usual using sends.

Yeah, right, how would we ever be able to reach concensus on a leading dynamic character? Also, I do think it is wise to syntactically indicate literal vs dynamic, heuristics only lead to developer traps. Better to clearly indicate intention.

Tirade

Tirade is a format I created for Deltas (ChangeSets improved) and I have written three articles about it earlier. Now, if I would at this point subjectively rank the formats along a few axis it could look like this:

• Interoperability
• JSON: 100% (all languages has it)
• STON: 70% (one could probably tweak a JSON parser in any language to work)
• Litarrays: 30% (could get higher score if we limit them, a parser would still have to be written)
• Tirade: 20% (same problem as with literal arrays, but even more advanced to parse)
• Capability
• Tirade: 100% (has the most features and options, by some margin)
• STON: 60% (second best, still not much better than JSON)
• JSON: 50%
• Litarrays: 40% (severely limited by lack of assocations but has a some features to compensate)
• Grokkability
• JSON: 100% (well documented, we all know it and so does the rest of the world)
• STON: 90% (rides on JSON)
• Litarrays: 80% (not hard but has quite a few quirks)
• Tirade: 70% (more or less as hard as literal arrays, but with a few more concepts added)

Conclusions from the above? Before looking at Tirade I think we can safely say that JSON is a strong choice. STON is IMHO in limbo, I can’t see picking it instead of any of the others in a given situation, sorry. Literal arrays could easily become the obvious “JSON for Smalltalk” if it had associations/literal dictioneris, it sucks for interoperability though.

Tirade on the other hand has associations (on two levels one could even claim) so it can be viewed as “JSON++ for Smalltalk”. But with more features comes a slightly higher learning curve and a penalty in interoperability. We now have set the scene for the last section about Tirade.

Tirade

Obviously I am partial, since I created Tirade. But let me try to contrast Tirade to all the others. Note that Tirade was never meant to be interoperable with other languages, it was however designed to be interoperable between different Smalltalk implementations, or at least all Squeak derivatives.

A stream of messages

First of all, Tirade is slightly different than the others. They describe a single structure. A valid Tirade “document” on the other hand, is a series of “records” terminated by periods. Each such “record” looks like a Smalltalk message (but without a receiver on the left side), either a unary or a keyword message, like this:

unaryMessage.
key: 'Hello' word: 'world' message: 4711.

This high level view as a “stream of messages” gives us several nice properties:

• The selector of the Tirade message is a kind of record “type”. It normally maps to a method on the receiving end that handles this record. That method then knows what to do with the arguments, and thus we don’t need to hard code class names into Tirade, like STON does. NOTE: This is not a security problem. There is nothing forcing the parsing end to just blindly perform these messages. In fact, there is nothing forcing the parsing end to be specific at all, it could just be a generic Tirade parser.
• If we look at a keyword message we realize that it is very similar to a JSON object, it is basically a “naked dictionary” where each key word is… right, a key! So for simple data we need perhaps not make it more complicated than this.
• It makes it very easy to extend a Tirade format by simply adding new message selectors that the receiving end can ignore if it wants to.
• Since Tirade is a flow of messages instead of a single, potentially quite large, structure like the other three formats, we can naturally stream it and handle each message one by one.
• And since we have this flow we can also use “control messages” that can instruct the receiving end on how to receive the messages coming next in the flow. One could even use Tirade over a bidirectional link (a SocketStream for example) and do handshaking and client server communication with it.
• Finally, in between Tirade messages one can add Smalltalk style comments which are simply skipped by the parser. JSON and STON has no concept of comments.

Smalltalk literals

The next level of Tirade is what kind of arguments we are allowed to put in between the keywords. Basically its most kinds of Smalltalk literals with some additional constructs. I would also like to point out that this part is not encarved in stone, I am still contemplating the best mix of literal support here. But the main point is that we only allow literals – no expressions, so there is no generic “eval” going on here.

Notable differences again compared to JSON/STON on the atomic level are just like with literal arrays:

• Strings are Smalltalk strings, no escape codes except for double single quote for single quote.
• Numbers are Smalltalk literal numbers, in fact we rely on the number parser of Pharo/Squeak. This gives us a rich notation for numbers, at the expense of possible portability issues with other Smalltalks.

NOTE: Tirade doesn’t currently implement Character literals nor ByteArrays, both can of course be added.

Let’s continue with the added features for literals.

Literal feature: Verbatim strings

A problem with JSON for dealing with readability is that JSON strings can’t have newlines in them! So if you want to store source code in JSON it will end up as a single very long line.

Smalltalk strings like in Tirade can have newlines in them, but they suffer from double quoting of single quotes and the problem that the single quotes surrounding the string needs to be first on the first line and last on the last line, which makes it less readable.

This is why I came up with verbatim strings in Tirade, specifically for being able to contain unmodified source code in a readable way with no escapes whatsoever. I am not sure if this is the best approach, perhaps here-docs would be a simpler approach, but currently a verbatim string looks like this:

some: 1 message: 'hey' withVerbatimStringForCode: [
 This is untouched, perfectly unescaped source code, ANY character combinations will work!
 Tirade will split the input on each CR (byte = 13) and then prepend each line with a TAB character.
 This means that the parser can detect the end by looking for the first line starting with "]",
 that must be the end of the verbatim string since all other lines start with TAB.
 Copy paste will work but you will need to care for the TAB indentation, but most editors
 can do that easily. Also, right before and after the string there is a newline added to improve readability.
].

Literal feature: Associations

Since we really want to be able to do dictionaries I first added literal support for Associations. This means “->” is a literal syntax for creating an Association, it doesn’t need to be in a Dictionary, you can use them wherever you like and the key and value can be ANY literal construct allowed by Tirade, even an Assocation!

Note though that we do not have parenthesis in Tirade (no expressions at all) and the current Tirade parser is a recursive descent bottom up parser so the code below will produce an Assocation with key #key and value an Association 123->’123′. In Smalltalk where #-> is a message this is instead executed from left to right creating a different result.

cool: #key->123->'123'.

This also means that Tirade can have associations inside literal arrays, which is not syntactically possible in Squeak/Pharo:

cool: #(12->'123').

Finally, since Amber lately added #{} syntax for Dictionaries I think it could be a worthwhile addition to Tirade also.

Literal feature: Dynamic arrays as literal

Tirade supports {} style arrays, but doesn’t allow expressions so they are very much like normal arrays except they do not remove #-prefixes from nested arrays/symbols and they look more natural to Squeakers since Squeak allows Association literals inside them:

cool: {12->'123. 'banana'->true}.

Is it worth supporting both kinds of arrays? It depends, either Tirade defines a literal subset that is as small as possible, or Tirade tries to cover all literals of Pharo. I was leaning towards a subset but perhaps a super set is more attractive to people.

Ending thoughts

I hope this article explained a few things and made at least Tirade a bit clearer. There are several things not fully settled in Tirade and if anyone wants to dig in and tweak it, feel free to email me.

regards, Göran

Needless to say though it is a real ton of bricks (8.8 lbs = 4 kg) and including the truly fat power supply it simply weared my back down during 2011. I have been carrying this beast in a backpack every day – and my body eventually said “enough dammit!”.

Ultrabook?

So I decided to upgrade to some hot new hardware weighing below 2 kg and naturally I started looking at the current crop of ultrabooks. And no, Macbook Air is not for me, sorry. After reading lots of reviews my perception is that all of the current Ultrabooks have one problem or another. This may be because of this being the first generation of Ultrabooks in combination with manufacturers pushing the envelope technologically:

• Keyboards tend to be troublesome given the limitations on thickness making the keys too shallow, the Zenbook for example suffers from bad reviews pointing out the fact that you really need to hit the keys in the middle for them to register.
• Touchpads are also an area lacking, probably because most of them are now moving to so called “clickpads” with integrated buttons.
• Screens tend to be less than stellar.
• There have also been reports on issues with wifi having bad reception.
• Then of course, a general lack of ports, but that is to be expected in this form factor.

I was still leaning towards the Lenovo u300s. It seems to be a truly awesome machine with no apparent weakness although they say the screen is not something to write home about. But I simply can not find where to buy one! Reading up on this Lenovo I came across a lot of people proposing the X220 as a better choice. Eventually I started to read up more on the rest of the Lenovo line, especially the X220 and X1.

Lenovo X220!

After some serious soul searching I decided that I really need an X220 instead of a shiny ultrabook toy, and today when I was home sick I ordered one from Dustin with home delivery – 2 hours after placing the order a car drove up to the house and delivered it – sweet!

So what about the newer X1 then? Well, what did it for me was the weight and size difference combined with the fact that I really wanted the IPS display. I have read some more comparisons afterwards and feel I made the right decision, although the keyboard on the X1 does get rave reviews even compared to X220. This means it must be insanely great since the keyboard is one of the true highlights of the X220.

After just a few hours with the X220 I am certain I made the right choice. This machine is… well, if Ultrabooks are flashy slim Ferraris and Porsches this machine would be… a mini Humvee. It is function focus all the way. Here is a list of key arguments for the X220:

• Superb real keyboard which is a true joy to type on. This is important and a key differentiator for Lenovo in general. It also has the Trackpoint (the little red mouse stick thing), quite nice if you learn to use it – which I am trying right now.
• Full voltage CPUs with top of the line being a Core i7-2640 giving even more power than the low voltage variations found in Ultrabooks.
• 8 Gb RAM (two replaceable slots). Many ultrabooks only give you 4 Gb max and non replaceable. For a small additional price I got an extra 4Gb memory module that was trivial to install. In fact, there are people who have managed to install two 8Gb modules giving a maximum of 16Gb!
• 1366 x 768 matte IPS panel, same technology as in the Ipad they say. Awesome display and a rarity among laptops. And matte damnit! This is alone a very strong argument for the X220. I mean, this screen rocks! Of course, higher resolution would have been nice but it’s fine.
• Tons of ports and ways to extend and replace parts (battery, memory, hard drive etc)
• 1.3-1.6 kg depending on choice of battery, clearly in Ultrabook class.
• Insane battery life with several battery options! The protruding 9-cell battery I got is meant to give up to 15 hours! There are 4 different battery sizes, just pick and choose. I am going to get an additional 4 or 6-cell variant which doesn’t protrude, when I want to be “slick”

I guess it boils down a bit to what kind of person you are. I wanted a really good and lightweight laptop that I can work on, but I also wanted something different, as the title of this blog says – I travel the road less taken. And X220 is a true utilitarian beast sending a “100% no nonsense” message.

Performance

Getting acquainted with the machine I decided to run some benchmarks in Windows 7. I downloaded the CrystalDiskMark and while not as good numbers as the best drive in UX31E it still got decent numbers:

           Sequential Read :   259.164 MB/s
          Sequential Write :   170.058 MB/s
         Random Read 512KB :   172.326 MB/s
        Random Write 512KB :   169.432 MB/s
    Random Read 4KB (QD=1) :    17.175 MB/s [  4193.1 IOPS]
   Random Write 4KB (QD=1) :    31.436 MB/s [  7674.9 IOPS]
   Random Read 4KB (QD=32) :   140.489 MB/s [ 34299.1 IOPS]
  Random Write 4KB (QD=32) :    95.920 MB/s [ 23418.1 IOPS]

But this is of course an attribute of the Intel SSD drive more than the actual notebook. I also downloaded and ran the free PCMark 7 in which it scored 4004. This is better than the fastest Ultrabook (UX31E which got 3653) but I had hoped for even better, perhaps I missed cranking up the speed correctly.

To top things off, here is a list of more funky details:

• A small downward directed LED lamp (Thinklight) right beside the web cam that illuminates the keyboard. Hehe, kinda low tech compared to backlit keyboards, but it works. I guess it is hard to make a traditional “non chiclet” keyboard backlit.
• A 720p HD web cam. Oh.
• A fingerprint biometric reader! So now I log on W7 by swiping my index finger, funky.
• 54 mm Express Card slot. No idea what to use it for yet!
• One combined mSATA/PCIe internal slot. In my machine it holds a UMTS 3G card. I just slid in my SIM card and it hooked up nicely!
• The second half PCIe port. No idea what to use that for either.
• Option to buy an additional mSATA SSD drive (currently available up to about 128Gb) giving even more disk space. Unfortunately this would mean ripping out the UMTS card.
• The navpoint (red mouse stick) has three buttons below and if you hold the middle button you get scrolling for the navpoint – really nice! Or perhaps obvious, but I like it.

Negative stuff so far

Well, these are nitpickings, but still, these are things that have annoyed me a bit:

• Although I really like the little red nubbin, it does get in the way when I type “b” sometimes, my right hand index finger “stumbles” over it. Might be simply an issue of getting used to the keyboard.
• The palm rests are very small on this machine due to its size. For my right hand it is not an issue because the red nubbin and touchpad is slightly off to the left so I tend to rest my right palm slightly more to the middle. But my left wrist ends up squarely on the left side corner of the laptop. And while the front edge is sloped downwards to make it comfortable, the sides are not sloped at all.
• The Ctrl and Fn keys seems swapped for my taste, the Ctrl should IMHO be in the corner. In the BIOS one can swap these (!) but then I would really like to change the writing on the keys too…

Software included

Normally I don’t care about installed software but Lenovo has actually included quite a few useful utilities for Windows 7. Power management, biometric finger print management, yaddayadda. This makes it harder to make the decision to wipe Windows.

Here comes…. Ubuntu!

First I tested running Ubuntu in a VirtualBox and while it works quite well it still seems to behave better on the real hardware. This is probably due to the graphics capabilities in VirtualBox. Anyway, one of the main reasons for going with a Thinkpad is also of course the fact that they tend to work really, really well with Linux. And the X220 is not an exception. I have been running Linux as primary OS for almost 6 years now so I really want to continue doing that, but I am being cautious and will go for a dual boot setup for now.

These are the basic steps I performed:

• Produce the so called “Factory Recovery” disks. This takes the recovery partition that Lenovo has put on the SSD and slaps it onto external media so that you can wipe that partition and reclaim about 16Gb of disk space. It’s also nice to have, if something goes bonkers.
• Shrink the Windows 7 partition thus leaving unpartitioned space for Ubuntu.
• Prepare a USB stick with Ubuntu.
• Install Ubuntu from the USB stick producing a dual boot setup.

Funny enough it was the first step that turned out a bit tricky, the rest was a piece of cake.

Producing Factory Recovery media

One would think that since everyone should do this it would be trivial to do. If I would design this procedure I would make it possible to produce iso-files that can just be saved onto an USB hard drive, but no no…

• Prepare a USB drive according to this document. It must be either at least 350Mb (only for booting) or about 9Gb (both bootable and recovery data).
• If you picked a small USB like I did, when you run the utility from Lenovo – only select “boot” when you get the dialog with two check boxes. It will then wipe the drive and make it bootable, but not put recovery data onto it. Then you can fire up the utility once more and use an USB hard drive for the other checkbox (recovery data), it does not need to be empty because it will not wipe it, it will just create a directory called “factoryrecovery” and put all data into it.
• If you picked a large USB stick (or hard drive) then you can select both checkboxes and get it all in one place in one go.

NOTE: You should try booting from it to see that it actually boots. To do that you will need to enter the BIOS setup (F1 or F12 on boot) and move the USB flash drive higher up in the boot order list. Of course, when this is all done one could produce an iso from that bootable USB stick and store it away somewhere to free up a perfectly good USB stick

Then finally you can let the tool “reclaim” the partition, it will nuke the paritition and then enlarge the Windows 7 partition with that space, but we will shrink it in the next step.

Shrink Windows

This is easy in 2012, Windows can do it for you. Just open control panel, type in “partition” and open the tool that it finds. Select the Windows 7 partition and use “shrink” in the popup menu. Then you get to a dialog in which you can specify how much you want to shrink it.

Prepare a USB with Ubuntu

There are many ways to install Linux and in the older days the traditional way was to burn a CD and boot from it into the installation procedure. These days I guess the most common procedure is to do the same, but with a USB stick. In retrospect the Wubi installer might have been even easier, but I wanted to install the beta 2 of Ubuntu “Precise Pangolin” and didn’t think Wubi was up to date with that, but it seems you can download any iso you want on the side for it.

Anyway, I downloaded Unetbootin and the Pangolin beta 2 iso and then “burned” it with Unetbootin to a USB stick. Done.

Install Ubuntu

Well, what can I say? Just boot from the stick and go with the flow. The installer is trivially easy, it will detect the existing Windows 7 and even offers to import bookmarks and stuff from your Windows user! A dual boot setup is produced without questions asked even, it was simple as that.

Conclusion

I love this machine! And the only thing not working perfectly smooth in Ubuntu is the 3G, it fails to unlock when I give the PIN code, not sure why. Also, one will need to do some tweaking to get less battery drain in Linux, but I think the forums indicate that it is possible to get similar results as in Windows.

So take my advice – if you are looking at the Ultrabooks, do take a long look at the X220 before making your decision.

Amber

The new Smalltalk called Amber (by Nicolas Petton) that compiles to javascript is pretty awesome and there are tons of interesting things one can do with it. My contributions so far include the beginning of a package model, a faster simpler chunk format exporter/importer, a command line compiler, a Makefile system so that Amber can be built fully from the command line and a bunch of examples running on top of Nodejs and webOS, and a few other odds and ends.

I would like to port Deltas to Amber in order to create a powerful toolset for managing code changes. Using local storage it would among other things enable undo and change logging to prevent accidental code loss. It could also easily form the basis for a “commit tool”, similar functionality that git stash offers etc.

Another thing I would like to build is a dead simple public shared package repository. And play with Socket.IO, or just fool around with the compiler trying to add optimizations like various type inferencing, optimizing self and super sends etc . So much fun stuff to do!

STOMP and Apollo

For a personal “secret project X” I need scalability so it is being designed with lots of daemons each taking care of a specific task. I want to be able to implement these daemons primarily in either Nodejs (in plain js or using Amber) or Pharo Smalltalk, but also in any other language that fits.

This requires some kind of messaging infrastructure to tie them together. So… after looking hard and long and reading a lot about messaging, job scheduling, AMQP, 0MQ, STOMP, Beanstalkd, RabbitMQ, ActiveMQ Apollo (and tons of other things) I decided to try to use the new ActiveMQ Apollo together with STOMP 1.1 (which should also be supported by the STOMP plugin for RabbitMQ etc).

The new Apollo implementation is written in Scala using HawtDispatch so the architecture seems modern and the JVM of course has very good performance these days. So, while I generally am very tired of Java and its eco system, this actually seems like a solid product and has already shown very impressive numbers in benchmarks.

So a sound asynchronous architecture with good performance is nice but the other thing I like with ActiveMQ is their focus on STOMP. Since I intend to use Pharo as one major component I need to be able to hook it into the messaging backbone. And sure, Tony Garnock Jones – one of the main developer behind RabbitMQ – actually has an AMQP client library written for Squeak 3.9, so I could probably us AMQP, but I somehow foresee a “world of hurt” in the complexity given that AMQP is a magnitude more complex than STOMP.

I have already implemented STOMP 1.0 for Pharo, actually tried it with RabbitMQ at the time, so I am now upgrading that library to work with 1.1 of the specification.

Riak

The other important piece of the puzzle for true “Internet scalability” is of course the choice of persistence. I am a long time fan of the new NoSQL databases and having played with a few of them, implemented a C# binding for CouchDB, hacked some bindings in Squeak for both CouchDB and Tokyo Tyrant… I now have decided to focus on Riak. Riak is IMHO the most interesting NoSQL database out there right now, at least for worry free ultra scaling. Sure, it may not be the fastest on a single box – but if you are really serious about scaling – one box is totally uninteresting.

Runar Jordahl had already started a Riak binding in Pharo, I took it and changed quite a lot of it – not really because it was “bad” or anything, I just have a different style of coding I guess. So I decided to fork because I didn’t feel comfortable – thus Phriak was born. Now Nicolas Petton is getting hard into Riak too and has pushed Phriak forward quite a LOT in the last few days, much further than I had time to do. It now has a clean command style protocol implementation, an object model similar to the one in Ripple (Ruby Riak client) and initial working code for both secondary indexing, link walking and map/reduce! Quite impressive stuff.

Nicolas is also experimenting with writing an “OODB-ish” database using Fuel called Oak and after I managed to get him hooked on Riak he has been moving that codebase over onto Phriak. The initial experience we have with Phriak and Oak is extremely promising and who knows where this will lead.

Happy coding, Göran

Nicolas managed to do quite a few “on the fly” demonstrations of various Jtalk snippets etc, and running the slides in Jtalk was of course a killer thing. I explained how jtalkc is being run on top of Node.js and quickly proceeded into showing the TrivialServer demo in Node.is – when Apache benchmark showed 1800 requests/second there was a spontaneous applause.

Now we can relax and talk to all people about Jtalk – and now in fact the web panel starts with Nicolas on the panel. Unfortunately the panel discussion didn’t play out that well, it needs some entertainment and also at least one or two that disagree

Later tonight and tomorrow we will probably keep on hacking Jtalk like mad. So much fun stuff to play with! We intend to “finish” the first stab at so called “speculative inviting” that we started earlier this week, and try to do some profiling on it to verify the gains. Using the Compiler is actually a good candidate for a reasonable benchmark.

The evening ended with the usual pubs and hacking and chatting about cool things people are doing.

This day starts with Stéphane presenting “Humane assessment”. Mmm, got distracted by my Touchpad, but Stéphane is showing some cool visualizations right now, clearly useful for large systems and organisations that need understand their own “huge legacy software”. Hehe, the browsers shows visual queues on “bad designs” like marking methods as “BrainMethod” or marking a class as “God Class” – that is indeed very slick!

All in all it looks like a very useful tool – I should probably try it out on some codebase. In fact, this tool is a really good “added value” tool that can be offered to customers when helping them. I have at least one client that really could make some good use of a tool like this.

Next up before coffee is Arden Thomas from Cincom (hehe, that was funny, the Touchpad wanted to correct “Cincom” to “Condom”…) presenting what is new in their products / ObjectStudio and VisualWorks. These are really mature and amazing Smalltalk tools, but of course they also costs money, money, money. But VisualWorks is accessible in a non commercial full version, which is quite nice if it fits your needs. Cincom is also quite active in a bunch of open source Smalltalk projects like for example GLORP (think “Hibernate” for all you non-Smalltalkers) and Seaside (the most outstanding web framework in the world).

After running around flaunting the Touchpad – I came slightly late to Igor Stasenko’s presentation on NativeBoost. I have worked with Igor and he has this refreshing “fearlessness” so diving into assembler is not a problem for him. So NativeBoost is an extension to the Squeak VM (and the new Cog VM) that enables dynamic machine code generation – and execution – directly from Smalltalk using just Smalltalk. So it includes a DSL for writing assembler (a port of AsmJit) and mechanisms to access memory etc etc. The machine code needs to be relocation agnostic since it is actually stored directly in a Smalltalk object (the method) and will be moving around due to the garbage collector moving things around. Another interesting issue is that if the machine code calls into the VM in order to create a Smalltalk object, it will need to be aware of the fact that this can trigger GCs and move things around – but this is just the same for building VM plugins. Of course, Igor’s stuff is very impressive and you can make very fast code using it.

The day then ended with the social event and announcing the winners of the awards and a nice dinner followed up with some beer and endless “Why doesn’t everyone use Smalltalk?” discussions – as is customary.

Over and out, Goran “typing this in on my Touchpad using the bluetooth keyboard”

The first hours were frustrating because I was in the ESUG conference and we only had a WiFi with a so called “captive portal” with a login form – and the first time you power up a Touchpad it wants to hook up to a Palm Profile, and does not want to do that using a WiFi with a captive portal.

The Montague pub to the rescue later that evening, an open wifi. I am currently writing this post using the Bluetooth keyboard (so nice) while the TP is snugly positioned on the Touchstone inductive charger. Both these are great accessories. I have also managed to do Skype with my wife, really easy and worked well, hook up the calendar to Google with perfect sync, and in fact it synched over all my contacts etc from my Palm Profile for my Palm Pre 2 – just works!

I have done the OTA 3.0.2 update (in the pub while eating) and I have installed a bunch of apps, like the one I am typing in know – for WordPress. I have also activated the included 50Gb free cloud space included from box.net – brilliant.

Email app is running fine, Facebook app is very good, tons of other little nifty things – I am a happy camper! Is it just as “smooth as silk” as the iPad? No, but it excels in other areas like true multitasking, a real Linux beneath (bonus for me as a developer), synergy, full flash, 50Gb cloudspace for life included, really good virtual keyboard (multiple sizes even) etc etc. Sure, slightly thicker and slightly heavier – but…. BUT…. It cost me around 85£ with 32Gb RAM. That argument is a killer.

Day after tomorrow I will be demonstrating apps written in Jtalk running on it – yiha!

I am not presenting anything but I hope I will get my HP Touchpad from Amazon before it starts so that I can demonstrate a WebOS app running on it written in Jtalk.

If you are going too, see you there!

What can I say, I am totally hooked! The SDK for WebOS 3.0 looks really nice and the Palm Pre 2 is the best phone I have ever used, if I disregard the poor battery life.

No, I have never owned an iPhone but my previous phone was the Samsung Galaxy, and that is a really good phone! Now, of course, getting the Pre 3 would be even better.

Screenshots

WebOS

Having used the phone for a week or two some things stand out:

• The gesture and cards system for multitasking is a real joy to use. Hard to describe, should be experienced.
• Notifications are really nicely done, non intrusive and slick.
• The “just type” mechanism is awesome, typing in a name or a website or whatever – and WebOS will suggest and list “everything”. And even better, WebOS discovers new “search engines” when I surf and offer to include them in quick list for searching! Simple and so smart.
• Synergy – the system merging all contact information together is amazingly good, much better than on my Android phone. It merges and syncs info from my LinkedIn, Facebook and Google accounts (and many other sources) brilliantly.
• Messaging is uniform, I can SMS or Gtalk or whatever in the same threaded view for a given contact. Yay!

And there is lots more of these little things, adding up to a very smooth user experience.

Application frameworks

One of the primary new things in WebOS 3.0 (vs 2.x) is Enyo – the new application framework in Javascript that is replacing Mojo, the older framework. Enyo looks like a really well designed object oriented UI toolkit. It focuses on using code and not HTML to produce the user interface and the API looks nice, well documented with examples and quite complete!

Applications for WebOS 3.0 come basically in three flavors – Enyo/Javascript, OpenGL/SDL/C/C++, or hybrid.

• An Enyo app is “just” Javascript running in V8 + Webkit and will be the framework that the majority of the applications will use. Given the push in Javascript land these days I would say it is a very interesting platform.
• More demanding graphical apps, especially games, can be written in the C/C++ tool chain and use the OpenGL ES and SDL APIs. This seems to be a very friendly platform for game development.
• Hybrid apps are Enyo apps (or Mojo) that can embed native components written in the C/C++ tool chain and allow them to render parts of the screen and also communicate with them. This is clearly an interesting option for many demanding apps.

An open eco system

Although WebOS is not open source it seems in many ways more “open” than the competition:

• It is trivial to get “root” on the devices. Just type in “upupdowndownleftrightleftrightbastart” and click the icon that appears!
• HP/Palm seems to realize that the homebrew community is very important and this community is exceptionally strong.
• Using the Preware homebrew app catalog and installing themes, patches, applications and more is just as easy and smooth as the regular app catalog (no, you can’t browse it on the web, only on a device)!
• The OS is a real Linux at the base! In fact, the ipk package format for apps is the deb format.
• The base technologies used are major open source projects like Webkit, V8, SDL, GStreamer etc etc.
• HP is offering a multitude of distribution channels including a “web distribution” channel where you can market your own app outside of the regular app catalog – but people can still just click on a URL and buy/install the application! That is very nice.

…and there are many more aspects to this “openness”, but I think HP realize that they need to play this part of the game quite a bit better than the competition in order to be able to catch up.

High hopes

I think HP has a diamond here in WebOS and if they play their cards right they should be able to find their piece of the market share. And that share just needs to be “descent” in order to be fruitful. But in order for that to happen I am hoping that:

• The products (Touchpad, Pre 3, Veer) really hit the stores all over the world ASAP.
• The 3G/4G versions of the Touchpad will show up soon. Just wifi is not enough.
• The next generation of products keep up with the competition in hardware specs.
• The major apps people want and need start appearing.

The first three are primarily up to HP. The fourth is hopefully not a problem since the eco system is so appealing to developers. And I think HP is trying to make sure some crucial apps are not missing – for example, I think HP made sure the Facebook app is there – and it is indeed a really good app!

Next up? Well of course, using Smalltalk to build Enyo applications…

Demontering

Dags att börja meka. Min ambition är att komma åt det mesta av drevets delar utan att gå så långt som att plocka isär det i alla sina beståndsdelar. Köpte Selocs manual – “Volvo Penta Stern Drives 1992-2002 Repair Manual” – från www.drev.se (finns en från Clymer också, vet ej vilken som är bäst) och följer instruktionen för att plocka av drevet.

Det första man noterar är att den lyftögla som man ska använda i oljestickans hål för att enkelt kunna hänga upp drevet inte går att köpa hos min Volvo Penta dealer. De berättar att de tillverkat egna sådana öglor! Ok, det ska alltså vara en lyftögla med tumgänga, 1/2″. Kollar med en rad järnaffärer och handlar till slut hos Stockholms expertbutik – Sifvert. Där plockar jag med lite hjälp ihop en lös ögla + en stoppskruv och landar på 150:-. På vägen hem trillar jag in på Jula och tror knappt mina ögon när de faktiskt har en enda sorts lyftögla – precis en sådan jag vill ha! För 29:-, ok.

Med öglan iskruvad och en provisorisk stång monterad över båtens akter kan jag skrida till verket med avmonteringen av drevet vilket visar sig vara en relativt enkel operation. Kåpan har jag ju tagit av tidigare, tre enkla muttrar så att man kommer åt växelmekanismen. (Grattis Finland, ni tog precis VM-guldet!) Momenten i översikt:

1. Plocka loss trimstängerna från drevet.
2. Plocka loss växelvajern från växelmekanismen.
3. Plocka loss de sex låsmuttrarna som håller drevet och dra ut drevet från skölden.

Vad gäller trimstängerna så varnade varvet för att låsringarna kan gå sönder när man knackar av/på dem, och de kostar 50:- styck! Mina höll dock, men jag var försiktig. Därefter fick jag tålmodigt knacka axeln rakt igenom drevet ut till andra sidan, använde ett armeringsjärn för att kunna knacka vidare när den försvann in i hålet. Seloc säger att man ska använda gummiklubba, men hade ingen sådan

Växelvajern var också lätt att plocka bort – tricket här är nog att dokumentera väl hur den var monterad. Jag räknade varven som låskuben var påskruvad på vajern, och tog lite foton! När man lossat vajern är det dags att lossa dess infästning på baksidan. När skruven är lös kan man dra ut låsblecket åt sidan så att vajern går att dra ut. På bilden ser man att blecket är utdraget cirka 1 cm och man ser också skåran i växelvajerns plasthölje som blecket var instucket i.

Dags att göra den stora manövern. Lossar de sex muttrarna och när jag försöker få loss den sjätte börjar tappen att snurra! Blir lite stressad eftersom jag inte förstår hur jag nu ska göra – men det visar sig att det bara är att skruva vidare, hela skruven kommer ut istället, puh! När alla sex är borta tar jag tag i drevet och rycker ut det sakta men säkert, ta emot drevaxeln bara så att den inte trillar ner och får sig en smäll. När drevet väl hänger kan jag känna efter hur tungt det är och visst, tungt är det men jag orkar lyfta det så inte så svårt att hantera ensam.

Värt att notera är de nästan helt bortrostade fästena för plastskydden på sidorna om drevet, samt saltavlagringarna väl synliga i huset. Där är det också en del korrosion faktiskt, ska se ifall man kan kromatera lite där. Det viktigaste – knuten – ser dock väldigt bra ut

För att senare kunna rengöra och måla delarna av drevet som sitter kvar på båten vill jag i alla fall få bort det yttre “huset” för att komma åt bättre. Läste om en annan kille i USA som plockat isär sitt drev och plastblästrat det – men jag orkar nog inte gå lika långt som han gick för att ta loss “gimbal ring” osv, det verkar krävas en del specialverktyg också.

Börjar med att lossa bälgarna, den övre är enkel att “trycka in”. Med hjälp av en stor skruvmejsel bänder man enkelt den över halskanten. Den under avgasbälgen är svårare – här behöver man verkligen en sk “inre ringtång” för att ta tag och få loss den inre metallringen som säkrar bälgen runt halsen. Åter ett inköp på Jula. Manualen tipsar om att vara försiktig för den kan sprätta iväg ordentligt ifall man tappar ringen.

Därefter ska vi skruva loss de två feta “bultarna” på sidorna, eh… ok. Seloc säger att jag ska använda en 1/2″ hex drive with a ratchet. Ehum, ok? Efter lite förvirring kring metriska insexnycklar (som tyvärr nästan passar) inser jag att det jag måste ha är alltså en halvtums insexhylsa, dvs insexnyckel för montering på hylsnyckeldragare. Problemet är att de flesta vanliga L-formade insexnyckelsatser i tum, inklusive den jag redan har, stannar precis på storleken innan, dvs 3/8″. Jula verkade inte ha något och inte heller en Claes Ohlson jag sprang förbi. Till slut hittar jag en lös insexhylsa hos TOOLS i Täby – tack, tack! Men mer om det i nästa artikel, nu går vi vidare med att försöka strippa drevet…

FedEx levererar

Som jag nämnde i förra artikeln beställde jag fyra spännande kemikalier från www.chemical-supermarket.com:

1. EFS 2500, färgstripper.
2. Metalprep 79, metallpreparationsvätska.
3. T5900 TCP, kromateringsvätska.
4. Stratocoat Green Epoxy primer, superprimer.

Allt levererades prydligt inslaget och nu har det blivit dags att se ifall strippern är så otrolig som den verkar! Jag börjar med att använda Henkels Degreaser som jag köpt på Seasea, enklast att hälla över i en vanlig sprayflaska, spraya och torka av med en gammal T-shirt som trasa (luddar ej).

Därefter tar jag och häller upp strippern i en liten mugg och penslar på med en vanlig pensel. Använder gummihandskar men denna vätska känns inte alls “farlig” att hantera, som tapetklister egentligen. Tyvärr är temperaturen relativt låg, kanske 17 grader som mest på dagen. Helst ska det vara 25-29 grader varmt, men det ska fungera i låga temperaturer men då kan det ta flera dagar tills det är helt klart. Penslar hela drevet överallt där jag kommer åt, har vid detta laget bestämt mig för att göra “rent hus”.

Slår därefter in hela drevet i en sopsäck eftersom det är risk för regn. Efter några timmar ser man hur färgen “bubblar upp”, både delar av lacken och självklart också resterna av den hårda Triluxen som bubblar upp bara inom någon timme, den färgen är ju inte alls lika hård som själva lacken.

Blir otroligt spännande att se ifall det blir så rent som det ser ut på hemsidan! Ifall allt går enligt plan ska jag kunna blåsa av flagorna med högtryckstvätten eller skrubba bort med en grov tvättsvamp.

Ifall du frågar ditt lokala båtvarv, din färgaffär, din billackeringsfirma eller kanske din marinbutik så tror du att de borde veta hur man gör detta på bästa sätt, eller hur? Men det är inte alls troligt! I alla fall inte enligt mina erfarenheter när jag gjorde just detta.

Mitt drev – ett Volvo Penta DP-SM drev från 1998-99 – hade råkat ut för en hel del ytkorrosion, antagligen under föregående ägares sista säsong med landström på bryggan (ajajaj). Det märktes dock inte eftersom hela drevet var målat i svart Trilux-färg (vilket i sig känns lite knepigt – visst, koppartiocyanat, men ändå…), men när jag började skrapa så slutade det med att jag fick slipa ner drevet till aluminium på kanske 30% av ytan! Ja, båda anoderna var ordentligt slut, på bara en säsong.

OBS! Slipa bara med aluminiumoxid-papper, icke metalliska saker eller sand. Absolut inte stålborste (om den inte är av rostfritt stål) eller stålull, dessa släpper ifrån sig stål in i aluminiumytan och det kommer sedan att rosta som attans. Jag använde tyvärr en stålborste på borrmaskin (osäker på vad den är av, men knappast rostfri) och har försökt slipa ytterligare för att bli av med det, osäker på om det lyckas.

Nörd som jag är så ville jag veta hur Volvo Penta anser att man bör lacka upp ett drev från grunden och lyckades till slut få tag på verkstadshandboken på nätet för detta drev. Värt att notera i detta sammanhang är att boken för min motor från 1998 (V8 5.7GS) har gamla instruktioner och den lite nyare handboken för 5.7Gi etc har uppdaterade instruktioner för målning av DP-S/SX-drev!

Jag utgår ifrån att Volvo Penta insåg att de behövde justera råden eftersom DP-S/SX-dreven är gjutna i en kisel-aluminiumlegerin. Har ej bekräftat detta med Volvo Penta, men en annan teori kan ju vara att de ändrade tillverkningsprocessen av SX/DP-S efter några år, men det verkar osannolikt. Tacksam ifall någon kan bringa klarhet i detta.

Hur som helst, följande text återfinns i verkstadshandboken (tror inte Volvo Penta blir arga ifall jag återger den här):

1. Remove all marine growth.

2. Remove all loose paint and corrosion by sanding or sandblasting.
If sandblasting, use an aluminum oxide blasting media with a particulate
size of 0.008-0.028 in. (0.2-0.7 mm).

3. Remove all trace of grease and wash with hot water and detergent.
Roughen all painted surfaces with medium 3M ScotchbriteTM
pad. Rinse thoroughly with water.

4. Treat any bare aluminum with chromate conversion coating. Clean
the entire area with an acid cleaner that does not contain fluoride,
such as DuPont 5717. Scrub the surface with 3M ScotchbriteTM
pad until it is completely “wetted” with no beads of water.

Note! Fluoride in a cleaner causes a “smut” (dark discoloration
on silicon-alloy aluminum castings), and paint will not
stick to “smut”. If this happens, sand the surface and start
over using a different acid cleaner.

Note! Do not use steel wool. Small pieces of steel wool become
embedded in the aluminum and will cause severe corrosion.

5. Rinse thoroughly with water. The area must appear “wetted” or the
surface is not clean, and paint will not adhere.

6. While the surface is still wet from rinsing, treat all bare aluminum
with DuPont 226S chromate conversion solution. Brush the chromate
solution as required for 2 to 5 minutes to prevent it from drying
on the surface. Rinse the surface thoroughly with water and
allow to air dry. Follow the label instructions exactly.

–If the chromate is allowed to dry anywhere on the bare aluminum
surface, chromic acid salts will form which will prevent
paint adhesion and promote corrosion. Sand the surface to
bare metal.
–It is best to let the part air dry, but if you must wipe the surface
to speed up drying, use lint free wipes not treated with
anything that may contaminate the surface. Do not scrub the
surface, wipe very lightly.
–Do not blow dry with shop air unless it is completely free of
dirt, oil, and water.
–Do not heat the part above 150°F, before painting.
–Do not touch the treated surface with bare bands before
painting.
–The part should be primed soon after it dries, or at least
within 24 hours.

7. Where the prime coat is thin or where the surface is unpainted,
prime with Volvo Penta Primer or PPG Super Koropon epoxy
primer. Do not apply primer over hard finish coat. Primer solvents
must be allowed time to evaporate and the primer must harden
before applying the finish coat. Allow 8 to 12 hours drying time.

8. Apply finish coat. The parts catalogs list numbers for finishing
products.

Ok… här visar det sig gömmas ett helt kunskapsområde att gräva i som de flesta inte har en aning om vad det är. Pröva med att fråga ditt varv om de vet vad kromatering eller passivering av aluminium är, eller om de hört talas om Alodine!

Medlen som nämns, DuPont 5717 samt DuPont 226S är en metallpreparationsvätska resp. en kromateringsvätska. Dessa ämnen finns i olika tappningar från olika leverantörer, exempelvis motsvarande DX533 samt DX503 från PPG eller olika varianter kallade Alodine från Henkel. Preparationsvätskan kallas ofta för Alumiprep 33 (dock ej den vi ska använda till ett DP-S/SX-drev, läs vidare) och kromateringsvätskan kallas generellt för Alodine, det är visserligen ett produktnamn men har blivit näst intill synonymt med “kromateringsvätska för aluminium”.

NOT: “State of the art” idag är tydligen elektrokeramisk behandling kallad Alodine EC2

Preparationsvätskan är i grunden baserad på forsforsyra som helt enkelt djuprengör ytan från oxidering, korrosion och annat jox. Kromateringsvätskan genomför en kromatering (även kallat mer generellt för passivering) av aluminiumets yta, dvs det är ett extremt tunnt lager som kemiskt binds mycket starkt med det yttersta skiktet av aluminiumet. Detta skikt förhindrar korrosion och ger en mycket bättre yta att måla vidare på. Detta är otroligt viktigt för resten av målningsprocessen ifall vi vill ha en lackering som håller lika bra som Volvo Pentas originallack dsv mer än några få säsonger – kort sagt, kromateringen sitter benhårt på aluminium och primern sitter benhårt på kromateringen i sin tur! Volvo Penta har (läste jag någonstans) under 30 år använt denna kromatering i deras lackprocess.

Alodine har traditionellt varit baserat på sexvärt krom, giftigt som satan! Kommer du ihåg Erin Brockovich? Japp, sexvärt Krom. Kallas “hexavalent” på engelska. Jag utgår ifrån att Volvo använt Alodine baserat på sexvärt krom. Ifall man googlar på nyckelord som passivering av aluminium, kromatering osv så hittar man svenska industriföretag som sysslar med detta.

Jag hittade också denna mycket bra beskrivning av en person som använt ovanstående process själv för att måla drev, med goda resultat.

Men hur ska vi göra som privatpersoner? För det första hittar jag inga affärer i Sverige som saluför dessa ämnen, rätta mig ifall jag har fel. För det andra vill i alla fall inte jag ta i sexvärt krom med en 5 meter lång tång ens, det är cancerogent och man måste ha avancerad skyddsutrustning osv. Inget för hobby-Pelle hemma på gården alltså! Men under senare år har det alltså dykt upp en rad olika alternativa vätskor/processer som exempelvis ChromitAL TCP, Surtec 609 Zetacoat osv. Flera av dessa baseras på trevärt krom som inte alls är giftigt!

På nätet finns det en affär som de flesta jänkare refererar till, och där finns alla dessa ämnen – men de levererar inte internationellt… Efter att ha pratat med tonvis med folk så hade jag vid det här laget bestämt mig för att hoppa över kromateringen och köra på den varianten som de flesta rekommenderar:

1. Slipa ner, undvik stål och sand. Jag försöker behålla originallackskiktet där det går. Har ingen bläster som såklart är det bästa utan använder skrapa + aluoxidpapper + borrmaskin med slipstift eller icke stålborste.
2. Använd avfettning, typ Henkel Degreaser, finns i båtshoppen. Tar bort fetter och oljor osv.
3. Högtryckstvätta som en idiot. Möjligen slabba på slutet med avjoniserat vatten för att bli av med salter i kranvattnet.
4. Måla med en 2-komponents epoxy primer enligt instruktion. Jag valde att köpa Henkels standardprimer från båtshoppen. Första lagret ska målas förtunnat, sedan 3-4 lager till.
5. Dags för Volvos originalfärg på sprayburk. DP-S har metallic.
6. Metallic behöver klarlack, Volvos återigen på sprayburk.

Värt att notera med ovanstående är:

• Vi använder inte självetsande primer. För det första är det enligt flera “old school”. För det andra tycks epoxy primern har svårt att fästa på sådan primer och de flesta avråder från det. För det tredje har International slutat att sälja sin Etching Primer och rekommenderar istället att göra som Henkels epoxy primer beskriver – förtunnat lager och därefter en rad lager till, direkt på aluminiumet. De anser att det blir bättre än etsande primer tydligen, enligt en kille på färgaffären.
• Degreasern klarar inte av att få bort oxidationen och jag är osäker på hur effektiv den är mot kiseln som ju finns inne i aluminiumet. Detta tillsammans med att vi inte fått stopp på aluminiumets korrosionsförmåga och att primern har svårt att fästa på aluminiumet är de stora svagheterna. Inte undra på att alla som sysslar med detta säger att, “Tja, du får vara beredd på att måla om efter några säsonger…”. Färgen fäster helt enkelt inte tillräckligt bra och oxidationen kommer tillbaka.

Det gnagde i mig att det borde gå att få tag på de där två vätskorna ändå. Det var då jag till slut hittade www.chemical-supermarket.com – aha! De har både giftiga varianter och moderna sorter fria från sexvärt krom. Game on!

Jag satsar på Chromital TCP från Henkel dvs T5900-TCP samt Metal Prep 79 som preparationsvätska istället för Alumiprep. Detta eftersom jag hittat på nätet att Metal Prep 79 rekommenderas av Henkel för kisel-aluminiumlegeringar eftersom den ej innehåller fluor, också noterat i Volvos instruktion. Alumiprep 33 avråder Henkel ifrån. T5900-TCP (TCP står för Trivalent Chromium Process) har också erhållit militärt godkännande i USA och visar näst intill lika bra egenskaper som referensprodukten Alodine 1200S (sexvärt krom) samt är inte alls lika giftig och läskig att använda. De helt kromfria varianterna visar inte riktigt lika bra resultat som TCP-varianterna.

När jag ändå bestämt mig för att köpa saker från chemical-supermarket så slog jag också till på deras Epoxy Primer som verkar vara riktigt vass, också godkänd för militärt bruk, samt deras stripper EFS 2500 för färgborttagning, uppenbarligen något i hästväg. Ska bli intressant att se ifall strippern kan ta resten av färgen på drevet utan slipning!

Alla fyra produkter landar totalt på 174 dollar, men FedEx-frakten går lös på 253 dollar! Vi landar således på 427 dollar dvs cirka 2700:-, inte billigt direkt.

Nu ser vår reviderade process ut såhär:

1. Pröva EFS-2500 Paint Stripper. Ifall den funkar extremt bra så gör jag drevet 100% rent. Annars försöker jag behålla originallacken där det går. Har ingen bläster som såklart är det bästa utan använder skrapa + sandpapper + borrmaskin med slipstift eller icke stålborste.
2. Använd avfettning, typ Henkel Degreaser, finns i båtshoppen. Tar bort fetter och oljor osv.
3. Högtryckstvätta.
4. Använd Metal Prep 79 enligt instruktion. Penslas på några minuter och sköljs av, skall ej torka på ytan. Vattnet skall sluta bilda droppar. Gummihandskar, förkläde och skyddsglasögon samt god ventilation är viktigt!
5. Högtryckstvätta samt skölja med avjoniserat vatten för att bli av med salter i kranvattnet.
6. Använd T5900-TCP enligt instruktion. Penslas på några minuter och sköljs av. Gummihandskar, förkläde och skyddsglasögon samt god ventilation är viktigt!
7. Måla med Stratocoat Green epoxy primer enligt instruktion. Antagligen 2-3 lager.
8. Dags för Volvos originalfärg på sprayburk. DP-S har metallic så det blir klarlack på det också.
9. Klarlack, Volvos återigen.

Vi är därmed uppe i cirka 6 lager, vilket ju är barnsligt jämfört med Volvos 19 i deras process! Steg 8 och 9 skulle kunna vara mer avancerade men jag kör gärna Volvo originalprylar på den nivån.

Detta är sålunda planen, i nästa artikel tänker jag visa steg för steg med bilder och detaljerade instruktioner samt tidsåtgång.

Ifall jag har faktafel, kommentera så justerar jag gärna. Ifall någon har mer kunskaper i ämnet, kommentera så lägger jag gärna till. Ifall någon firma erbjuder tjänster för kromatering av drev – maila så kan jag lägga in länkar till er.