Sanitize dates in podcast title with groovy + jid3lib

When I sort the podcasts I download by their ID3 titles, I want to see an older episode sorted after a newer episode.

Here is a groovy script that modifies the MP3 title of an MP3 file passed as first parameter of the script, and replaces any dd.mm.20yy date by a 20yy.mm.dd date. It also moves the date at the beginning of the title.

You need the Java ID3 Tag Library (jid3lib) and an embeddable Groovy (groovy-all.jar)

Now in order to run the script after each download, your podcast receiver must be able to run a custom command after each download. You can use Juice.

So here is a quick and dirty script sanitize_dates.groovy :

<br />import org.farng.mp3.*<br /><br />TagOptionSingleton.getInstance().setOriginalSavedAfterAdjustingID3v2Padding(false)<br /><br />def readMp3Title(filepath) {<br /> def mp3file = new MP3File(filepath) <br /> mp3file.getID3v2Tag().getSongTitle()<br />}<br /><br />def writeMp3Title(filepath,title) {<br /> def mp3file = new MP3File(filepath) <br /> mp3file.getID3v2Tag().setSongTitle(title)<br /> mp3file.save()<br />}<br /><br />def sanitizeTitle(title,action) {<br /> def m = (title =~ /^(.*)([0-9][0-9])\.([0-9][0-9])\.(20[0-9][0-9])(.*)$/)<br /> if(m){<br /> def g = m[0]<br /> action("" + g[4] + "." + g[3] + "." + g[2] + " " + g[1] + g[5])<br /> }<br />}<br /><br /><br />def filepath = args[0]<br />def title = readMp3Title(filepath)<br /><br />println "Original title:${title}"<br />sanitizeTitle(title) { sanitizedTitle -><br /> writeMp3Title(filepath,sanitizedTitle)<br /> println "Title after sanitization:${readMp3Title(filepath)}"<br />}<br /><br /><br />

In the preferences of Juice you can use Run this command after each download with for exemple :

<br />/usr/bin/java -cp /home/me/javalibs/groovy-all.jar:/home/me/javalibs/jid3lib.jar groovy.lang.GroovyShell /home/me/bin/sanitize_dates.groovy "%f"<br />

MTP Mp3 players and Asus eee

Works like a charm :

Open a console : CTRL+ALT+T then
sudo apt-get install libmtp libnjb gnomad2
./gnomad2

Does not work with Amarok though, as the MTP support does not seem to be compiled in the version provided with the eee.

MTP devices, udev and permissions in Ubuntu Dapper

I had to install Gnomad2 in Ubuntu Dapper in order to upload files to my MTP Mp3 player.

I followed this great How To

However Gnomad2 could not open the device unless I was root (same thing for mtp-detect)

It looked like a permission problem in /dev/bus/usb

This worked for me :

In /etc/udev/rules.d/40-permissions.rules I changed

# USB devices (usbfs replacement)
SUBSYSTEM=="usb_device", MODE="0664"
to

# USB devices (usbfs replacement)
SUBSYSTEM=="usb_device", MODE="0664", GROUP="plugdev"

Then

sudo /etc/init.d/udev restart

Closure, Functors, Command Pattern

Closure, Functors, Command Pattern: rougly the same thing

TDD : Can Shared Fixture test unexpected statefulness ?

When praticing TDD, the impact of the different types of fixture that can be used to setup the tests must be known in order to avoid to create Obscure Tests

The usual default fixture type is the Fresh Fixture

When the fresh fixture takes too much time a Shared Fixture can be used. Now, that being said, the shared fixture should usually be avoided (there's a risk of Erratic Test)

A few days ago, during a discussion about test fixture, some colleagues of mine and I were wondering if shared fixture could be used in order to test the statelessness of the objects used in the fixture as a side effect of the sharing.

Here is the initial reasoning : when an object is supposed to be stateless, but is buggy and not actually stateless , the use of this object will lead to some failing test, since the state left by some tests will make some subsequent tests fail. The statelessness is tested "for free" with a lot of different combination. Actually, if the object happens to be stateful it is a case of Interacting Tests and the reason why some tests fail could be quite hard to find.

I must admit that it may help to find some obscure statefulness interaction, but I do not really like this idea :

• I fear Interacting Tests far more than a single bug, as Interacting Tests in a test suite is hell on earth,
• A test is supposed to have One Assertion Per Test. Or, at most a few assertions. In this case, the statefulness test is spread in the whole test class.

Actually, the statefulness should be tested in its own test. Of course it means that only a few method call combination will be tested but it should be enough to prove the statelessness (or else it means that the code of the class under test must be refactored in order to make the stalessness explicit in the code structure)

To try to use the side effect of the shared fixture to test statelessness may seem to be worthwhile at first, but it creates Technical Debt. And in this case I think that the financial interest of the debt is pretty high.

Albert Einstein quote

“Insanity: doing the same thing over and over again and expecting different results.”Albert Einstein

Closely related to the quotation in the header of this blog

90s geek flashback

Wooow...Internet still surprising me.

(Just skip this post if terms Atari ST + Demo do no ring a bell)

I never imagined I would have the opportunity to listen to this track again : the Union Demo main menu.