Pragmattica

January 17, 2008

Convert iTunes M4A files to MP3 on Linux

Filed under: Linux — bnsmith @ 3:00 am

And Keep Some of the Tags!

Update: I have just finished creating a GUI front-end for the conversion program described below. This new program can be installed easily through a package and should be easier to use, so I suggest you follow this link and try the directions there first.

I love iTunes. It was the first web retailer to sell music from the major labels with no DRM. On the night that iTunes Plus first became available, I stayed up late, trying to find some albums that I wanted, just because I wanted to see the folks at iTunes and EMI rewarded monetarily, and wanted to do my bit. Of course, iTunes Plus music comes in non-DRM-encumbered M4A format, which doesn’t play on many portable MP3 players, and doesn’t play very well on others.

There are plenty of posts describing how to convert M4A files to MP3, but most of them completely ignore the information about the artist, album, and so on embedded in the file as tags. I don’t know about you, but I think tags are important. I don’t want to sift through 500 tracks named “unknown” on my MP3 player.

The program that I’ve created will convert a directory full of M4A files to MP3, preserving the artist, album, song name and track number tags. Hopefully this should be enough to play a whole album, in its proper order, with no confusion.

These instructions are specifically for Ubuntu 7.10, but should work on other distros with some modifications.

The first step is to install some required libraries. Open a terminal and type:

 sudo apt-get install id3v2 mplayer lame python-mutagen

Next download my program here, and extract it. Suppose that your iTunes music is in “/home/youruser/itunes”. In your terminal, go to the directory where you extracted the program and enter this command:

./ConvertToMP3.py /home/youruser/itunes

The original files will be left untouched, and new MP3s should be put into a new directory called “/home/youruser/itunes_mp3”. If you have any problems, don’t feel bad about leaving a comment asking for help. In fact, even if you don’t need help, maybe you could just leave a comment anyway. It would be the first comment I’ve ever gotten. 😉

January 15, 2008

My First Scheme Program

Filed under: Scheme — bnsmith @ 4:15 am

Today, I am releasing my first (more or less) working Scheme program. I’m still only learning Scheme, so my work is not very sophisticated, but I hope this is just the beginning.

I named the program “Conversation Tree Writer.” It’s purpose is to allow someone to more easily write the “conversation trees” that are commonly used to express the plot in role-playing games (RPGs). Once the conversation trees have been written, the program then allows the user to step through the conversations and see if they work as intended.

If I understand correctly, my program implements a domain specific language (DSL) for expressing conversation trees. I implemented it with the ‘define-macro’ syntax, because it is a little easier for novices to pick up.

As you’ve probably guessed, the primary reason that I chose to write this program was as a learning exercise. However, I still hope that it might become useful to someone after a few more revisions. Someone working on a video game would probably find it very difficult to write these trees in a standard word processor. It would become something like a choose-your-own adventure book; adding a page would mean having to manually update all of the instructions for what page to turn to next.

Presumably, commercial game developers have some internal tools to ease this process, but I was not able to find any such open-source programs.

I’m currently distributing the source-code only, so you will need to install Gambit Scheme and SLIB to run it. See Getting Started with Scheme on Ubuntu Part 1 and Part 2 for instructions. After Scheme is set up, download the source code here, open a terminal, move to the directory where you extracted the source code and run this command:

./ctw.scm secure.ctw

You can then choose between the available options by entering a number.

January 1, 2008

Five Management Strategies to Hire and Retain Great Programmers

Filed under: Programming Professionally — bnsmith @ 3:55 am

And they won’t cost you a dime…

DISCLAIMER: I’m still an underling, and so I haven’t actually had the opportunity to put these ideas into practice. I base my theories on experiences that I’ve had working on various teams over the course of my career, and how these experiences affected my own decisions. Although I’m convinced that the ideas are sound, I can’t offer any proof. Use at your own risk!

1.) Cultivate a Casual Work Environment

I love throwing on jeans and a T-shirt in the morning. It’s not just the convenience though; it’s all part of the uber-geek ego-trip. If you try to make developers wear shirt-and-tie to sit in their cubicle and code, don’t expect to retain anyone besides those that aren’t good enough to get hired anywhere else.

This assertion probably seems a tad extreme, given that all we’re talking about is a useless flap of cloth wrapped around the neck. Still, I think of it this way: managers who enforce a dress code are forcing needless, arbitrary complexity on their developers. Dressing up in a special costume doesn’t make developers more productive or NP-complete problems less difficult. So what’s the point? Even worse, managers who make bad decisions about clothing are equally likely to make bad decisions about technology and architecture, and these decisions would be vastly more painful to a great programmer.

The only possible exception that I can see to this rule would be for organizations with fat, bloated, governmental bureaucracies that force the dress code, but also incredibly cool technologies that a geek can’t play with anywhere else. I think that the best example of this would be NASA. Of course, once commercial space companies really start to take off, this situation won’t last for long.

2.) Let Your Developers Choose Their Tools

Have you just read the most fascinating article/advertisement in your favorite management magazine about the amazing new integrated version control system that will double the productivity of any developer? Stop right there. If you haven’t committed any changes in the last six months, then you are not in a position to make an informed decision. Try to realize this fact, and listen to what your developers tell you.

This doesn’t only apply to version control. The more control that you give your developers, the better.

If you’re hiring Java programmers, then let them develop on a Linux or BSD box instead of Windows, if that’s what they want. Java is multi-platform anyway, right? You might have to tell them to test on Windows extensively, if that’s your primary market, but your programmers would still be grateful to be able to work on the desktop OS of their choice. Perhaps the IT department might not like it, but are you going to let them stop you from building a first rate development team and thus creating fabulously successful software? This important benefit will help you attract and keep more talented programmers than you might otherwise get, and it costs nothing.

3.) Allow Your Developers to Connect with your Clients

I bet this is another controversial suggestion. Do you really want your shabbily-dressed (see point #1), Unix-hippie (see point #2) developers to be talking to your valued clients?

I would say yes.

Think of it like this. Your developers are smart people, and as long as you express your needs, you should be able to trust them to behave properly. If the customer has a particular dress-code, tell your developers what it is, and tell them that they will need to follow it in order to go there. In this case, it isn’t an arbitrary decision. You don’t have any control over your client’s rules, and so your developers won’t resent it.

But would developers actually want to see the clients? I think that most would, as long as you are careful not to take it too far, and make your developers feel like they are first-line tech support. Developers appreciate being able to see how real-life customers use the software, and how it helps to make their lives easier. If you have some people working for you who have never once seen a client-site, spare them a thought and ask them if they would like to tag along and see the sights. If you’re going to be driving over there anyway, why not? This is especially important if the client-site is something that a geek might find interesting.

4.) Offer Benefits Like Flex-Hours and Telecommuting

I don’t use an alarm clock. I wake up in the morning, generally about 8:00 am, roll out of bed, get dressed and go to work. But if I wake up at 8:30 or 9:00, I don’t have to worry about it. Nobody is keeping track of exactly the hours I work, as long as I get things done. If I was forced awake at 7:00 am every morning, I’d probably be an unproductive, coffee-chugging zombie for the first couple hours of each day. Is that really a worthwhile price to pay to maintain the same nice, rigid schedule for everyone?

Why even show up at all? If there are no meetings scheduled and a lot of solitary development to be done, there’s no reason that a developer can’t be equally productive from home. And of course, nothing makes me appreciate telecommuting like waiting at home for the FedEx guy to deliver a new tech toy.

Also keep in mind that telecommuting shouldn’t cost anything to implement — at least for programmers. If we were talking about marketing or sales people, then you would need to buy an expensive VPN appliance to give them access, but for any programmer worth their salt, all they should need is SSH. A little port forwarding magic is all it takes.

5.) Promote Ceaseless Learning and Discovery

Next Monday morning, as your developers arrive at work, hand them each an envelope containing a first-class ticket to Chicago and vouchers for a penthouse suite at the Drake Hotel so that they can attend PyCon 2008. Oh, wait… I promised that these strategies wouldn’t cost you a dime, didn’t I? Well, in that case, try this on for size.

Ask your developers what technologies they’re interested in. Ask them what they’re learning about in their spare time. Ask them how the technological landscape will shift in the next five years. Listen to their answers, and suggest that they each plan a short seminar on their favorite subject, so that they can share it with everyone. Friday lunch is an ideal time for such an activity. If you decide that you might be willing to part with a few dimes for this exercise, then perhaps you could even offer to order pizza for your crew. Who knows? You might even learn something.

Conclusion

Offering a high salary is a good start for finding top talent, but you will eventually run up against the law of diminishing returns. An extra thousand dollars added to the salary likely won’t be as big of a draw as a thousand dollars of well-thought-out perks. And when it comes right down to it, sometimes the best perks in life are free.

Create a free website or blog at WordPress.com.