improvement – Jam and Bees

Ellen Allien — Sehnsucht

Such a brilliant song.

The world’s moving by slowly, quietly. I’ve been spending my spare time mostly reading:

introducing html5, part of a series which, the publisher assures, is written by “voices that matter”. Quite what that means, I don’t know, but it’s a surprisingly fun book to wander through.
Beginning Visual C++ 2010. Visual Studio is a big mammoth of a tool, C++ is a big mammoth of a language. Together at last, I guess: seems like every page has a dozhundred things to remember, and I’m not even out of the chapters that are mostly concerned with the grammar and structures of C yet. Bloody ‘ell.
Javascript and Ajax, a part of the Visual Quickstart series of books. Surprisingly accessible, even downright funny at times. What’s with teh current trend of writing programming books that tickle you pink?

Still, my hope is that one day I’ll be some kind of lean, mean fighting machine on the web and desktop. Just give me ten years, I’ll get there. In the meantime: longing.

Windows developin’

I started life as a die hard linux developer. That was all I wanted to do, and all that really made sense to me. I enjoyed looking into, calling and using various odd APIs, I love the idea of writing a little C and bob’s-your-uncle-you’ve-got-a-driver. I’ve never actually written a linux driver, though, and as such I just bought a linux device drivers book so I can get on that.

In either case, I think there’s some odd difference between linux and Windows development that I’m finding it hard to put my finger on. It seems, though, like there’s more general knowledge inside the linux camp: the languages themselves are known, rather than just the MS libraries. The kernel is studied and understood to have an exposed API, the compilation toolchain is something you’re encouraged to understand instead of just pressing build and now it’s done. And I think I’m better off for having an idea of what the individual steps that are taking place whenever I request magic from an IDE are.

However, the IDE front is really interesting. There’s something nice about a tool like visual studio, which is giving me a lot of hand-holding, rather than sitting down in front of gEdit, or Emacs or vi and being stuck with, well, with working out how the hell everything else happens. It’s a bit of a pain the first few times and visual studio takes a lot of that pain and hides it away.

Mac OS has a great IDE, too, in XCode. Interface builder could use a touch of work, and it looks like XCode 4 addresses a lot of my complaints against XCode as a whole, but it’s overall pretty neat. And the documentation, oh the documentation.

One place where the proprietary folks tend to whip the open source folks is the documentation. Now, that’s not universally true: OpenBSD has very, very high quality documentation indeed, the GNU toolchain is exhaustively documented (though documented exhaustively and documented well are two different things), but by and large the smaller stuff isn’t nearly as good. Except in the perl community, where everything on CPAN is normally really outstandingly well documented.

Something I’ve been really taking to heart, and which my colleagues at work are really pushing for, over the last six months is the idea that if I’m going to write code then everything in it has to be highest quality, no exceptions. It’s one thing to write a tracer bullet, to take an example from The Pragmatic Programmer, it’s another to then leave the tracer bullet in the system and never improve it. And if you’ve not written a high quality tracer in the first place, well, just remember that nothing’s quite as permanent as a temporary solution.

Sharing one iTunes library amongst multiple users on Mac OS X

Last night, I set up iTunes so that it uses one library for all my accounts on my mac, and figured to do a little writeup.

Let’s say you have an account, jam, and want it to use the iTunes library from the account bees. I assume you’ve already got bees’ iTunes stuff set up how you like.

There are two key insights:
a) both accounts are, by default, part of the staff group
b) your iTunes library is, at its heart, just a folder on the file system

In jam:

1. Open a console
2. cd ~/Music
3. remove the iTunes folder and ln -s ~bees/Music/iTunes .

That’s the initial, basic setup done. If you open iTunes, though, you’ll find that you can’t write to anything from the jam account, so you can’t actually do useful things, like opening iTunes.

However! From the jam account, open a Terminal and:

su - bees

Now, in the bees terminal:
cd ~/Music/iTunes ls -l
Now, the owner of each file is bees:staff, right? And bees has the correct permission for writing everywhere, right? So, use chmod to replicate the user permissions to the group permissions for every folder, and for your library files and whatnot:


-rwxrwx---@  1 bees  staff    806136  1 Aug  2008 Temp File.tmp

-rw-rw-r--@  1 bees  staff   4628440 17 Oct 08:32 iTunes Library

-rw-rw-r--   1 bees  staff   1122304 17 Oct 08:31 iTunes Library Extras.itdb

-rw-rw-r--   1 bees  staff  83341312 13 Oct 15:50 iTunes Library Genius.itdb

drwxrwx---  69 bees  staff      2346 16 Oct 12:17 iTunes Music/

-rwxrwxr-x@  1 bees  staff  22701215 16 Oct 13:22 iTunes Music Library.xml

-rwxrwx---@  1 bees  staff         8 17 Oct 08:31 sentinel

Now, cd iTunes\ Music/ and do the same trick here, then cd into Music and Podcasts and those guys and do the same trick there.

Of course, it’s directories which need their permissions changing, not files, so if you want to you can always find ./ -type d -exec chmod 775 {} \; from the iTunes directory if you want to be quick about the majority of this. After that, go find the files which need their permissions changing too, like the iTunes library xml file, and you’re rockin’ and rollin’.

Trying to Improve

I’ve been writing a lot of perl recently, and had a few solid insights into what it means to program better than a beginner. Not like a professional, but not like a beginner.

Writing to the interface has been huge to me. Writing to the interface, not changing the interface.

Slowly working out how to keep my functions free of side effects is another. Incredibly hard to do, it’s taken me years to grok what it means for a function to have a side effect and to discipline myself to write side effect free code. I’m not great at it, but I’m better than okay.

A really interesting way to learn about side effect free code is to start writing ruby. The ruby community really encourages tons of small methods on an object, and that starts training your intuition to understand how to make one method do only one thing, and chain things together.

I have so much improvement to do, though. I don’t feel like I really understand perl or ruby or C or Objective C at all. C, I’m getting closer with: understanding how pointers and the address of operator work was crucial, as was getting a mental image of what a type is in C (think of it as a way of indicating how much memory something needs).

On another topic, Uncle Bob’s been giving some really interesting talks recently about what the new programming paradigm might include, what direction programming should be taking. His recent interview on the pragmatic programmer’s podcast is well worth checking out.