Iraê tech & dev blog

wheningit:

I was listening to the eBook Ninjas podcast and they were curious about why the HTML5 version of the Nook Reader don’t support Safari.

Original podcast episode

I am now on my iPhone, so I am just guessing this and I have to debug it to make sure later, but here is what I wrote to them:

I’m writing you about the Nook web not supporting Safari at all. There is a big technical problem. The HTML5 offline storage engines are changing really fast, and Safari’s webikit is lacking the current specification.

If you would like to explain a little better for the more technical listeners, it’s all about WebSQL being removed from the specification and being replaced by a new spec (which Chrome, IE10 and Firefox already support) called IndexedDB. The former is not only being removed from all browsers but also is harder to develop for. Supporting both technologies is very hard and costly.

Comparing Nook web with the other web readers it is clear that being a later player in this area, they probably just skipped the older API in favor of a faster and slimmer development cycle. They only have to wait a little until Safari updates this API and they will be immediately compatible.

Cheers and kudos again for the great podcast!

Irae Carvalho

Ps: You almost got my name right the first time I wrote you. Nice try!

I fell I must explain why I created yet another autogrow script, and am posting about it. First, lets see the code.

Besides that I was unable to find a good one in 2 minutes searching, I did this kind of code many times, I wanted a way to have a good one ready when I needed this thing again. And since “good enough” is relative, let me note what I mean:

• use of delegation: means 1 event on the page and no more
• $(document) is fast, if you have a page with 40 textareas you won’t need to query the DOM for them.
• some other scripts rely on rows=3 to calculate the growing, this is lame
• I init jquery only once per keyup, and since I pass a dom node, it is fast enough
• I only query the DOM on init, since later on I rely on $().data() to store both variables on the context of this textarea. This is important, since people may type really fast, and You don’t want to query the DOM this many times.

Being perfectionist always may slow down your coding speed, but I repeatedly find myself doing that. So this time I will save this work so I can be more productive later.

In the past three months I’ve been reorganizing my online presence, well, at least trying. I started posting mostly in English and using Twitter mostly to read and communicate about work and development stuff. But sometimes is hard and painful to choose who to unfollow and who to turn retweets of.

So I played a little with firebug and, since twitter uses jQuery, I found out that it’s very easy to hide some tweets so we can curate what will really come from some user to your timeline.

First, the meter of @mentions (aka @replies). When you follow someone you receive only the user @mentions to people you follow, so this tends not to flood your timeline much. At least not with what you aren’t already interested. But when you open someones profile you have this lots of tweets with @mentions that you will not have do deal with, and it’s hard to know what impact this person will have on your timeline. If only we could hide this tweets…

twitter-@ — Drag this link to you bookmarks bar — When you are in Twitter, hit this and all replies will be hidden.

And then there is the meter of Retweets. If you don’t know, you can opt out of the retweets of some user by clicking this button little round button:

So, to decide wetter or not to receive retweets from a user I want also to have a look at how it would be with it turned off. You now can hide then too!

twitter-♺ — Drag this link to your bookmarks bar — Wen you are in Twitter, hit this and all retweets will be hidden.

Drawbacks

1. Whenever you scroll the page, more tweets will be loaded, so you’ll have to hit the bookmarklet again.
2. Using this bookmarklets in timeline too flooded by these features will prevent twitter’s “infinite scroll” feature. To mitigate this, first scroll down a little, so more tweets are loaded, then hit the bookmarklets and you sould be fine =)

I was about to create a userscript for that, but I don’t have the time right now. Maybe sometime in the future, who knows. If have interest in this, let me know =)

Google Doodles are the custom Google logos for holidays or special dates. Yesterday was Martha Graham 117th birthday and Google made an amazing animation to honor her life’s work. If you missed it, here it is:

Besides the amazing hand drawn animation (witch led me to hours online watching Ryan Woodward amazing and enthralling work), many webdevs, like myself, got curious about how this animation was published, everyone with a technical eye saw it was not Adobe Flash.

I spent some time researching it and found out that it’s a cleaver combination of simple techniques. The result has much more quality then an animated gif, is a lot faster to load and less processor intensive then Flash.

The animation and how it’s saved

The first step, of course, was the animation itself. All animation consists of a lot of frames, and many tools can be used to create animation as video files, as separate frame images, as animated vector graphics and so on. Seeing some making offs of Ryan’s works, I suppose he used Flash to animate this by hand. But we already know that the final product is not in Flash, it was converted to what we call an Sprite Sheet.

An sprite sheet is a single image containing all frames of an animation. Sprites are being used for computer graphics since the 70’s and it’s a good way to store frames in a single file. Here is the sprite sheet used for this Google Doodle (original here):

Tools to create sprite sheets

This image could be assembled by hand, but no programmer would like to do that. After all, we are lazy people who like to make the computer do whatever we want so we can focus on the interesting part. There are a series of tools to generate sprite sheets out there. The most straight forward that I found is SWF Sheet. If you have a Flash animation and are looking to a simple way to convert it to HTML5 animation, this is the tool for you. There is a very nice video of it in action:

The video above is shows the creation of frames of the same size, this is not optimal for web and if you look closely at Google’s image above, you will notice that the sprites are not the same size across all frames. This is why I think the Google engineer in charge of this project did it a little more manually. Flash itself can export each frame as a PNG file. After that, one can cut of the frames and leave only the part that changes from the previous one, and this smaller imagens can finally be assembled in a heavily optimized PNG. I found two mac apps that automate this work, one is TexturePacker and the other is Zwoptex. Here is a nice screenshot of the later:

Call me crazy, but I bet that this animation was planed beforehand to have little portions of the logo animated in each frame, just to make it smaller. For me this is amazing, making the artist aware of what is best for the final programming of the logo is a level of detail that I can only dream to work in the future.

Outputting in HTML with Javascript

So, now that we have our very optimized sprite in hand, we need some javascript code to animate it. The logic is simple:

1. Each frame will be a <div> with the sprite sheet as it’s background image
2. Each frame must have the exact size of the frame and it’s exact position
3. Each frame must be inserted in the DOM in a specified time.

I was about to explain the code further, but there are already nice resources explaining that.

If you like to see some code analysis and screenshots there is a nice post by Acumen Brands Break Things Blog.

There is also an youtube video (in german) that shows the web inspector in action. I wish the audio was in English, but the video is easy enough to understand even without audio.

If you want a minimalist code of how to animate sprites in HTML, I found an nice article explaining this principle with an example that uses the YUI library. You can check it out here.

Another very nice post is from the same guy who created the SWFSheet, but explaining how to render it sprites in HTML <canvas> with Javascript. Depending on what you are about to do with sprites, you can use the <canvas> or the DOM to animate your sprites. In Googles case I bet their concern was to use one code for all browsers, so they did like I explained above.

Finally, for more complex sprite uses, there is also LimeJS Sprite Class. This is not a simple library, it’s meant for game development, but is also a good read.

Hope you can find this useful for your needs. This is an amazing topic and I look forward to work with something like that in the future.