To apply, send an informal application, CV and contact information to tuomas-at-52vali.com, outlining why you would be a good candidate for the position.

Unity3D developer

Required experience and skills

• Prior experience in Game development with Unity3D in either C# or JavaScript
• Familiarity with Studio3D Max or Maya and Unity art/development pipeline
• Good eye for design
• Experience with extending the Unity editor
• Basic knowledge of network development
• Must have shipped at least one project with Unity
• Interest in games

Optional skills

• Experience with NodeJS / JavaScript a big plus
• Experience with other web development languages
• SCRUM master
• Flash and ActionScript proficiency
• Knowledge in SVN / Git
• Good spoken / written Mandarin

Unity3D developer trainee

Not yet a experienced Unity developer, but always wanted tyo be?

Required experience and skills

• Prior experience in any of the following languages: ActionScript, JavaScript, C#
• Prior experience in Game development using any tool or programming language
• Eagerness to learn Unity3D
• Good eye for design
• Interest in games

Optional skills

• Experience with NodeJS / JavaScript a big plus
• Experience with other web development languages
• Flash and ActionScript proficiency
• Knowledge in SVN / Git
• Good spoken / written Mandarin

Games Platform developer

U-Baby is working on a unified Games Platform / Framework to power all of our future games using multiple clients and a NodeJS/MongoDB-based back-end.

Required experience and skills

• Experience in developing with NodeJS OR experience building generic games platforms
• Experience with either Flash or Unity3D
• Experience with Database design & ORM
• Professional knowledge of developing network applications
• Interest in games

Optional skills

• Flash and ActionScript proficiency
• Experience with MongoDB
• Experience with Git and creating deployment scenarios
• Good spoken / written Mandarin

Now look at the result (with Chrome).

Oh wow. Good 4k’s used to be the last bastion that of desktop applications that were hard, if not impossible, to create using JavaScript. Check out the post-mortem here.

First off, let me congratulate most of the tech journalists for once again showing that they really don’t know what they are writing about. “Adobe kills Flash for mobile”, “Flash is dead”, “Flash for mobile devices killed”, just to quote some of the headlines. I think there’s a great leap from “We’re going to stop development of the Flash Player for the *browser* of mobile devices” to “Flash is dead”, right?

I’ve always, and will always use the best technology to suit each service, game or campaign I built. The “best technology” for a job can be defined in a simple formula: impact multiplied by reach. If you are able to create impact without reach, you have nothing. So I would rather say that Flash for the mobile web (to spell it out: on a mobile device’s web browser) was never even alive. Sure, we had a few funny Android devices that could play back Flash content embedded on web pages, but have you ever thought of telling your client (or boss) to build a solution with a technology that has about 5% penetration? I sure hope not.

Given the weak penetration of the Flash Player for the mobile web, exactly what has changed after Adobe announced FP’s mobile browser development discontinuation? That’s right, absolutely nothing.

So please tell me, disregarding Adobe’s announcement, why exactly  do you think Flash is once again dead?

Ok, so I quit Finland and moved together with my family to Shanghai now three weeks ago. I joined a local “startup” creating and operating kid’s games in the Chinese market. But more on that once I’ve signed my agreement (huh, some things take a looong time in China).

Currently, I’m probably at phase two of “the process” that expat’s go through: Culture shock. The first weeks were fantastic, Shanghai’s definitely a great and lively city with good food, nice skyline and nightlife. Now I’m just banging my head against the wall trying to get my Visa stuff worked out. My new colleagues at the office are very helpfull, but they too make mistakes. Apparently I was missing two documents (out of nine) and have to take the 1.5 hour trip to the entry/exit bearuea again tomorrow. All while my earthly belongings are shipping in from Finland tomorrow and will be eaten by customs trolls if I don’t complete registration before that. Well, it’ll be easier once all of this shit is done with.

Looking forward to skipping step three (denial) of “the process” and going straight to step four, acceptance.

Nokia introduced their first MeeGo device last week, the Nokia N9. It certainly looks good and actually contains a few new innovations (about time), like getting rid of that last hardware button (Steve must be furious that Nokia beat him to it).

However, many people have raised the question of why Nokia is discontinuing any development on further MeeGo devices and abandoning the platform entirely given that they just released a device that actually get’s very positive inital feedback from users and the press (the last time they did was about 5 years ago with the N95). Even people within Nokia are giving Steven Elop (and the board) a hard time (woth a read).

Still Steven stays firm and goes on record to say that no matter how huge a hit the N9 turns out to be, Nokia will still abandon MeeGo. As I’m lazy, I’ll just quote a Gizmodo comment, because it’s very much in line with my thinking:

Simply put, Elop has it correct. It really doesn’t matter how successful the N9 is because everyone wants to measure it by unit sales (short term success) and not the development of the ecosystem (long term success). Sales can be taken away from you (see RIM’s recent report on their Blackberry sales) but ecosystems live on for much longer. Everyone knows that Nokia builds excellent hardware but their software is so-so at best. What makes people think that it will create better development tools than Microsoft? What makes people think that it will line up the retail deals in the US so you can buy music, movies and TV shows? What makes the N9 different from webOS on a fundamental level?

Everyone says that webOS is probably one of the best mobile operating systems out there, but it hasn’t become all the rage since it’s release. Why? Sure, the hardware is a major contributing factor, but even if that were fixed, you’d be left with a device that would have ONLY succeeded in a world where the iPhone doesn’t exist.

The reason why people buy iPhones, iPod Touches, and iPads is because of the ecosystem Apple has developed. Any app you’ve bought for your iPhone will work on your iPod Touch or iPad. Any song, movie or TV show you’ve purchased from iTunes will work. Or books from the iBookstore. Or having first-class podcast support. It’s a very, very strong ecosystem which Nokia knows Microsoft is far closer to achieving than their own company ever would be.

People need to stop thinking that only having nice hardware/software will save your butt today. This isn’t 2006. The iPhone showed that you need ALL your ducks in a row to win at this game.

A few points of interest on this one: Try the text input on page two to see how layout is validated. Try and hold down the vertical scrollbar thumb on page 5. Scroll containers validate their context correctly even though the whole container is resizing.

Also, check out Sofanatics, the first app that has been built with Flow. To get timely updates on the progress of the framework, follow me on Twitter.

Flow (the fast and lightweight layout-, effects-, graphics-, data-binding-framework) is now up on GitHub. There’s no documentation, no examples, even no readme file, so it’s probably only interesting if you… hmm… no, there probably is no reason why you would want to dig through the source. Just wanted to let you know, though. Stay tuned.

However, I still wanted to use many of the features that make developing with Flex so much faster than building out an app in pure ActionScript. In no particular order, these features are:

1. MXML. Declarative programming is one big time-saver.
2. Contraint-based layout. Our interface scales with the browser. Without a good layout-framework, putting the interface together would require a lot of extra effort.
3. Data-binding. Once you hook up your data via data-binding, you swear never to go back again.
4. States. Coupled with declarative layout, states provide a fast way of putting together the visual representation layer of the app.
5. Transitions & Effects. I’m a sucker for smooth transitions in UI’s
6. Declarative graphics. Declaring shapes, fills and borders in MXML is just cool.

In addition to these Flex-based features we had the following requirements

1. Be fast. That’s a no-brainer.
2. Be small. The Flex framework takes around 300kb without any components. I’ll target 30kb.
3. Mix&match. You should be able to use any assets in your display list, not only instances derived from UIComponent, as is the case with Flex.

Searching the Internets, I did not find that many frameworks that supported these requirements. The best that I found was ReFlex, but I had some issues with it. While it provides most of the features I was looking for, I still found it to be a bit too slow. Most of the core code relies on anonymous objects, arrays and interfaces instead of using strongly typed parameters and vectors. I did not measure performance, but I’m sure its performance is not optimal. And although developing against interfaces makes your code more manageable, I opted for making my core code as fast as possible, even if it meant making it harder to read or modify (though creating components based on the framework should of course be easy and have a clean API).

So I decided to write my own. It currently powers all of the Sofanatics client’s UI, so check it out to see some of it’s features. Otherwise it’s still very much in the making. Once done, I’ll release it under the MIT license and put it up on Github. But even in its infancy, I do like it very much. It gives you a tenfold increase in productivity against building a UI via ActionScript, but gives the speed of a pure AS implementation.

Now all I need a great name for this cool little framework. Got any ideas?

One Infinite Tunnel is now available on the AppStore. Get it while it’s hot! And If you like it, please be so kind as to leave a review.

Deep in unexplored space, you’re spaceships controls brake down while exploring a massive underground tunnel complex. With just one engine working to control your tilt, how long can you survive before you smash into the hard rock?

One Infinite Tunnel features gorgeous 3D graphics, “one button” controls and, well, one infinite tunnel. Compete against the world on Game Center and OpenFeint.

One Infinite Tunnel works on all iPhones, iPod Touches and iPads.

While I understand why especially many finns are so upset about the change of direction, I couldn’t disagree more. Sure it hurts throwing out a OS that Nokia has received billions of R&D money, but guess what? Symbian still sucks and nothing is going to change the fact that with Windows Phone, Nokia is finally on a path to deliver smart-phones that can actually compete in the market.

It’s simple to choose when you have a choice of selling someone else’s beef or your own shit, even if you’ve poured billions into producing that shit. And this is something that people don’t seem to grasp. Symbian is not and was never going to be a competitive OS. So it really wasn’t a choice to start with. What about MeeGo then? Word has it that its development has run into the same problem that I’ve witnessed too many times with Nokia: An army of middle managers trying to push development in different directions either to gain recognition or claim their bonuses. Nokia is doing fine on the hardware side where you have a relatively small team (and relatively few managers) for each product. But when it comes to the OS, where features need to serve the whole company and all of it’s products, the result is a fragmented, slow moving, over managed bloat of compromises. Just pick up a N8 and you’ll notice that while the hardware is excellent, the OS just makes the product frustrating or even unusable.

So I have to salute Elop and Nokia’s board for making this bold move. While it may weaken short-term sales (who wants a phone with a dying OS?), I’m sure it’ll make sense in the long-term. For the first time in many years I’m actually looking forward to see some cool new Nokia devices. Heck, I’ll probably even start developing for Win Phone myself.

We’re using CodeIgniter on Sofanatics as our back-end. One problem we faced was that our installation didn’t perform well enough. Sure, Amazon’s EC2 is to blame for most of this. If you look at any benchmarks out there, you’ll find that Amazon isn’t the best cloud in regards to speed / €. Nonetheless, our RightScale managed Amazon E2C instances gives us the flexibility to deliver a ha-service that automatically scales according to demand, so changing to dedicated hosting is not really an option for us.

Now, all clouds suffer from slow IO operations, and caching database queries (to Memcached in our case) of course gives you a great speed increase. But once we had cached everything we could we still didn’t have the speed we desired. Our most critical part of our API that gets bombarded very frequently during matches, we could manage to respond to 22.000 hits per minute (367 hits / sec) on one E2C Medium instance. While this really sounds sufficient I wanted to take the opportunity to check where this bottleneck actually came from.

CodeIngiter is a rather small framework and many libraries and helpers required by our app are loaded on demand. For the API call that I tested, CodeIngiter didn’t have to do much. It resolves the Controller for the given URL, does some initialization, calls the controller and instantly returns the result as a full page cache is hit 99.9% of all times. There’s no room for optimization there, and having gone through the way CodeIgniter initialized, it does this in a very efficient manner. So what can we do?

Well, I decided to skip CodeIngiter altogether. For that particular API call (and all other API calls that were hit frequently) we actually didn’t need to know anything about the calling user. We were able to include all the required parameters in the URL and everybody who hit a specific URL would get the same exact response, which was valid for at least a few seconds. So we did an override of CodeIgniter’s output-method send the data to Memcache (every front-end machine has it’s own Memcache-server for super fast look-up) if that specific call was cacheable.

Next, I send all requests to a very simple script that connected to memcache and checked if a valid cached result existed for the URL that was requested. Only if the cache was missed, would the script forward the request to CodeIgniter for execution.

The result? We got from 22.000 hits per minute to 250.000 hits per minute (4166 hits / sec). Now _that_ is a good result.

So what exactly should you take away from this?

If you need super speed, have your cache serve data as upfront as possible. Also keep in mind that PHP files are surprisingly slow to load, even if they don’t execute any or much of it’s code. In our case we were using eAccelerator, so our PHP files didn’t even need to be parsed but still, thats were most of that whopping 1100% speed increase came from.

Big thanks to Aleksi Eeben for the title music, Black Salamander.

• IE9 for Windows Vista & 7 only. This will happily ensure that it’ll take many years before we can forget to build our pages to gracefully degrade to HTML4. Forget about using Canvas, client-side form validation, the video- and audio-tags for a while…
• Flash on Mac. Well it’s not only 2010 that Flash on Mac has sucked, but it’s on the list as it still is sucking big time. Your average Windows Net-book is running Flash faster than your 10 times more expensive MacBook Pro.
• Nokia. Yup, they’re still sucking as much as in 2009. They’re only notable new release – the N8 – is crap because of it’s miserable OS. Maybe that Canadian fellow will be able to shuffle things around for 2011.
• The whole Flash vs. HTML5 discussion. Dudes, get over it. Flash co-exists with HTML5. If you think otherwise, just stick with one tech and shut up.
• Sarah Palin. I’m totally baffled that someone actually thinks (and wants) that she has some chance in the next presidential elections. Voting for her is like eating dog-shit while shooting yourself in the head.
• Greece. You’re government has overspent and now you’re asking us to bail you out. If you’re not paying back, we’ll annex a few of your islands.
• iTunes. Here on the list due to Spotify. If you’re living in one of the countries where you have access to Spotify you’re bound to have the same feelings towards iTunes: It’s a massive, slow-moving, monolithic dinosaur and I hate that I have to use it to activate and sync my iOS devices through it. Uh, and Ping didn’t help either.

First and foremost: Finally! It’s been almost a decade since Adobe (or back then, Macromedia) shipped web-based GPU accelerated rendering in it’s other plug-in, Shockwave, with the release of Director 8.5. Ever since it’s been on the wish-list of almost every developer in the community for every single Flash Player version shipped ever since.

As I’ve not seen the API or played with the Molehill pre-alpha (hint, hint) I can’t tell whether I like it or not. Well, that didn’t come out right. I like it already, but I don’t know yet whether I’m going to love it. Looking at the videos published by Adobe and Alternativa it certainly seems that rendering has been enough taken care of with multi-texturing and bump-mapping letting you assume that you could create other pixel-based surface shaders.

What however is not clear is if the API supports realtime-shadows, mesh deforming using bones, rendering to textures for reflection shaders or model-based level of detail. Sure, many of these effects can be seen in the demo-videos, but it’s not clear whether these are natively supported by the API, or whether these have been created using ActionScript. For some games, ActionScript might be sufficient to do e.g. bones-based mesh deforming, but most others, this would be way too slow. Specifically I’m concerned that the Racer demo was said to contain Phsyics that had been created using ActionScript (dudes, you already had Havoc support almost a decade ago in Shockwave, what gives?). From this one might assume that model collisions need to be done in ActionScript which basically will kill the performance for 1st/3rd person shooters or adventure games that have a detailed world where box- or sphere-collision is not sufficient enough. In the end, ActionScript is still very slow.

One other point of interest would be to know whether there’s going to be any specific tooling for 3D. I would certainly hope that Adobe has chosen a binary-based model format instead of going with Collada. This of course would require exporters to all the major 3D modelling applications as was the case with Shockwave 3D. Of course animations would have to be supported, too.

Unity to the rescue

Then it hit me, Unity will provide the tooling. It makes perfect sense.

Unity has long been an integrated IDE for 3D development that has published to multiple platforms. Currently it supports PC, Mac, Web based (through their own plug-in), Wii, xbox360, iPhone and Android publishing, with PS3 support coming soon. It’s in their blood to do publishers for totally different hardware and software environments. And Flash is going to be almost too easy for them. Here’s why:

1. You can create applications in Unity using EcmaScript 4 (or what it would have been). They actually call it JavaScript, but it’s a strongly typed language which is almost identical to ActionScript. There are a few additions (such as sub-routines, which are really cool) and differences mainly in how vectors are declared, but these are nominal.
2. Unity already has a compiler to create the SWF. You know, the Flex framework along with it’s MXMLC is open source.
3. Unity already supports DirectX 9 and OpenGL, shaders and the rendering pipeline is not that different in the Flash Player as in their own plug-in.
4. The biggest problem that’s holding Unity back is the adoption of it’s plugin. No-one has it. That makes developers think twice before starting to use it. Targeting Flash would solve that problem once and for all.

There you have it. It’s a win-win-win;) Unity wins by beeing able to sell tooling, Adobe will win by becoming the standard delivery platform for 3D games (it’s not all that certain if tooling lacks), and developers win as they get great tooling and can publish the same 3D app to the web, desktop, phones and consoles.

Update: Fantastic! Four months after writing this post Unity announces support for the Flash Player! A great move from Unity, and excellent news for all Flash devs out there.

To summarize this post: Don’t use Facebook, Twitter or any other on public WLAN access points. Anyone can now *very* easily, in a few seconds, hijack your account.

HTTP is an insecure protocol and anyone on the network can sniff what data gets send from the internet to any other client on the network. Still people have been living under the wrong impression that capturing ones session is something that only hard-core hackers can achieve. Until now.

Eric Butler just released a Firefox extension that makes hijacking HTTP-sessions very, very easy.

Basically the extension looks for data on the network (e.g. your companies, cafes or conferences WLAN) identifying a users session to one of the services supported by the extension, and you can always write a bit of code to support any service that doesn’t use SSL.

I just tried Eric’s extension and yeah, it was easier than I thought would be possible. In under a minute I had captured the sessions to Facebook and Twitter of *all* of my co-workers and could have easily written posts in their name, or worse, reset their passwords and email addresses for these services and thus effectively captured their accounts.

Scary stuff. Currently the only fix is to force SSL (Firefox extension) on services that support it. Read about it on Techcrunch. Otherwise I suggest you don’t log onto that open WLAN, or if you do, make sure that you don’t use any unsecured services.

Stay tuned for more info: twitter.com/artman.

Bashing Nokia has become nothing short of a national sport over here in Finland. Even big magazines publish front-page stories titled “Mokia” (translates to fuck-ups) and analysts are arguing on national television what Nokia did wrong and how their management structure is messed up.

You see, our relationship with Nokia is one of dependency. Nokia’s impact on the Finnish economy is huge. In 2004, Nokia’s share of Finland’s GDP was 3.5%, and accounted for 25% of all exports. If Nokia is messing things up, it’s not only the shareholders feeling it in their stock, also it’s many suppliers and subcontractors are feeling it, and to some effect, the whole Finnish population too.

This is why, with every new model Nokia churns out, the Finnish press goes into overdrive mode to proclaim the end of iPhone’s and Androids superiority and the inevitable Nokia comeback. This happened with once again with the N8. And once again everybody who made even the slightest remarks that the N8 might be competitive look really, really stupid.

Now, the on-his-way-out VP of whatever, Anssi Vanjoki recently famously said that jumping over to Android would be like pissing in your own pants for a short, warm moment in the winter. Well, he surely has got a good point there, one that we’re going to see in a few years from now as Android device manufacturers won’t be able to differentiate their handsets enough from one another.

But still, pissing in your pants with Android is a lot better than shooting yourself in the head with Symbian^3.

It don’t want to go into details on what’s wrong with Symbian^3 as that would be the same as having to say what’s wrong with having a flag-pole up your arse. In the end what matters is that Symbian renders the N8 completely anti-competitive. There simply is no reason whatsoever to prefer a N8 over a modern Android, iOS, Windows7 or BlackBerry OS phone.

Whoa, didn’t see this coming (this soon). Apple has issued an statement regarding changes to the sections restricting Apps to be developed using 3rd party tools, such as Flash.

This is good news indeed. Not that I’m going to use Flash to develop any games for the iPhone (it’s still way too slow to do anything decent), but it’s definitely good to see that Apple is loosening it’s grip on the store and let developers choose how they want to create their apps.

From Apple’s statement:

We are continually trying to make the App Store even better. We have listened to our developers and taken much of their feedback to heart. Based on their input, today we are making some important changes to our iOS Developer Program license in sections 3.3.1, 3.3.2 and 3.3.9 to relax some restrictions we put in place earlier this year.

In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need.

The first preview of the upcoming Flex 4.5 SDK – code-named Hero – has gone live and Deepa Subramaniam, Flex SDK product manager, just announced it. Newsworthy on Deepa’s post is that Adobe, at least for this release, has chosen to build the SDK against a future, yet to be announced Flash Player. Because of this, they have not been, and will not be able to post nightly builds, as they don’t want to give away any new features of the Player.

At least to me, that sounds weird.

Sure, we’re all know that companies love to control the publicity of new products, mostly to gain enough momentum to get good press out of an launch event. It sure makes sense to control product details regarding (for example) CS6, but the Flash Player is a different beast. End-users don’t care about new features, and developers don’t need to press to tell them.

So what gives? Why hide upcoming features of the Flash Player? Wouldn’t being totally open about the future of the player be a great way of getting the community involved in the development of the player? After all, it’s developers, not end-users that you build the Player for. Wouldn’t it totally make sense to have the input of the community as early as possible and be able to act upon that feedback without an 1,5 year cycle?

The only reason I’ve identified for this secrecy is the fear of competition (Silverlight). The introduction of Silverlight’s latest release was one of the biggest Deja’vu moments I’ve had.