* Boot OSX and run the Disk Utility tool. Create a new partition using the free space in your HD. Don’t format it, just leave it as free space.
* Download and install rEFIt. Once you’ve done that, you can setup Linux as the default OS by editing refit.conf and uncommenting #legacyfirst.
* Insert Ubuntu’s CD and restart.
* Hold the ALT key while booting up so you are offered all boot options. Select Ubuntu’s CD and install.
* DONE.

No need for Bootcamp or anything, it’s as simple as that.

Just a note about how I’m installing Ubuntu these days. Read sometime ago somewhere (sorry, no link) about being able to reinstall Ubuntu without losing your data. It goes like this. When installing Ubuntu, choose manual partitions. You need to create 3 of them, in this order:

* System partition: pick up the space you want, but 15 – 20gb should be enough since it’s going to be for the system only. Select “/” as the mounting point.
* SWAP: select it on the combo and pick up at least the size of your RAM.
* Everything else, for the home partition. Select “/home” as the mounting point.
* DONE.

Now, next time you want to reinstall Ubuntu, if you follow the same partition scheme, you will boot up to the new system and all your data will be there. And with “all the data” I mean all the data: bookmarks, browser history, files, subversion sites and credentials…. Since in the Linux world all user data is (or should be) stored in your home directory, and you don’t touch that one when reinstalling, you boot up to a new system with your old data in place. I call that a “dirty” installation as opposed to a “clean” installation when I back up all the files and completely wipe out the hard disk.

As per Ubuntu on the MacBookPro, it’s going fairly well. Haven’t touched the console for the installation. Just used the proprietary hardware drivers manager (System > Administration > Hardware drivers) for the WiFi and the graphic card. Have to say that after trying the NVIDIA closed drivers I’m sticking with the default ones, seem to do the job for me. Only if you want the F keys to work as normal human beings would expect, you go through this (using the .conf file method).

When working at home I’d rather use Ubuntu instead of OS X but couldn’t get ADT to find out my Nexus One, so I was stuck on the emulator which was not feasible since one of the apps (.™) uses the accelerometer. I needed to test on the real device.

First I went to the Android documentation and then after Googling quite a bit I finally ended up in this very good tutorial: Nexus One USB in Ubuntu 9.10. But still no luck. ADB was still showing ??????????? instead of my precious. Finally, somewhere, read a comment about the USB cable being involved in the party as well.

Since I don’t want to carry around the USB cable, 3 weeks ago I went out and bought an extra one so I can keep one home and one in the office. First went to a Carphone Warehouse shop and they told me generic cables will NOT charge the phone. Transferring files would be ok, but no charging. After that I went to a T-Mobile shop and they told me that yes, the generic cable would indeed charge the phone. Are you sure? Yes. Are you really sure? Yes. Ok, so be it.

And indeed charges the phone, the guy at T-Mobile was right. However, it prevents USB debugging… in Ubuntu. Cause the same generic cable with the same Nexus works ok on OS X, but it prevents testing on Ubuntu. God knows what kind of shit there’s going on in there (why everything works on OS X, but on Ubuntu files and charging do, debugging does not), but just keep it in mind:

Mind your cable!

(at least on Linux)

We’ve all done it, we’ve all received them:

Sorry, sent the email too fast :/ I was saying…

The email was sent too fast. Gmail helps out a little bit if you try to send an email without subject:

But to me that’s not enough because most of the times when I get to write the Body of the email, the recipients and Subject have been already filled, that’s what email clients lead you to. First To, then CC, BCC, Subject and finally the Body. So by the time you get to the Body, you’ve most likely filled both To and Subject and if for some reason you are too quick to fire up, all the mandatory fields are filled and validation looking for empty fields passes.

To prevent this I’ve taught myself to leave empty To and Subject fields and write the Body first. Only when I’ve written (and read-proof) the Body I fill To and Subject. This has reduced a lot the number of unfinished emails I send.

So I was thinking about re-arranging email clients like this:

See? First the Body, then Subject and the recipients of the email at the end.

Of course this won’t help much when replaying to an email, since both Subject and recipients would be automatically filled, but the current layout doesn’t prevent that either, so that’s a tie.

You guys think this makes sense? Would this help reduce the number of accidentally emails sent? Or am I just talking non-sense?

A File object represents a path to a file or directory.

Uh? Why? When you bring this up some people start banging about old paradigms such as “system nodes” and other ancient stuff. Well, I think whoever designed the AIR API lost a great opportunity to make a difference and start applying some usability to API design. This is most likely due to the old inferiority complex about ActionScript being a “serious” language that Java and C developers cannot look down to.

Well, how do you think Java and C developers explain it to Grandma?

Yeah, you have 2 types of files, one is for storing information, the other is a special type of file which can contain other files (of the first type) and other special files like itself.

Or

Yeah, you have files for your docs, and folders where you can group other files and folders. Y’know, like real life files and folders.

Best part is, since they are forcing the concept so much, they end up with ugly APIs and code. Let’s see:

Smelly code:

Smelly API:
File.isDirectory says it pretty much all:

Indicates whether the reference is to a directory. The value is true if the File object points to a directory; false otherwise.

“The reference“. Maybe they should’ve called the class Reference instead of File, then?

Also, if files and folders are the same, why there is File.deleteDirectory(deleteDirectoryContents) vs File.deleteFile()? Sure there should be a common method called File.delete(), right? Well, turns out that most systems don’t allow you to remove a non-empty folder without confirmation and thus the deleteDirectoryContents parameter.

So, convinced now? If you are not, then enjoy the official API. If you are, check out XAPI for AIR : )

Benefits (IMHO):

* No instances, all methods are static.
* Different File and Folder APIs with consistent method names.
* Much simpler API. Compare:

Reading the contents of a text file in plain AIR:

Using XAPI:

You decide : )

XAPI for AIR hasn’t been released yet, so if you can’t wait just go and checkout the code from Github. Once it’s done it will be released as a SWC, I guess.

Extra ball: XAPI for AIR would be almost 100% identical to XAPI for haXe which was the original implementation (differences due to platform limitations), so if you are up to developing build tools using haXe the jump would be much simpler cause you would be using the same (X)API.

We are developing at ustwo a very interesting internal little project that needs to run 24/7. By default developers should always be very careful with memory leaks and hogging resources, but with an AIR/Flash app running non-stop every detail counts.

To top it up, the app must handle images, SWFs (AS2, AS3) and videos without going through developers. That means marketing can contact one of the designers, ask s/he to produce someething and put it to display without developer approval. Oh, and all assets are in the network, not in the machine. Scary.

Preliminary tests show we are doing OK, we’ve been running the app non-stop for 4 days without a crash or needing it to reboot. The player takes and releases memory when it needs to, transitions and animations look as smooth as the first day, etc.

Check out below some of our thoughts.

FAIL, FAIL, FAIL

Shit will happen, so be ready to fail. Assets won’t load, video will have the wrong codec, image will be 80mb, network will be down….

That’s Google’s approach to servers. Instead of having a big fat multimillion dollar server, they have a farm of 100 mini-servers and they *know* one or two *will* crash everyday. They’ve build their systems to cope with failure and fail gracefully.

Also embed some default content for when everything else fails.

RELEASE, RELEASE, RELEASE

You must release resources. Explicitly remove every single listener you add, use FP 10 unloadAndStop and if you are in AIR don’t hold references to File objects (more about this in another post).

If you are a good dev, the Flash player will behave most of the times…

MONITOR, MONITOR, MONITOR

…but sometimes it won’t. Or something you didn’t even think was possible will happen in-your-face. You can’t prevent all errors, but you can react when they happen.

At the beginning we were trusting our own app to be its own watchdog, but then we got a nasty crash and obviously the watchdog failed as well. So we’ve created a little haXe/Neko app called “the helper” that is automatically called every minute and that checks the state of our app.

At the moment, the helper is being automatically launched using launchd (fancy cron job for OS X), but that has very interesting side effects (again, more on another post).

The helper checks if our app is running using something like:

And parsing the result for a relevant match. If the app is not running, it starts it again using:

Since we are using AIR 2 beta, we could implement a more refined communication system using the new Native Process API, but for the time being checking if the app is running “the hard way” is enough.

UPDATE, UPDATE, UPDATE

Find a good mechanism to auto-update your app. Most 24/7 apps are unattended apps and they might well be in a different room / building / city / country. But even if you are just a few steps away, you still want to be able to remotely deploy a new version.

We decided to implement our own update system based on GIT commits instead of relying on AIR’s update framework.

LOG, LOG, LOG

Log as much as you can. You’ll be happy you did when you need to find out why your app crashed. Believe me, in this case more is more, even if you face huge log files. If you are a little bit consistent you can always build automatic parsing tools for your logs or just run a simple grep to find error traces.

BTW, we settled for a log file per day to avoid massive log files.

WARN, WARN, WARN

As I said before, most of these apps run unattended, so you want to be notified as soon as possible when there’s an error. You can:

* Use a private Twitter account that people subscribe to.
* Send an email. You can do that from Flash using for example SMTP Mailer and a local SMTP server.

Whatever you do, don’t rely on one method only, specially Twitter, in case is down when the app needs it.

REMOTE, REMOTE, REMOTE

You either enable VNC, SSH or both. If you can’t, then be prepared for walking / driving / taking the bus a lot.

–

I’ll leave the details of running your apps using launchd and the peculiar way in which AIR holds “hard” references to files for another posts.

For those who don’t know, XFL is an open format based on zip+xml+assets used also in other products of the suite such as After Effects. The idea is great, storing the information needed in a simple format makes certain things easier:

File diffs. Now that source control is much more spread in the Flash world (sadly, not standard yet) how nice would be comparing two XFL files same as you compare two AS files?

Corruption recovery. How many FLA files have gone down the crapper for no apparent reason? How many FLA files grow in size disproportionally? Well, what do you think is easier, getting meaningful information out of a closed-binary file or out of a zip with xmls and assets?

3rd party tools. A Flash IDE for Linux!! There’s probably no business case for Adobe in porting and maintaining a Linux version of the Flash IDE, but with an open format such as XFL is only a matter of time till someone comes up with an IDE-like software for Linux. I’m almost sure it won’t be as feature rich as the official IDE (takes time), but doesn’t need to be. It needs to allow *me* to work in Linux while designers work in Macs.

It also opens up a new scenario for SWFMill or SamHaxe. Wondering if they are thinking already about adding XFL support (being able to compile a XFL in SWFMill, for example).

Since I think XFL is the next best thing after bread, there’re a couple of things I don’t fully understand:

Two formats

Why keep the FLA? If you can effectively store in XFL the same information that you can in FLA, why does Adobe maintain the 2 formats? Why don’t they fully move to XFL and remove complexity from the IDE?

XFL is not the default

Assuming for some reason that there’s an actual need to keep the 2 formats, why is XFL not the default? Again, since it offers so many advantages over the FLA, why is not the default format?

–

One problem at the moment is that it seems the XFL specs haven’t been released yet. Kind of sad, to be honest. Reverse engineer a XFL file is not a piece of cake and you can never be sure you are doing it 100% right. Also, it prevents people without CS5 to start investigating, and CS5 launch is still due in mid May.

From the tests I’ve been doing, it seems fairly clean and well thought through, but difficult to say due to the complexity involved. Sorry for not uploading a sample file, but since CS5 is not out yet, not sure I wouldn’t get into trouble :/

Anyway, even if not perfect, I’m very happy about XFL, now need to find out about those other 249 reasons : )

This hackathon was about messing around with a fixed set of open APIs and come up with a good app. We got together into teams and TED + Red Gate put the WiFi, the space, the food and the beer (which I had to miss).

I’m reasonably happy with our outcome, because for the time given you can’t really expect much more. Only finding out what was available in those APIs and agree between 7 people what to do took us 40% of the time. Once we knew what to do, the coding fun began.

What we came up with was a very simple way of putting in perspective what very little it takes to help developing countries. Or what could’ve been done with the staggering amounts of money companies in developed countries raise. For example, Spinvox’s first round of funding could’ve funded over 100,000 health related businesses in Sierra Leone through Kiva. Awesome.

Couple of guys putting together a Ruby backend for the API (including caching requests, as most APIs are limited to a certain amount of request per IP), couple of guys putting together HTML + Ajax to read the data and pass it to Flash and I did a little Flash widget to display the data. Fairly simple, but we got it working.

[UPDATE] We won : ) Ventropy is up and running! [/UPDATE]

Interesting to see what other people did. We were very, very pragmatic. Thought about using SVN or GIT, but settled for using Dropbox and worked really well. We got something working as soon as we could and added small improvements till the deadline. Should we take the project to the real life, I very much doubt we would keep anything we coded, though. Other people went for a complete setup (source control, a website, DB abstraction) and I think that time could’ve been better used in something else, but I’m not part of the jury : )

The day was totally worth it, but to me it felt like a sprint more than a marathon. 3 years ago, Yahoo’s Hackday in London was a full weekend of coding. Much more time to code, learn, develop ideas and network. Sure, the time pressure was a funny incentive, but i like more the “what can you do in 48hrs?” thing. Still, thanks to the organizers and the sponsors.

Sadly I had to leave just after the last presentation and to top it up I’m also going to miss the main TEDXCam conference next weekend. Why would I miss such an event, specially when we got free tickets for participating in the Hackathon?

Well, next weekend is the Xtreme Geek Weekend – Barcelona Edition.

Stay tuned!

[Warning, haxeIgniter is not a port of CodeIgniter, the PHP framework. Sure, ideas are pretty similar, but it's not a direct port]

As a rule of thumb, I like it. Although docs and code need further improvement, it seems easy enough to get your head around. Let alone it brings a compiler and friendly haXe syntax to the server. If you want to try it yourself, read the docs, starting at the intro and follow links from there.

I’ll list some things that got me and might save you some time.

By default only works in the root of your server

In theory you should be able to make it work in any folder by tweaking Config.hx, but I got it working in the root and didn’t try again.

Needs write permission on www/runtime folder

When I started testing on OSX under XAMPP I wasn’t getting anything on the screen or Apache logs, for some reason. Finally tried in Ubuntu and got to the problem, you need write access folders in www/runtime.

Custom router

The router is the piece of code that decides the “translation” between URL and controllers. There’re 2 by default, Basic and RESTful. Basic translates URLs to classes like this:

site.com/class/method/param1/param2

The RESTful follows the REST approach where:

site.com/controller/id > show(id, ?args)
site.com/controller/new > make(?args)
…

Ok, but what if you need more control than that? Well, for the time being you just have to roll your own. Create a MyRouter class implementing Router, add it to your Config.hx (about line 259 in 0.9.2) and you have full control over mapping URLs to controllers. See DefaultRouter.hx in haxigniter.server.routing for sample (as any other library, haxIgniter is installed in haxelib’s path, find it running haxelib path or haxelib setup).

No obvious way of creating common + content views

haxeIgniter offers 3 different template systems. haxe.Template (default), Templo and good ol’ Smarty. I’m not so sure that more is more in this case, especially since there’s a low common denominator interface to deal with all of them, but anyway.

If you want to create a common + content view (common being html header, title, css and js links and content being each page’s specific markup) you need to render templates inside templates:

No helper for linking assets into views

By default there’s no helper to include assets in your view (js, css, images, etc). Something like:

In theory, inside a view, that code would create a img tag with the right path to the foo image, working out what the application path is inside the server, etc. At the moment there’s nothing like that, but you can set the base path in your html and then use absolute paths. Something like:

–

So, there’re a few gotchas and probably haxeIgniter is not ready for mass consumption yet, but I think it’s a good start. I’m using it for building the next version of my website, so you will be able to look at “real” code soon. I’m using quotes here because the next version of my site is going to be very, very simple, so probably not the most complete haxeIgniter sample, but sample code nonetheless : )

I’m reading now The Pragmatic Programmer, an all time classic for programmers. For starters, they seem to be the people who coined the term DRY, Don’t Repeat Yourself. Might sound like a minor achievement, but being able to create new words and terms that allow people to communicate faster and better is a big deal. See, now when you hear someone talking about making apps more “web 2.0″ or “harness the power of social media” the bullshit alarm in your brain automatically goes off and you get a quick idea of who you are talking to. Very useful.

The building with the broken window

Very early on the book they talk about something that is very true both in programming and real life. Researchers found that in a building, once a window breaks and it’s not fixed in a reasonable amount of time, the state of said building declines very, very fast. We see this all the time. Whenever something is clean, everyone follows and tries to keep it clean. But as soon as the garbage is left out for too long, people start letting themselves go. Very, very soon, the mindset goes from “wow, can’t leave that rubbish there” to “fuck it, everything looks shit”.

In software projects at the beginning everyone is happy and the rainbow is high up in the sky, but soon enough someone breaks a window. It might be using a literal here cause you don’t have time now to get hold of the config object or making a method public cause it simplifies so much getting the data out of the component, even if that breaks encapsulation.

How to tackle the problem

Fire the developer that breaks the window and doesn’t fix it in time? Too harsh? Is breaking windows a necessary evil from time to time? It really isn’t, but, for the sake of the pragmatic people (tight deadline, client wants this, today I was tired, etc), let’s assume breaking windows in inevitable. I can live with that. But we shouldn’t live with the broken window for too long or devs will start not caring very fast. What once was a nice and clean system can turn very quickly into a mess nobody wants to touch.

If threatening to fire developers might not go down well, what about threatening them with superstition?

Exodus 23:10

And six years thou shalt sow thy land, and shalt gather in the fruits thereof: But the seventh year thou shalt let it rest and lie still

This I think I picked up from Chris Heilmann at StackOverflow DevDays. They say it in the sense that every 7th iteration (whatever long that is in your project), stop coding and clean up. I like it cause I think it brings a good balance between fast coding (I can hack this little thing now, code cleaning comes in 2 iterations) and keeping quality reasonable high.

Also this goes by hand with the idea of the technical debt:

Doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like the financial debt, the technical debt incurs interest payments, which come in the form of extra effort that we have to do in the future development because the quick and dirty design choice. We can choose to continue paying interest, or we can pay down the principal by refactoring into a better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

It’s ok to incur in some “debt” when you kick off the project, same as businesses incur in some real debt when they start. But at some point devs need to start paying back some of that debt or the interest (time wasted dealing with crappy code) grows exponentially.

Bottom line: it’s ok to break a window from time to time, but it’s not ok letting it broken forever. It will haunt you down : )

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 : )