So anyway, recently Opera released 10.60, which is awesome news because finally Linux has a modern stable release, because of the amount of new eye candy in the UI, the new supported web standards (like Geolocation or WebM video, yay!) and… because of the amazing speed (“much faster than a potato“).

On Saturday, DailyTech published an article comparing the speed of several browsers, Opera 10.60 included. Obviously the conclusion was that Opera is the fastest (I wouldn’t link to that article from this post if it wasn’t the case, would I? :-P), and shortly after reading that, I came across this hilarious video that sort of follows up on that:

I mean, the video even mentions Opera Link, I have to like it :-P (although yeah, the claim is not correct, Chrome does have something similar). My favourite quotes are:

• “You promised innovation, but look at Opera!”
• “Maybe Opera is hiring”

And the second reminded me that yes, we are hiring!

But I hate not trying to be constructive, and just saying that it was disappointing for me won’t tell you much about the possibility of it being disappointing for you, so here we go:

• The choice of articles seemed “random”: clearly some of the authors had very good things to share, but many others didn’t sound that experienced or having so much interesting to say. I could imagine myself writing some of those articles.
• Many articles read like they want to give “general” advice, but extrapolating from circumstances that I may never have (like making a rule out of a “this happened to me once” kind of experience).
• I didn’t find it “inspiring” at all, if I wasn’t a project manager already I would not want to become one. The idea of working as a project manager felt dry, boring, and too focused on processes.
• Many articles feel written for someone that doesn’t have any project management experience whatsoever. That’s cool, but it’s useless for me and should have been clearer in the book I think.
• Many other articles seem written for project managers from other industries (or even simply “managers”) that are going to start managing a software project. That is not only plain useless to me, it also bores me to death. Seriously, WTF is with the definitions of super basic concepts? If you don’t know what an “iteration” or a “hack” is and you won’t check yourself out of curiosity you shouldn’t be allowed to manage a software project. Period.
• Many articles felt too “corporate” to me, there was too much jargon and too many references to job titles, methodologies and contractors instead of really essential stuff based on experience.
• Reading some of the more or less interesting stuff, I couldn’t help thinking that those things would be obvious for someone who has been working as a software developer for years and wants to become a project manager because she finds it interesting.
• Other articles were interesting, but lacked depth to make them really useful.

Don’t get me wrong, there are useful articles, but the book as a whole doesn’t feel that useful. Certainly not worth the time reading the whole thing.

And finally, something that kept popping in my head, even if the comparison is unfair (it’s a different kind of book), is that this book is in many respects the opposite of the things I loved about Making Things Happen (an excellent book that you should read if you have any interest in project management). Oh well.

But that meant I had to edit video. Which I had never done before. And I figured it wouldn’t be trivial if I only wanted to use Free Software tools under Linux. I was partly wrong, because after looking around a bit I found OpenShot, which I found pleasant enough to use (at least for my very basic, very limited needs). However, the final footage I used made OpenShot export corrupted videos. I know it was something specific to that source video (a MOV format, H.264 codec, EPICly HD resolution (1920×1080) video) because I had tried to do exactly the same things with earlier, lower-resolution, MPEG-format takes, and it had worked like a charm.

In any case, I was sort of fucked because I couldn’t get the final edited video out, so I had to resize it and change the format somehow. I won’t list here everything I tried (that includes trying to download and use several programs on Windows, as well as using mencoder on Linux), but after a very long and frustrating process, only ffmpeg did the trick for me. My first attempt with ffmpeg did export the video, but with awful quality. After looking around a bit, I found what worked for me:

ffmpeg -i original.mov -s hd720 -b 3200k resized.mpeg

The trick to get a decent result was forcing the bitrate (“-b” option), which will hopefully help someone in need. Meanwhile, I’m going to stop typing so I can go back to crossing my fingers to get picked for GTAC ;-)

My first impression is fairly good: even though it’s the first decent Android phone and quite old now, I find it very nice to use and quite customisable (which is great, considering all the applications and widgets available for the platform). And even when using an old version of Android (1.5) I don’t find it slow. At least not enough to be irritating.

However, there are several annoyances and things I found out that I figured I’d share:

• It doesn’t automatically import SMS from the SIM card, let alone use the SIM card as the SMS storage. I find that really silly, but to be honest it doesn’t bother me that much. You can of course import your backed-up SMS using some utilities (I haven’t bothered).
• It took me a good deal of effort to import my contacts from the old phone. I tried some app called vCardIO, which sounded awesome but it didn’t work for me. The final solution was using a utility called “Import Contacts” that doesn’t seem to be in the Android Market (?). I had exported my contacts using gammu/wammu, but I had just in case removed the X-GAMMU-* lines from it. I don’t know if it had anything to do.
• I found the default mail application to be kind of sucky, so I looked around and found K-9 Mail. I’m quite happy with it.
• The default browser is some sort of bad joke, but luckily there’s Opera Mini. Opera Mini 5 totally rocks, especially with Opera Link.

So I started to work on my own suite of tools for it, and recently I decided to release what I’ve done so far. It’s by no means complete, but it’s very useful for me and I thought it would be useful for others. And, with a bit of luck, someone will help me improving it.

So what is it? Arepa (it stands for “Apt REPository Assistant”, but obviously I called it like that after the yummy Venezuelan sandwiches) is a suite of tools that allow you to manage an APT repository. It contains two command-line tools and a web interface, and its main features are:

• Manages the whole process after a package arrives to the upload queue: from approving it to re-building from source to signing the final repository.
• It allows you to “approve” source packages uploaded to some “incoming” directory, via a web interface.
• It only accepts source packages, and those are re-compiled automatically in the configured autobuilders. It can even “cross-compile” for other distributions (treated like binNMUs).
• Far from reinventing (many) wheels, it integrates tools like reprepro, GPG, Rsync, debootstrap and sbuild so you don’t have to learn all about them.

The approval via some web interface was actually sort of the driving force for the project. One of my pet peeves was that there wasn’t an easy way to have an upload queue and easily approve/reject packages with the tools I knew. From what I had seen, the tools were either for “single person” repositories (no approval needed because the package author is the owner of the repository) or full-blown distribution-size tools like dak and such. My use-case, however, is the following:

• You have an installation of Arepa for an entire organisation (say, a whole company or a big department).
• People inside that organisation upload packages to the upload queue (possibly using dput; the point is, the end up in some directory in the machine hosting Arepa).
• Someone (or a small group of people) are the “masters” of the repository, and they’ll have access to the web interface. From time to time they check the web UI, and they’ll approve (or not) the incoming source packages.
• If they’re approved, the source will be added to the repository and it’ll be scheduled for compilation in the appropriate combination(s) of architectures and distributions.
• A cronjob compiles pending packages every hour; when the compilation is successful, they’re added to the repository.
• At this point, the repository hosted by the Arepa installation has the new packages, but you probably want to serve the repository from a different machine. If that’s the case, Arepa can sync the repository to your production machine with a simple command (“arepa sync”).

I imagine that a lot of people have the same need, so I uploaded all the code to CPAN (you can see it with the rest of the contributions by Opera Software). Sadly there’s a silly bug in the released code (I wanted to release ASAP to be able to focus on other things, and I ended up rushing the release), but it has both a workaround and a patch. So, please give it a try if you’re interested and tell me if you would like to contribute. I haven’t released the code in GitHub or similar yet, but I’ll probably do if there’s interest.

Maybe the testers in his team are doing too good of a job?

Because, you know, if testers are finding enough of “those bugs” (the ones that should be caught and controlled by unit tests and not by testers weeks after the code was originally written), maybe some developers are just not “feeling the pressure” and can’t really get that they should be writing tests for their code. If testers are very good, things just work out fine in the end… sort of. And of course, the problem here is the trailing “sort of”.
I know I’m biased, but in my view there is a ton of bugs that should never be seen by someone that is not the developer itself. Testers should deal with more complex, interesting, user-centred bugs. Non-trivial cases. Suboptimal UIs. Implementation disagreements between developers and stakeholders. That kind of thing. It’s simply a waste of time and resources that testers have to deal with silly, easy-to-avoid bugs on a daily basis. Not to mention that teams shouldn’t have to wait for days or weeks until they find basic bugs via exploratory testing. Or that a lot of those are much, much quicker to test with unit tests than having to create the whole fixture/environment for them to be found with exploratory testing.
My current conclusion is that pushing on the UI/usability side is not only good for the user, but it’s likely to produce better code as it will be, on average, more complex and will have to be better controlled by QA (code review, less ad-hoc design, …) and automated tests. Maybe developers will start hating me for that, but hopefully users will thank me.

So, what does the Dingoo have to offer? Well, it’s a nice and small portable gaming console that apart from games, it plays music, video and radio, and has a simple picture viewer and a basic plain text reader (with features like bookmarking). On the gaming side, it has its own game format (it comes loaded with around 30 games) and emulators for quite a bunch of different machines, so you can play games from NES, Super NES, Neo Geo, Mega Drive, Game Boy Advance, and the arcade machines CPS1 and CPS2. I don’t have words to say how awesome that is. The Dingoo has an internal memory of 4Gib and supports one external MiniSD card, so you have more than enough space for a lot of games, some music and even a couple of films.

In general, I have to say that both the emulation and the video playing works very well. A handful of games can’t be played (they crash or behave funny) and other games can be played but are too slow/annoying to play (e.g. Super Mario World for Super NES), but in general there aren’t any problems. I have a couple of minor complaints though:

• I find some of the button conventions confusing (e.g. for menu navigation). It doesn’t help that different consoles have different conventions on which buttons to use for which actions.
• The Mega Drive emulator doesn’t seem to support the .bin format, which is slightly annoying.
• There are a lot of video formats supported (the console comes with several sample videos), but the first video I tried to copy and watch wasn’t recognised :-( I hope that won’t happen often.

All in all, I think it’s a great console and it’s quite cheap, so I’m very happy I bought it. If you’re curious about how it looks and works, have a look at this video review:

• Software automated testing 123, an entry-level talk about software automated testing. Why you should be doing it (if you’re not already), some advice for test writing, some basic concepts and some basic examples (in Perl, but I trust it shouldn’t be too hard to follow even if you don’t know the language).
• Taming the Snake: Python unit tests, another entry-level talk, but this time about Python unit testing specifically. How to write xUnit style tests with unittest, some advice and conventions and some notes on how to use the excellent nosetests tool.
• Introduction to Debian packaging, divided in four sessions: Introduction, Packaging a simple app, Backporting software and Packaging tools.

Just a quick note about them: the slides shouldn’t be too hard to understand without me talking, but of course you’ll lose some stuff that is not written down, some twists, clarifications of what I mean exactly by different things and whatnot. In particular, the “They. don’t. make. sense. Don’t. write. them” stuff refers to tests that don’t have a reliable/controlled environment to run into. I feel really strong about them, so I wanted to dedicate a few more seconds to smashing the idea that they’re ok, hence the extra slides :-)

Enjoy them, and please send me any comments you have about them!

The PlayStation 2, well, it had all the games I wanted to play when I bought it (the Prince of Persia series, ProEvolution soccer, Ico, Shadow of the Colossus and God of War), it was cheaper than the alternatives and it had a ridiculous amount of second hand games and websites with reviews. The phone I bought mostly because of a recommendation, but actually I find other brands stupid and confusing, so I really like it and my next phone might be another Sony Ericsson. The PlayStation Portable… well, the DS is awesome in many ways, I realise that, but again the games I want to play (God of War, Patapon, LocoRoco, Echochrome, Katamari Damacy) are all for PSP.

There’s something similar with Apple. Some of their products (most? all?) look awesome, and I’m sure they’re awesome in many ways… but I can’t stand that they’re so closed in their own world. So far I haven’t bought anything from them, and when I read certain news I’m really happy that I haven’t. That’s more or less why it bothers me that the iPhone is so successful and that no vendor seemed to be able to do anything about it… until I saw the HTC Hero.

I haven’t used it myself (only played with it a bit and seen some videos), but it looks seriously good. According to these videos it’s still a bit rough around the edges compared to the iPhone, but it has more functionality, the same kind of app store (only open) and based on Android. I’m not sure what else I could ask for. Ah, yes: a couple of models more so they can polish it further :-) So I wonder if the Android platform, through HTC Hero and similar phones, will allow me and others to escape Sony (and Apple) on the phone arena.

Now, I only have to find some “open” portable console that will allow me to play PSP games ;-P

The long(er) story:

• I bought a laptop with that card, and I wanted to make it work.
• Apparently the open source driver (b43) doesn’t recognise my card, although it seems it should?
• I tried to download the proprietary driver provided by the vendor (wl), but it didn’t compile at first. After applying some patch for the kernel 2.6.29 (I’m using kernel 2.6.30) it did compile, but it didn’t quite work. Meaning, it locked up my machine seconds after loading.
• After a couple of days of wondering and trying to make it work… I realised the driver is already compiled in Debian (in particular, broadcom-sta-modules-2.6.30-1-686). Just installing and loading it worked like a charm. Oh well.