As I said in the last post regarding build tools in haXe, I’ve been working in XAPI.

To put it simply, XAPI (Ximple API, the “x” is mandatory on haXe projects, you know?!) is a higher level API for haXe backends. Tu put it even simpler, that means doing more with less lines of code.

So, what can it do?

• Read / write / manage files and folders.
• Get information about your system (OS, where’s the temp or the user folder, etc.).
• Interact with other tools in your system (Git, SVN, MTASC, SWfMill, etc.).
• Search for files and folders.
• And other smaller bits and pieces.

You can do all this already with “plain” haXe, XAPI only simplifies how you do it. Sometimes it also prevents developers for making mistakes. Two quick samples:

Writing content to a text file using XAPI:

Using plain haXe:

[BTW, the opposite is not true, there's neko.io.File.getContent() which I didn't know about and used to use for this example. And also, turns out the PHP package has php.io.File. putContent()]

Checking if a file exists using XAPI:

Using plain haXe:

So, there’s no “isFile()” call in the API, plus using haXe alone you would get an exception because you are passing null (in real world you would never pass null on purpose, but it happens that you pass a variable that is), whereas in XAPI I check for null and, if it is, it just returns false. I think that’s how it should work and I reported it as a bug, but it won’t get fixed :/

Those are the little and not so little additions that XAPI provides to the Std API. To get full details, just install and check out the docs. Simplest option is installing via haxelib (haxelib install xapi), but you can read installation instructions on the wiki.

HippoHX’s API is the mother of XAPI. That’s when I first decided that I was going to expose a slightly different API that **I** thought it was simpler. See those stars around “I”? They are important. You see, this business of building APIs is very, very subjective. I honestly think it’s much like designing. You need to know your target audience, one size doesn’t fit all, and there’s a great deal of taste involved.

XAPI is an API for developers like me, with the same needs I have, etc., etc. I’m fine with that, I have no plan to dominate the world (yet), and I’ve built XAPI to help me on my own projects. I open it to the world so hopefully a) other devs will benefit and b) people will help me fix bugs.

What the future is?

Turns out XAPI is almost feature complete because I want to keep it simple. I want it to be easy to use and I don’t want to target every single project out there, because that’s what the Std API is for. When we were discussing on the list about what XAPI could do,Jonh de Goes came up with an interesting idea about building some kind of “general file system wrapper” API where each “node” could be a file on your system, in the cloud or somewhere else (read it here). Well, that sounds like an awesome project, but out of the scope of XAPI.

On what can only be described as sweet irony, he also was the person who convinced me NOT to do it when I read his series of posts about writing Good APIs (1, 2, 3, 4. Extra Ball, also read his post about Dispersed Development).

Sweet Spot Saturation Rule

“By letting go of the power users, they achieve high usability (this is not always an inevitable tradeoff, but at the very least, simpler applications are easier to make usable than more complex applications”

And that’s exactly what I’m planning to do. By not implementing the general file system wrapper he proposes I’m going to let go power-users like him on behalf of mid-users like myself. I hope it pays off resulting in a very simple to use API. Time will tell.

One thing that I’m thinking about is custom exceptions, though. At the moment if the Neko VM finds a problem it raises an exception which I’m not sure we know the type of. So catching them in XAPI and raising new ones to which we know the type I think would help a lot. Ideas welcome, btw.

Is XAPI for you?

Well, depends on the type of projects you face and the kind of developer you are.

If you build for backends (php, cpp, neko), it might interest you.
If you are rather new to haXe, it might interest you.
If you develop build tools, it might interest you.
If you are wiling to sacrifice some flexibility to gain simplicity, it might interest you.

And to wrap up, thanks to Ian Thomas, he was the first one suggesting such a project more than a year ago. I might need some time, but I do deliver : )

Remember how I’ve been lately pestering about how cool is learning to program in Bash? Well, I’m not retracting, but last couple of days I’ve been doing the same thing but using haXe + Neko + Xcross. And I like it better.

How is this better than the others?

I think it’s better than Bash because haXe is an OO language and it’s fully crossplatform (no bash in Win unless you use Cygwin). I also think it’s better than Ant because you get rid of bloody-fatty Java as a dependency.

How is this done

In a nutshell: you program in haXe, compile to Neko and then pack to a native app using Xcross. Piece of cake!

Let’s say you need to read some config file, compile your AS using MTASC and copy the output file to several places. Let’s assume a simple config file like this:

And that we pass it to our tool like this:

Now the pseudo-code:

And now compiling:

That should be it; we’ve read and parsed a config file passed as a parameter and then called MTASC handling the result. Then compiled to native Win, Mac and Linux apps.

As I said, that’s pseudo code, on a real life app you would definitely need more error handling or might have a more complex config file (maybe xml, try parsing xml in Bash!), etc., but since haXe is a really similar to Flash or JS, it feels very natural to me. Granted, you can do the same in Bash, but to my eyes is much more complicated.

Some more notes:

• From a Neko app you can call any other tool on your system. That includes SVN, Ant, GIT, grep… Whatever is there, you can call it.
• Apps created with Xcross embed the Neko VM so they have zero dependencies (unless you use any of the tools described above, of course).

We are investigating this route instead of Ant for our build scripts. You might think it’s kind of reinventing the Ant wheel, but we have the feeling that this is going to be much faster and flexible to our needs.

We’ll see : )

PS: I’ve used the xa.* package in the code, that’s a little project I’m working on to provide a simpler haXe API for backends. This is a spin-off of HippoHX and it’s not ready yet, but if you are interested you can follow the development in GitHub.

We are looking for a in-house permanent Flash dev to join the team! You don’t need to be a senior, but definitely you need to be more from the programmer side of things.

Our tools set is pretty standard: FDT, MTASC, SWFMill, PureMVC, Ant, command line scripts, haXe…

WARNING: You MUST be willing to do AS2. We know it’s a pain in the neck (tell us about it) but until FP 10.1 / FashLite 4 is a reality on mobile devices we are stuck with crappy AS2. Believe me, we would LOVE to ditch it, but that’s just not a possibility at the moment.

As for the things we do at ustwo™: a ton of Flash stuff for mobile devices, also quite a few iPhone apps, we were part of the private beta team that tested the Flash to iPhone CS5 exporter, we work with some big names, some not so well known names, we do Android apps… Check out the blog for latest info.

ustwo™ London is based in Shoreditch and we also have offices in Malmo (Sweden). We are a bunch of nice people, we put music for the whole studio (despite the occasional cheese shite played by Mills we have good music on), we play footy once a week, we have a beer fridge… but we also work our asses off and push to keep delivering awesome stuff.

So, check out ustwo™’s website and if you feel like it, get in touch.

I reckon this is kind of a niche thing, but interesting nonetheless.

Our current project at ustwo™ is a PureMVC-multicore application. Sounds really fancy, but it’s only a SWF loading SWFs.

To compile those SWFs we have some scripts using Ant, MTASC, SWFMill, Rhino and other tools. Updating from SVN and compiling 18 modules was taking around 90-100 seconds (that’s updating and compiling the whole project, you can compile single modules much faster).

Keep in mind that our compilation process is a little bit more than calling MTASC. We are running some pre-processing, generating exclude files and some other trickery to gain extra performance (we target mobile devices).

Anyway. Got a hint from one of our developers so I did some research to find a way to speed up compilation time. Since most of us have now dual-core machines we should be able to parallelize some of the work, right? Indeed we can.

Finding PPSS was quite easy but understanding how it to works was a little bit more complicated. I’m not going to bore you to death with the nitty-gritty, so this is the flow that adapted better to us:

* In bash parse the list of module folders and create a txt file containing the path to a script passing to it the path of the module as a parameter. One line per module:

* Feed that txt file to PPSS like this:

That’s where the magic happens. PPSS parallelizes each call to the compilation script using both CPUs. When you run it you can see they go all the way up to 80-90% usage, which is kind of the point.

We took some metrics and found a 40% speed improvement, sometimes even more. If you are a compulsive compiler like yours truly, this saves you quite some time.

Going from the serial approach to the parallel approach wasn’t straight forward. Mostly because I had to split the main script into several scripts and that caused some issues due to my bash programming limitations. This is what I learnt:

* If you execute a script from another, the child doesn’t have access to the variables defined by the parent unless you export them…
* … but arrays don’t get exported.
* Also, you can’t “escalate” exported vars from children to parents. The trick only goes from parent to children (security, I guess).

Anyway. Some more command line black magic under my belt, which is great. The console is a very, very powerful tool that can simplify and standardize daily tasks, which is a must when you are on a team of 10 devs. Not that it is the nicest programming language (actually, it’s pretty ugly), but its ubiquity makes learning it worthwhile.

I’ve just finished reading Coders at Work, and it’s a really good book for developers. Peter Seibel interviews 15 very successful programmers about how did they start programming, what changes they’ve seen in the industry over the last decades, what they look for when hiring new people, how do they debug, etc. I also quite like the tone of the book because it is a laid back conversation between peers, to the point and no bullshit.

Keep in mind that these guys are responsible for quite a few things that today we take for granted such us memcached, Unix, JS, Internet, Java, Firefox, etc.

One common thought is that back in the days they used to know in and out every line of code that run on their machines. Most of them spent quite a few years programming assembly and “close to the metal” (aka, the hardware), but today’s programmers “don’t know the whole thing“.

Well, they are right.

I for one have no idea of assembly, machine code or even C. Now, is that good or bad? Granted, the more you know, the better, but most of them also agree that with the level of abstractions that we programmers “enjoy” these days this doesn’t sound possible any more.

For example, think about the abstractions of the typical Flash movie:

Hardware > OS > browser > Flash player > framework of choice > your app here

Now, that’s obviously a gross overview, since we could break OS in (that I can think of, not even sure it’s the right order):

kernel > drivers > window system > graphic card

The thing is, even if you had access to ALL the code running (which most likely you don’t), who has the time and skills to look at it _and_ get job done?

With all those abstractions in place, when something fails good luck trying to figure out where the problem is. Can you be sure? Because even when we find a bug in the player, is that Adobe’s fault? Mozilla? Explorer? Linux? A combination? Very hard to tell, more so when a few of those elements are black boxes (proprietary software, you don’t have access to the code).

Most of those guys wonder about what are the best skills for programmers nowadays. When they started coding, it was a must having very good math skills because of the lack of HW power. They needed to squeeze every single CPU cycle and memory position. Either that or your program wouldn’t go anywhere. We all know that’s not true any more. Is this bad? I say it depends on your work.

If you are building compilers, 3D engines or drivers, then by all means you need to focus on performance and have those skills. But if you are doing user interfaces I bet your users appreciate a hand for design and usability. So, completely different skills needed. The fact that HW has gotten so powerful has lowered the barrier for being a programmer so people with very different skills can afford it now, and I think that’s good. The fact that a designer (and probably even the most advanced Flash “programmer” looks like a designer to them) can build an interface without having to worry about HW, graphic cards and code optimizations is pushing computers to different areas.

Even for developers, the skills you need now are not the skills you needed 40 years ago. They think most developers these days “play Lego“. They mean we build blocks with the frameworks or libraries available, but don’t do any “real” programming. They have a point. But again, is that good or bad? This is classic DRY stuff. Why would I want to code a SHA1 library if there are quite a few there already? Heck, doing so would not only be a waste of time, it’d probably be a security hole as most likely I wouldn’t get it right. Why would I want to roll my own PHP framework if there are a myriad of choices offering DB abstraction and XSS and CSRF protection out of the box?

See, I think what’s important is having the skills to roll your own code when needed and use somebody else’s when it makes sense. And that requires some skills as well. First, you need to be able to identify what’s core for you and disregard coding everything else. Then you need to be able to start using somebody else’s code without having to understand it all, many times only looking at some (often incomplete) docs or API. That require skills. A different type, but skills nonetheless.

Also, obviously with all due respect, I think they miss an important thing. They didn’t start from scratch either. Nobody does.

Standing in the shoulders of giants

For example, very, very, very few physicists question the thermodynamics laws. Very, very, very few mathematicians question Pythagoras. They take them for granted. They’ve been proved. They use them as a base to build on top. Yet, there’re those very, very, very few that do indeed question the core laws that everyone else just “use”. It’s their job challenging those laws, otherwise completely accepted, and put them to the limit and analyze them with modern eyes.

Why we don’t have similar laws or universal truths in computing? Well, for starters computers are what, 50 years old? 70 years old? 80? Physics and maths have been around thousands of years. Even if you could compare both worlds, the rules of the “computing universe” have been created by human beings whereas the rules of the Earth just are. Those rules haven’t changed since the Big Bang, what changes is our understanding of them (call it physics math. chemistry, whatever).

As I was saying, quite an interesting book. One of those you can re-read in 2, 3 or 5 years, still enjoy it and still learn from it. Go read it!

Have you ever been curious about how many lines of AS a project had? To be honest, I couldn’t care less but hey, there’re clients out there with pretty good reasons for it.

So, Google a little bit, first result takes me to CLOC.

In theory you should be able to restrict CLOC to a language only but most likely due to my incompetence with regular expressions I couldn’t get it to work the way I liked it. So doing a little bit of command line trickery, I had to create a text file containing the path of the AS files I wanted to parse and then feed that to CLOC. This is how it looks:

Then send that to CLOC:

That would be the simpler option. But because my project is made of modules (it’s a multicore PureMVC app) and the client wanted both stats per-module and global, I had to push it a little bit further. Basically create a stats file per module and then merge them together. Piece of cake:

Where “overall” is the name of the final output file (actually, 2 files are created, one per file, other per language) and “moduleReportX” files are the partial report created before for each module.

Another good thing about CLOC is that it runs in both OSX and Ubuntu at least pretty much out of the box because both come with Perl installed. However, had a little problem in Ubuntu but contacted Al Danial (the author) and he fixed it right away. If you are running Perl 5.10, go to the line 1038 of CLOC and replace “%” by “@”.

Good to go!

I think Linux/Ubuntu is yet again more easy to use than OSX, but I don’t even feel like bitching today. Here it goes:

++ Open Script Editor and type this updating the name of the VM you want to launch:

++ Save as Application Bundle and check Run Only.

Off you go.

Thanks.

** Mac (open terminal):

** Ubuntu (on any window):

CTRL + H (toggles on/off hidden files).

OS X, the paradigm of usability MY ARSE.

(And please don’t embarras yourself saying that Mac users don’t need to know about hidden files)

[Sorry for those who got an incomplete post, hit Publish again when I was meaning to save]

So, yesterday went to StackOverflow DevDays in London. I’ll start with the bad part:

Organization: Massive queues to pick up food or coffee. FAIL. No 10 minutes break between speakers. FAIL. Mics failing. FAIL. The chairs EPIC FAIL.

The content: I understand that FogCreek is putting some money to sponsor the events but Joel run 2 completely sales focused sessions, one about FogBugz, the other one about FogCreek. Didn’t enjoy either. Please remember that this is not a free conference. Fair enough, it’s not pricey either (£85) and I’m not sure if they cover expenses with tickets only, but it just felt too much advertising. I’m not alone, read the twits. BTW, I wonder if they got similar feeback in the US.

That’s it for the bad part, now the good part.

Joel: when not doing a sales pitch, he is very funny and a great speaker. The intro video with Jeff was a lot of fun.

Jeff: the same. It was like a live Coding Horror post, always very inspiring.

Now the GREAT part:

Jon Skeet: really funny, probably the best speaker and that I didn’t see coming. Put in perspective that Jon Skeet is the SO user with highest reputation and such a badass that he has earned his own facts, much like Chuck Norris! I would love to see him again, FOTB next year? People loved him. He talked about the absolutely mess that is working with dates, strings and numbers in computers due to so many different standards. All this with a sock puppet in his right hand.

Things like Argentina decided this year NOT to follow daylight savings and warned the world only 11 days before hand. Well done you guys!

Christian Heilmann: another very good speaker. He’s a Yahoo! evangelist and I can see why. He demoed YQL and I I had a question banging in my head all the time: Why nobody told me about this before?!?!?! It’s a Yahoo! service to mashup open APIs and it looks REALLY powerful and something I’d definitely look into. Not sure for what yet, but looked very, very cool.

Pekka Kosonen: He works for Nokia and gave a talk about Qt (since when Qt has been pronounced “cute“?!?!?!) that, for those who don’t know, is the framework Nokia finally bought not long ago for building cross-platform *native* applications (including phones and all major desktop OSs). Well he was VERY honest about Nokia. I mean, very, very honest saying things like “we used to suck a lot, now we are getting our act together“. He was very funny, the sort of speaker that doesn’t laugh his own jokes, even when they are good. The honesty was very refreshing after the sales-oriented talks. Again, I wonder what would a US company do should an employee speak *the truth* that about them. Wonder what Joel was thinking (something along the lines “I would SO fire this guy as soon as he’s off the stage“).

Some pearls to put in t-shirts:

Joel: “The mother of all options is giving the user a compiler”
Jeff: “Don’t be afraid of failing publicly ”
Pekka Kosonen: “Light at the end of the tunnel, this time hopefully not a train”
Pekka Kosonen: ” I wrote a Java book but was only for the money”
Phil Nash: “Objective C is like Marmite: LOVE it or HATE it” *
J Mark Pimp about Obj-C: “80s called, they want their memory manager back” // <-- HILARIOUS

There were other speakes as well, they did a decent job. There was a nice intro to iPhone development, a nice intro to Android development, a nice intro to jQuery, a rather dry talk about compilers and a rather drier talk abut Python. Not bad for a single day.

Would I come back next year? I'll have to think about it.

* For probably anyone outside of the UK: Marmite is a cream that literally people either love or hate, they even say it in their adds. Me? Haven’t tried it!

Remember this post where I was talking about an app we were doing for Nokia and was the reason why I had to delve into Kuneri? Well, it’s up and running:

Kids treat you like a taxi service? Now you can act like one with this GPS enabled taximeter application on your mobile. It even includes additional annoyance tolls and children-friendly payment options.

It’s a simple looking app but it does indeed use the GPS and the calculation of the fare is done following London’s official taxi rules. It also takes into account if for whatever reason you lose connection with the satellites. Well, not so simple after all!

But I cannot take full credit, fellow ustwobie Dain Demmel did a big part of the app (if not the biggest), plus we teamed up with WorkClub for art direction.

Anyway, very happy to release an app that people actually use and are happy about.

[UPDATE] Here’s a video demo of the app. [/UPDATE]

And lately we’ve been releasing quite a few apps at UsTwo:

** Ben 10 MouthOff in partnership with Turner.
** .™, brutally addictive first release of the 48hours app series (watch the interview with Mills if you want to know more about the concept).
** Hell-oween MouthOff special.
** And the soon to be released inkstrumental in collaboration with Jon Burgerman.

We don’t stop : )