Perfectly Normal Blag

This is a continuation of the story of Flexo.

Shortly after writing the last post, I lost interest, and abandoned work on Flexo. I have now revived it, and also published it on GitHub, as all cool Ruby-developers do. (this one can be found under “PerfectlyNormal/Flexo:http://github.com/PerfectlyNormal/flexo.)

The big changes since last time is that the plugins actually work now. Also fixed up some missing require’s that seemed to get included automatically on the Linux-box, but not on the Mac.

So it’s now possible, although a bit clumsy, to install Flexo and get it up and running. The rest of the work will be to write plugins allowing it to actually do anything. And to do that, documentation is useful. Meaning I should get the website up and running, and add some more comments on the inner workings on Flexo so it’s possible to create a RDoc that actually does anything.

And maybe create and publish a gem.

Not Invented Here is a way of life for most of my projects. Most, if not all, could easily be solved by finding some already existing product, and, if neccessary, tweaking it. Instead, I choose to create my own solution. Which usually ends up buggy, unmaintained, and I lose interest before moving on.

This time, I was thinking about my semi-working DVD ripper currently without a name. It was going to help me rip all my dvds into H264, to be stored on the fileserver, where I could access them all instantly. And then my interest died…

My previous version was pretty much complete. Only thing missing was a way to convert subtitles from vobsubs to a normal, sane format without having to start a Windows-box and run SubRip. Had a look around again, and found gpgm2srt. Downloaded and tested it, and it actually works.

But of course, it’s not perfect. And that’s why I’ve taken it upon myself to improve it. First, I’m planning on translating the entire thing to Ruby. Then, stuff it into my own project ruby-subtitles, rip out the GUI and replace it with Qt. When that is done, I’ll most likely be sick of it, and not do any more, but the plan was to then improve things a bit, and then finish up my ripper, making them work together for great justice.

Been ages since I last posted anything here. Just kind of lost interest, and got busy with other projects (as it usually is).

One of the things I’ve been working on, is ruby-matroska. A gem designed primarily for working with ordered chapters in matroska files.

The reason I started was that my media player of choice, mplayer, currently doesn’t support ordered chapters and all that nifty goodness. And since my anime is slowly adapting it, and that we decided to use it for our Death Note releases, actually being able to use it was kind of important.

ruby-matroska consists of two binaries, of which only one is complete.

• playlist takes a Matroska-file as an argument, analyzes it, and creates a mplayer compatible playlist, or launches mplayer with the right files.

• unorder, which is incomplete, takes a directory with ordered chapters, analyzes and creates self-contained matroska files, containing all the linked chapters in a file of their own. I can’t see myself actually using the last one, but since I’m releasing this gem upon the world, I thought it would be a nice feature to have.

It’s also open source, and the source is available through my github repository. Also got a bugtracker over on Lighthouse, but since I’m using the free version, I’m not really sure if it’s accessible for others.

I’m currently relying on the user having mkvtoolnix installed, but in the future, I would like to extend this project to also include a Matroska-parser. This would not only make it do it’s thing a lot slower, but also be a fun lesson in implementing others formats.

Besides from removing dependencies, and making sure my SUIDCache-class is needed, I’m not really sure what practical use this library could have. And since I’m unable to find a completed EBML or matroska-library written for Ruby, I’m guessing not many others have seen a need either. (Or my Google-fu is just getting weaker)

Flexo is, in addition to being a character in Futurama, an IRC bot hacked together by me. (He’s also the first image to be featured in this blag).

Written in Ruby, and very much based on Flux. In fact, some 80% of the code is probably identical. The difference between Flexo and Flux is that Flux was written as a framework for creating IRC bots, while Flexo is written to be a single, stand-alone, extensible bot.

The base of Flexo is pretty much complete. Only problem is, the bot is pretty much useless as well. Right now it can connect to IRC, join channels, and idle. That’s all it’s supposed to do. The rest will be done using plugins.

Working slowly on a plugin for adding restricted triggers to Flexo, which will use a small database for storing users and their access levels. The restricted commands will in turn let me write a plugin for controlling Flexo directly through IRC. Additionally, I was planning on making a DBus plugin as well, so that outside scripts can interface with a Flexo-instance easily.

After those plugins are done, it’s finally time for my master plan. The main reason why Flexo was born. A svn notifier. I want it to inform a channel each time a commit to one of my svn repositories is made, with some basic information about it. I don’t want everything to be public, so something like CIA is out of the question. Plus, writing my own is much more fun.

When it’s done, it might even get released out into the wild. That’s how much I like it.

iEye: Coming soon to a desktop near you!

At least that’s what I would like to say. I’ve had it on my mind the entire day, and now I’m all ready to start working again. There’s always that slight hope that this time will be the one time I actually make it work.

I’ve been thinking a lot about it, and I think I might want to try making this version of iEye into a regular desktop application. The web-interface would still be there, but not as the only choice.

What I’m thinking about, would be similar to how Opera deals with bookmark syncronization, Opera Link. The application would run on as many machines as the user wanted, and with a single username/password (or something similar), also get access to a central server, where everything could be stored securely, for retrieval, backup and syncronization with multiple machines. Of course, for the privacy freaks, it would also be possible to run iEye without this feature.

Moving to the desktop would make a lot of things easier, such as automated fetching of covers, and integration with barcode scanners, for one thing. Additionally, it would let me have something to work on as I explore how programming for the desktop works. Which is my main goal in this planned rewrite.

iEye has served its purpose as a technology experiment pretty well. I’ve lost count of how many rewrites it has been, but there’s been a few. (Very few of them were in a working state before they were scrapped). First, in ASP, then some spaghetti-code PHP, a little cleaner object-oriented PHP, then some neat MVC PHP and lastly, Ruby on Rails (which never was finished, or anything remotely like it.)

Now I hope to use Ruby with Qt. Additionally, storage would be done using SQLite, as a database would be very well suited, and SQLite is small and lovely. Plus it doesn’t require a database server.

Finally, when all this is done and working correctly, I plan to add a web-interface to the iEyeLink-thingy, so that it can be used remotely without having to install anything as well. For that, I hope to try out Ramaze, which seems pretty interesting.

Right now I got it all in my head. Everything. Exactly how I want it to look when it’s done. I think I’ll have to try and draw some scetches. Really psyched about this now!

…and then reality, in the shape of gorken, strikes. He kindly reminded me that I don’t have time for this now. I have another project I should focus on. And at the same time, there’s also that pesky school that demands attention and work. Wish I was free.