When I first worked as a contract web developer in the late 90s, the standard issue was PCs for developers, Macs for designers. That’s just how it was for most of my missions, with few exceptions. Personal preference? Bah! To the technical decision makers at the design agencies where I worked (IT departments), providing Macs at all was only a necessary expense to keep the designer prima donnas happy. There were probably other reasons, from developer tools, to network compatibility, but mostly I think it was down to cultural bias of IT departments and developers alike: an affinity to big-number specs. Speed. Capacity. Grrrr.

I had learned to code on a Mac, so although I missed BBEdit on the job, I grew to like Homesite and appreciate the various things I could do with Windows XP. They are just tools after all, and not to be blamed. By 2003 when I set up my own business, I had mostly given up, and kept my iBook for portability, but otherwise I was a PC shop (with a couple Linux servers under my desk). I worked a lot with a designer, and he had a Mac. Every now and then there were some issues with exchanging files and fonts, but mostly we got along fine between our arguments over the necessity for rounded corners and drop shadows.

How times have changed. These days Macbooks seem to be the preferred tool for developers (in the media and design world anyway). Go to any conference or hack day, and you will see fewer HPs or IBMs, and those that you do see are probably running some form of Linux anyway. Apple has provided a great platform for developers, and some great hardware. Good design has won the day, and things have turned around. Or come full circle…

The more Apple-shaped my environment, the more I am niggled by the increasing dependency on a single company’s (or single CEO’s) vision. Sure I have choice. I could, for the sake of diversity and freedom, give up my iPhone for an Android, or switch to Ubuntu Desktop for development. And buy an HP Touchpad (or not, anymore). But the more  software and apps I buy, the less likely I am to change. And anyway, I like my basket of Apples, they are solid, and I use them to great affect daily. But what if they end up a basket of eggs?

In this time of the surging tech wars going on between the major players, our privacy, identity, personal data and creative output as developers are potential pawns in a bigger game, and this question is more and more prevalent to me.

The answer, I think, is to make sure I am collecting tools, not eggs or apples. The real value lies in the open technologies and formats I choose to use to build websites and run my life.  Maybe one day I will be cursing the ubiquity of Ubuntu or some other flavour of openness, but at present, Apple provides the best balance  for me of openness, productivity and enjoyment. Some of these unfortunately require lock-in on a functional level, such as native apps. But where possible I will make sure I am investing in something that is open, portable and adaptable to any of  the changes that lie ahead.

Panic also creates Coda, a text editor for Mac, and Transmit – the only FTP client I have ever felt willing to part with some cash for.

The principles of Schedules, Work Based Structures, Resources, Effort, Duration… I understand.

But Microsoft Project… Baffles me every time. It seems to work against my logic. I’m stuck with it at work because I’m on Windows, the ‘real’ project managers in our team have fancy Macbooks with OmniPlan, which I can only imagine is more intuitive. I had given up on using it for anything other than a very bloated hierarchical list editor. Gantt charts, levelling, resource allocation, estimates and due dates were all not working the way I wanted. Until I read this in a series of articles at Tech Republic on MS Project:

Duration = Work/assignment Units

I’ve seen Abraham Lincoln’s quote, “If I had six hours to chop down a tree, I’d spend the first four hours sharpening the axe” used in the context of software programmers’ obsession with refining their tools instead of getting on with the job, but thinking about it, the tree metaphor doesn’t really apply, we’re not cutting down trees, we are building unique structures. The point is, choosing tools can be a distraction, and that remains true.

There is large overlap in features and capabilities across the available JavaScript libraries, and the good ones all perform as well as each other. In other words they can all do the job, so just choose one and get on with it. But despite their similar capabilities, they all work in different ways, so to jump from one to another has the friction of a change in direction or a new learning curve, which can only detract and add strain to the development process.

The only way you are going to get the most out of an open source code library is to use it, and learn about it. Use it some more and get to know it better. Use it a lot and know it backwards. A JavaScript library is not a drag and drop or copy and paste replacement for coding. It will not make up for your lack of ability or willingness to understand JavaScript programming paradigms.

If there’s any advice it’s make a choice and stick to it. You definitely need some help ironing out the differences between browsers and at least standardising your access to the DOM and Events. The light weight of most libraries’ core files make this worthwhile. The rest is subjective. Here are some of the issues I have encountered.

Administrative or Expressive?

For building the interface to a CMS or other application-type interface, that should follow well established interface design patterns, a good component or widget library is essential. You need your datagrid and tabs and layout and menus to look like they belong together. If this is part of your requirement, limit your selection to YUI, Dojo or ExtJS. Application developers and programmers from a more structured server-side background may feel more at home with these.

If your use is less administrative, and you are looking for a library to support a tactile and dynamic user experience, within the context of a branded or expressively designed site that doesn’t use standard UI widgets, consider MooTools or JQuery. The learning curve on these is not as steep, and implementation is often simpler. These libraries have more traction in visual design communities, and in my experience, visual designers who are willing to code, and client side web developers will be comfortable and familiar with these.

Open source?

Personality

And the winner is…