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.

The initial idea of the loanmeter widget was to show where in the world Kiva was offering loans. However, as I used the widget myself, I realised that the location in the world was less important for me, and I was more interested in knowing what the person was going to use the money for. So, I added some options to filter by “sector” and I figured that having some graphs comparing how much money was requested and already funded, for each sector, would be a very quick and visual way to get the information I wanted. I started playing with flot, and I have to say that except for a couple of relatively minor problems, it was quite easy to use. I don’t have screenshots showing the graphs, but feel free to try the widget itself and have a look (hint: you have two buttons at the bottom right corner to switch between “map view” and “graph view”).

The other widget I have been working on is a monitor widget for projects in CruiseControl.rb (a really simple and neat continuous integration server we use at Opera). More than one year ago, my colleague Nico had written a very quick & dirty widget for monitoring the result of the test runs of the My Opera functional testsuite. There were a couple of things I wanted to change, and I also wanted to monitor other projects, so I figured that I’d rewrite the widget to have a more maintainable codebase and then make it generic, so you could configure which CC.rb installation and which project to monitor. I’m moderately happy with the result of the refactoring, and happy enough with the final result. I know it has several issues, and I expect that once anyone outside our team starts using it, there will be things to improve and fix :-) If you use CruiseControl.rb, give it a try!

• It does have a (lame) name now: Bubug (supposedly stands for “Barely Unconventional Bug Untracking Gizmo”. Whatever).
• It has improved a lot here and there, and it now has authentication and multi-user support, not to mention a lot of UI bling bling and goodies.
• The development has moved to BitBucket, an excellent free service built by ex-Opera’s Jesper Noehr, where you can follow it more easily, comment on, check the Wiki, fork, or whatever you want. You even have a screenshot there ;-)

As you can guess from the last point, for this project I’ve been using Mercurial instead of Git. Although I certainly don’t have sophisticated needs, so YMMV (heavily), I find Git more pleasant to use. Which is kind of surprising, because I always thought that Git’s UI was a pain in the ass. Oh, well. That doesn’t mean that Mercurial is hard to use, though. I think it’s more that I’m used to Git now, and there are a couple of things that I find more convenient: the coloured diff (possible in Hg, but you have to install some extension for it, and only thinking about installing some Python extension that is not even packaged for Debian makes me want to switch to Git) and the staging area are the most important ones I can think of.

So, if you thought I had abandoned the TODO application thing, you were wrong ;-) If you’re interested, have a look at the Bubug BitBucket project page, download it, play with it, and tell me what you think.

The point now is that, while working on it, I needed some module to parse command-line options and “subcommands” (like git commit, svn update, etc.). As it’s written in Perl, I had a look at CPAN to see if I could see anything. The most promising module was App::Rad, but it lacked a couple of things that were very important for me: my idea was “declaring” all the possible commands and options and have the module do all the work for me (generating the help pages and the default --help implementation, generate the program help subcommand and so on). App::Rad didn’t have that, and it didn’t seem to me like that was the direction they wanted to go to with the module. But I figured I’d drop the author an e-mail anyway and see if he liked the idea so I could start adding support for all that…

And boy was that a good idea. He replied a couple of days later, and said that they had liked the idea so much that they had implemented it already (that’s why he took a couple of days to reply), and he sent me an example of the new syntax they had introduced and asked if that was what I was thinking. And not only that, but they added me to the list of contributors just for giving the idea! That completely made my day, free software rocks!

1. Possibility to “postpone” a task, so it doesn’t appear in the main view for a defined time.
2. Possibility to associate a task to a “person to nag”.

When you have a lot of small tasks to do, and they are not the kind of things you put in a BTS (say, stuff that you have to do that is not really connected to some project’s code) I think these two features are really useful, and I was surprised that no applications I saw seemed to have those. I mean, don’t people have the same problems as me?

That’s why, as I had mentioned, I started writing my own TODO application: I’d have what I wanted, and I’d learn a thing or two about Merb, DataMapper and jQuery. The application has several design limitations that I used to simplify things, like not having any notion of users (single user app without authentication) or supporting only a “title” for the tasks, without any longer description. It isn’t something I really plan to publish for other people to use (I mean, the code is in my Darcs repo, I’m just not going to make a project page for it or anything like that), so I don’t really care how much it fits other people’s needs :-)

As it is a pet project and I didn’t really mind how long it would take to finish it, I started by making some mockup of the application in HTML (+ a bit of Javascript with jQuery), and once I was happy, I started with the actual design and code. I think some parts of the code are nice, and it has some Ajax sweetness, but I admit I haven’t used it yet for myself: only as a kind of underpowered BTS for the application. Maybe I’ll upload some screenshot some day. In the meantime, feel free to download and try it out ;-)