Computer Science vs Software Engineering

This article entitled Software Engineering, Not Computer Science (PDF), is probably the clearest definition of the difference between the two fields that I have seen to date. It also provides very interesting food for thought because many yearn to do computer science, yet most of us are employed doing software engineering.

In a way, it is a pity that there are not more computer science jobs available. I have encountered a few really smart people who love the discipline and would no doubt advance the field of computer science if they were given the chance. They just made absolutely horrible software engineers as they were not really interested in producing products. They were only interested in creating new things, no matter how unrelated or inapplicable to their task at hand.

The Paranoid Programmer: From Junior to Mid

While chatting with a fellow developer, the question was asked: "How does one go about raising one's skills?" The answer to this sort of question is different for every person - every person has different talents and weaknesses and develops in different ways. At this moment in time, looking at the current Exoweb team, there are a few areas that I would particularly emphasize:

• Paranoia
• Mapper vs Packer
• Quality Plateau
• Knowledge Portfolio Investing

This particular entry is written mostly for Exoweb developers, but any feedback, comments or suggestions are welcome. Update 2006-01-15: Changed the title. Besides the fact that I've previously written something on what makes a senior, what I've written here will only get someone up to a mid level developer in Exoweb. There are a lot more things I left out on what makes a senior, like the soft skills.

Paranoia

Paranoia is good in a developer. Or perhaps some would prefer to refer to it as boundary checking. At any rate, it is always good for a developer to consider that Murphy's Law (anything that can go wrong, _will_ go wrong) is something we encounter far too often in our daily life. Once code is written and being inspected for improvements (you do go through your code again and see if you can improve it, right?), it helps a lot if the developer considers what can go wrong and how one can safeguard one's code against this.

As an example, one area that developers typically forget in web programming is url encoding. For instance, some insert usernames into the url as a variable. e.g. /user/john/details or /user_details?username=john. However, they forget that usernames can often include characters that are not legal in urls, such as spaces, &, ? or others. Worse, they may not even be ascii. In our global environment, it is no longer uncommon to encounter a lot of unicode characters. This of course leads to much pain later. Competent developers learn the first time they make this mistake and never repeat it. The superstars never make this mistake in the first place.

Paranoia can only go so far - you will miss something. Fortunately, that's what code reviews, pair programming, even more paranoid seniors and users^H^H^H^H^H beta testers are for - helping you catch your errors. But it helps the user experience (and your career) a lot if you catch as many of the bugs as possible before anyone else sees them.

Mapper vs Packer

The terminology comes from the Programmer's Stone, and it refers to a mindset. Are you a memorizer (pack information into your brain) or one who figures out the fundamental principles (maps connections between data points)? Packers have a tough time making senior in Exoweb because seniors are the ones that handle the most unusual, newest problems. For that, a packer has to find and pack the appropriate response. That can be rather hard to do. Instead, we need people who are adaptable to new situations and can figure out solutions to problems. Nothing is more annoying than a person constantly bombarding you with questions that could easily be answered with a little thought.

The Quality Plateau

Yet another term from the Programmer's Stone, this time in Day 2 of the website (I consider the first two days the most valuable). I wish they had a HTML tag to that particular section so I could link directly to it, instead of telling people to search for the heading. At any rate, that site shows how even code that is considered well written can be improved and made more readable. You may or may not agree with the style or the different methods used, but it is an eye opening experience - 26 lines of code reduced to 11 much more readable lines of code.

The Quality Plateau is not about reducing unnecessary variables, cramming things into as small a space as possible or holy wars about coding conventions. It is primarily about looking at your code and constantly finding ways to improve it. This mindset may seem expensive at first as you spend time looking over already functional code, but the long run benefits are enormous. Each time you see a way to improve your code, you learn something new for the next bit of code you write. Over time, you get better and better and start producing top notch code without much effort.

Knowledge Portfolio Investing

If the Quality Plateau is about constantly improving your code, then Knowledge Portfolio Investing is about improving yourself. This particular phrase comes from The Pragmatic Programmer, a book I highly recommend. As knowledge workers whose tools are only our intelligence and a computer, our greatest value lies in what is in our heads. If we do not constantly invest in increasing that asset, we will one day find ourselves penniless in our job - we will not have the value left to justify the high salaries that we believe we deserve.

It is hard to take time out to invest in ourselves, to learn something new every day. Work is tiring, our personal lives often seem more interesting and something always seems to come up. But none of us would have gotten this far if we hadn't invested time and effort in improving ourselves. No one in Exoweb has ever studied only the bare minimum required of them in school. Work should be no exception.

This is one of the reasons why Exoweb allocates 10% of work hours to employee improvement and tries to minimize overtime - to give every one of our developers time to continue developing themselves. This is a win-win situation for all parties involved as Exoweb's time and resource investment results in more competent and skilled developers. However, this all depends on the developers actually taking advantage of this time.

Final Thoughts

There are plenty of other things and more will be added over time as the situation change and other needs become more obvious. Of all of the above, the area that is ultimately most important is #4 - Knowledge Portfolio Investment. In the end, if a person is constantly trying to develop themselves, they will learn all the other areas.

The future, our industry and our targets are always moving. We can never be satisfied with hitting all the goals we set today, because by the time we hit them, needs will have changed and new goals are needed. However, if we are at least moving in the right direction, there will be a much shorter distance to travel to the new target after we hit the old one.

Public Key Missing in Apt

Just a quick blog about some key wierdness in the debian testing apt-get setup. Not sure where the exact problem stems from, but since the new year started, all debian updates are signed with the 2006 gpg key, which my testing systems did not seem to have. So you would end up with this error after doing an update:

Get:1 http://box.exoweb.net testing Release.gpg [378B]
...
Fetched 2810kB in 24s (114kB/s)
Reading package lists... Done
W: GPG error: http://box.exoweb.net testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F

The problem being that the public key at the end is not recognized. Looking at the key management utility for apt (apt-key) didn't show any simple way for it to download the correct key from the debian keyring, so I ended up having to use a bit of a kludge. These were the commands I had to run (as root):

gpg --keyserver keyring.debian.org --recv-key 2D230C5F
gpg --armor --export 2D230C5F | apt-key add -

The first line downloads the public key and adds it to the root user's list of public keys. The command exports this from the root user's keylist to apt-key. The cleanest way to do this would probably be to use wget to get the actual key from its appropriate location, then pipe it to apt-key (it would be a one liner too). However, that is clunkier to do since one has to look up the appropriate location of the key, etc. In the end, adding just one public key to root's keyring was no real deal.

Ah well, back to your regularly scheduled hacking ...

Year End Thoughts

With 4 hours left to the end of 2005, it's time to reflect on how the year has gone and prepare for the coming of the new year. Overall, it has been a good year for me, though it has felt like I've been hanging on for dear life on to a runaway train. For FOSS, it has been a great year it continues to grow by leaps and bounds.

The greatest challenge in 2005 was for Exoweb to find and integrate good people into the team as we ramped up to satisfy client demands. Exoweb grew from an 8 man outfit when I joined in 2004 to a 34 person company today, and is still growing rapidly. We would actually be larger if we had not had such a tough time hiring good people. In the last year, we have streamlined our HR process, allowing us to screen 10 times the number of candidates we could previously, with minimal impact to the daily operations of Exoweb.

Beyond just increasing bodies though, Exoweb feels so much better a place to work in now. It was a nice place before that, but in the last year, we have managed to strengthen the company culture, added a bunch of really smart people and started processes to ensure that we are constantly improving. I can honestly say that the current Exoweb team is the smartest, most competent tech team I have had the pleasure of working with. It is both a joy and a challenge to work with intelligent people who are far more knowledgeable than you in their areas of expertise. We may or may not have the stellar brain matter that Google is reputed to have, but the current team can definitely give any other team a real challenge.

2006 will bring its own challenges, no doubt. The company culture is relatively young and it will be challenged quite a bit as it tries to accommodate the changing desires, needs and eccentricities of our growing and maturing developers.

Another thing that I am proud of is that Exoweb's contributions back to FOSS projects are growing. While we mostly filed bug reports in in 2003 and before, we started contributing code to small projects in 2004 and that trend has only accelerated in 2005. Since we became active users of django, several patches have been accepted into the main trunk and we should hopefully be contributing even greater functionality soon. We have patches in various other small projects such as EaseXML (formerly XMLObject), and identified performance improvements in projects such as PostgreSQL. We recently instituted a contribute-back policy, where developers can spend up to 10% of their working hours on FOSS projects, just contributing back to the community that makes our business possible.

Incidentally, the usage of FOSS is on the rise in China, even if the community does not appear to be that visible as yet. A growing percentage of the candidates going through our HR process are listing FOSS skills and projects on their resumes. More and more companies are using FOSS technologies in their daily work. We are also getting more business inquiries specifically seeking our FOSS skill set.

Finally, every competent FOSS person I know is fully employed and in huge demand. I know, because I tried to poach every single one not working in Exoweb :). For those who kept asking, "how can you find a job with FOSS skills?" a year or two ago ... HAH! Everyone I know has options - if they were not happy where they are right now, they could find a new job so very easily.

It has been a good, busy year. I am really looking forward to 2006 - more challenges, more growth and hopefully a bit more free time to relax and really play with technology again.

What Makes a Senior?

It is time for the semi-annual performance reviews again and a few questions raised during the reviews made me do some thinking. As a young, growing company, we find ourselves defining many things on the spot. Many things which may be well defined in larger, established companies, we do not find appropriate for Exoweb. One of these is the definition of what is a senior.

First, a little background - Exoweb has roughly 3 broad levels of software developers - junior, mid and senior. There are finer distinctions within each broad category, but those suffice for now. In general, what defines whether a person is either a junior or mid level is pretty clear - it is based on their ability to complete a task. Juniors normally require supervision and guidance, including being pointed in the right direction and perhaps some tutoring, in order to complete their tasks according to Exoweb standards. Mids are relatively independent, able to complete a task independently. It is defining what separates a mid from a senior that is tricky.

The problem is that our seniors have varied skill sets and roles. Although Exoweb knows very clearly who are the seniors within it, it is not always easy to articulate what makes them seniors. We do not look at education, expertise in any technology or years of work experience. There has never been a need to define the separation, perhaps because every senior that we have is clearly above and beyond the mids that there was never a need to define the role. We just knew.

However, people normally aspire to improve themselves and advance their careers. In order for Exoweb's mids to advance and join our critically important pool of seniors, it becomes more and more important to define what it is so people can work towards achieving this goal. In my mind, it comes down to one critical factor - trust.

We have to be able to trust our seniors to achieve the job. Exoweb defines its job (right now) as "delivering projects to our clients and ensuring they are happy with them." Simple enough. With that definition, the job of a senior is simple enough to define - we have to be confident that a senior, given a task and often a team, will achieve the task. That is all.

It does get a lot more complicated though, as you look at all the different aspects of delivering a project to our clients. There are multiple different aspects:

• Problem solving - This is just a general catch all for anything not covered below. The ability to see problems and ensure that they are resolved is another key quality we look for in a senior. They do not have to resolve it themselves, if it is not their field of expertise. However, they do have to spot problems before they negatively impact performance and ensure that they are resolved, one way or another. If a user interface is clunky and cumbersome, either resolve the issue or find the in-house usability expert to consult on the problem.
• Quality - We take great pride in our work. It hurts us when we are forced to rush out shoddy, buggy software. Even though it does happen, it should be something to be avoided where at all possible. The enforcers of excellence, when it is lacking among team members, are the seniors. They are the final, last chance to catch any defects before they hit our customers. This particular aspect of being a senior is often a thankless and tedious task. Yet someone must do it.
• Technology - The senior must understand enough of the technology to oversee the team and ensure that they are not going off a steep cliff. Besides knowing what technologies work well together, they must be able to spot and stop common pitfalls, bottlenecks and problems normally produced by less experienced team members. Or in some cases, depending on where their strengths lie, the senior must know where their limits lie and be intelligent enough to call for the assistance of another senior when they are out of their depth. This happens often as no one person can know every single technology.
• Project management - Someone has to manage the project and this typically falls to one of the seniors in the team. The person must be able to scope out the work, make estimates, allocate resources and monitor progress. Should any problems arise, the problems must either be resolved internally or escalated to more senior staff. Preferably the former.
• Leadership - Management is more than just looking at tasks and watching numbers. It is also about motivating people. Motivating intelligent, opinionated and confident team members is no easy task. People are far more unpredictable than computers. Yet someone has to do this. Leadership is a crucial resource in ensuring that a team of people are far more effective together than spinning their wheels individually. Leadership in this area can be either or both technology leadership and team cohesiveness.

Most seniors do not have every single aspect mentioned above. Some seniors have limited technology skills. Others are hopeless at motivating fellow team members. But part of being a senior is also knowing where one's weaknesses lie and compensating for them, either by teaming up with someone who has complementary skills, or putting in processes that compensate for this shortage.

In summary, seniors give Exoweb peace of mind. It is the knowledge that when something is passed to them, it will be done without problems. Attention can then be turned to other areas, such as growing the company and ensuring that Exoweb achieves its goal of becoming the workplace of choice for everyone here.

Goodbye apt-get

So it's finally time to leave apt-get, at least on my desktop machine, and go down the path of bsd and ports. I gave up on fink for my software packaging needs and switched to OpenDarwin instead. The main reason for the choice was that OpenDarwn has a larger and more updated package list, so it requires less manual downloading and package dependency resolving. The small price of learning a slightly different controlling program (port vs apt-get) was more than outweighed by the ease of typing 'sudo port install x' and just walking off and letting it do all the work. The lack of a central repository (OpenDarwin downloads the tarballs directly from the original site, not from a central repository) makes it difficult to use a repository cache, but I guess that's irrelevant since I am the only one in the office that uses OpenDarwin anyway.

Also took care of the clunky OpenOffice issue by installing NeoOfficeJ. My colleages have not had good experiences with the older versions but the latest version does not seem too bad. Fires up relatively quickly and seems stable, but I must admit that I have not used it too extensively. Will know more later.

One minor annoyance with OSX are the emacs keybindings, or the lack of two of them. Almost all the commonly used ones are here, even the obscure ones. However, there are two that I use very frequently that are not found in the text editor programs - Meta-f and Meta-b. These go forward and back one word, respectively. I have ctrl-f and ctrl-b, which move one letter at a time, but I have gotten very used to the one word movements that I seriously feel the lack without them. In terminal, all the Meta-x keys are done via option-x, and in text editors, some of this is there. option-backspace is backspace one whole char, the same as Meta-backspace in emacs. However, the option-f and option-b keys produce some strange characters, instead of replicating their Meta-x behaviours. Ah well. At least option-arrow key still moves on word at a time, but I'm too lazy to move my entire hand the few cm required to hit them :)

One other note - never use transparencies on anything you want a fast response time from. I had a slight transparency going on my terminals and was wondering why text-mode emacs was moving dog-slow. Once the transparency was shut off, it was back the good old speeds you have come to expect and love from text terminals. Even with the high-end graphics cards that all these machines come with, transparency is still very expensive on the CPU

Interviewing Thoughts

Just some thoughts to trends/things that some people say when I am doing interviews. Some I strongly disagree with, others ... I am curious what other peoples thoughts and experiences are with them.

1. You can't keep up with the young 'uns
2. You have to change jobs every year, or you will never advance
3. If you learn on your own, without 'real' experience, it is worthless
4. To really become an expert, you must focus on one specific field and ignore the others
5. Details are not important. The compiler will catch it

1. You can't keep up with the young 'uns

This was first related to me by an applicant in her late twenties, with only a little working experience but lots of degrees. In the interview, she said that her goal was to move into project management because, "as you get older, your thought processes slow and you cannot code as fast as those young kids."

The sad part was, all the senior applicants I interviewed that day shared exactly the same viewpoint. All wanted to move out of coding and into project management. They wanted to get into management not because they enjoyed it or because it had to be done, but because they felt it was their only escape from obsolescence.

This is silly. This ignores all the experience and knowledge that older, more experienced coders have gained through painful experience. This assumes that a person's mental faculties begin deteriorating at such a young age (not true!) and that quantity of code equates to productivity. I know I certainly produced a lot more volume of code in my early programming years, but experience has taught me to produce more effective code. It takes fewer lines, has far fewer defects and is far easier to maintain later. If anything, the years have taught me that quality is far more critical than quantity. And woe to anyone that even thinks I'm close to being an old fart ...

2. You have to change jobs at least once a year, or you will never advance

This particular one really annoys me. It feels like the get-rich-quick days of the dotcom boom again. Demand for good technical people is high in China, especially so for those with FOSS skills. Because of this, opportunities abound and everyone is jumping from one job to another to get more money.

I suppose it does give a person more experience and probably a higher salary in the short run. But do you truly gain any skills when you jump around this quickly? By moving so much, you miss the big picture. Most major projects have lifecycles longer than a year.

An eye opening experience I find for most people is to be still around during the maintenance phase of a project. It is then that you realize that those fancy coding hacks you did, or that /* This will never happen */ section of code, will come back and bite you. You get to see the long-term price of taking shorts cuts and skimping on quality. It gives you an appreciation for doing things _right_, especially if you have been through two project lifecycles, where you have seen on where it went right and one where it went wrong.

3. If you learn on your own, without 'real' experience, it is worthless

One thing we always make a point to ask for is whether a person tinkers with technologies on their own, outside of what is required for work or class. More than one applicant has justified not doing so by saying, "if it was not done for work, it is not real world experience. It is worthless."

Is it? The best technical people I know are always voraciously learning. Some deliberately learn technologies far removed from their daily work, to stretch their brain to new ways of thinking. The diverse knowledge base they draw on seems to serve them well.

Yes, "real world" experience is valuable. You never truly appreciate the value of caches until you have been slashdotted, or when you max out all the CPUs on your server farm serving dynamic content. It is hard to really appreciate the value of distributed databases until you have so many transactions that the fastest hard disks in existence cannot write the transactions to disk as fast as they pour in.

However, they are not everything. There are many people with "real world" experience who still have not really learned the best practices and techniques. Unless you are really lucky, you cannot learn this unless you are constantly looking for it. The chances of you working with the best in your field are extremely limited, unless you're lucky enough to be working for someplace like google.

4. To really become an expert, you must focus on one specific field and ignore the others

Partially related to #3. I meet a lot of people with only Java experience. They know every single Java library, framework and technique there is. But nothing else. They have never touched another language, framework or system. They sneer at all others as inferior, but have never tried them.

Depth is valuable, but so is breadth. I have watched Java experts sink their systems as they tried to employ lower performance Java web caches, when squid outperforms the faster available system by an order of magnitude. I have seen people try to squeeze J2ME into embedded systems when an ncurses interface is the only thing that would have given a halfway decent response time.

As they say, when you only have a hammer, everything in the world looks like a nail. If you don't know anything else, you will always use the tools you know, even if they are not the most appropriate for the system. You miss the best of breed tools.

5. Details are not important. The compiler will catch it

Final peeve. Some applicants make careless and copious mistakes while answering their coding question. They explain this away as, "oh, the compiler will catch it when I run this on a computer."

The compiler is not your nanny. It is not your QA department. Even if you had a QA staff to back you up, the most qualified person to find errors in your code is you. There are insidious logic errors that no compiler will catch and even good code reviews and QA people may miss. The best and easiest time to catch errors is right after you have written the code, when all the variables, requirements and interfaces are fresh in your head. Spend the time to review your code and catch everything you can.

Attention to detail is really important. If you lack it, it comes back to haunt you. If you have it, your users may not be able to explain why, but they will like your work a lot more. It is like the Apple products which I rave about - the attention to detail and usability have given their products an incredible competitive advantage. Even with commodity, even sometimes inferior hardware, they can still command per unit profit margins that are the envy of other PC manufacturers.

Powerbook day 5

(Originally posted 20050810)

So it has been 5 days with this nice little bit of hardware and I am liking it greatly. It occurs to me though, that my blogs do not reflect this. I am more likely to point out its shortcomings and difficulties than all the things I love about it. So I thought I'd spend this blog writing about it. I'll try to gloss over the stuff that most other people rave about and focus on what is special about it to me as a full-time developer.

Ok, the usual stuff people rave about:

1. Beautiful, well thought out design
2. It Just Works!
3. Consistent UI
4. Sleeps and recovers in less than 4 seconds
5. High quality hardware

The other stuff that makes me use it as my primary workstation, despite its currently lower performance:

1. Power users welcome

While Apple may have been one of the first to properly implement a GUI and has one of the slickest interfaces around, the mouse is almost totally optional! People like me who like to work primarily through the keyboard interface can actually navigate around purely with the keyboard, using the mouse very rarely. For me, this is a significant speed increase as keyboard shortcuts are far faster than using the mouse. Additionally, because the key bindings are very similar to emacs (my main development environment), everything is comfortable and familiar.

One other cool thing about emacs key bindings is the very limited hand movement. You can reach just about all the keys without moving your hand more than a centimeter from standard rest position. You do not even have to move your hands the ~10 cm required to hit the arrow keys (3-4 cm on a laptop), thereby not disrupting your typing speed. Yes, I am anal about these things. But it does make a serious productivity difference to me.

2. *nix base

While the flashy GUI protects new users from having to deal with the guts and internals of the OS, you can still pop open the hood as necessary. Fire up the terminal program and you can see which processes are the memory/cpu hogs, what crazy programs are running riot, etc. You can fire up your trusty shell scripts to perform routine tasks, run all the *nix applications which we know and love, etc. Get down to the OS level and figure out exactly why that peripheral is not working, if you can.

Granted, this is no different from any *nix environment, but it is a *nix environment with few of the warts. In many ways, it feels like a *nix desktop done _right_.

3. It Just Works!

Ok, so I ran out of other points. But this is a point I cannot emphasize enough. Almost everything works without problems, in exactly the way you would expect it to in a perfect world. One click/keypress often produces the results you are looking for. Things run effortlessly. You waste so little fighting the GUI/OS and so much time just being productive. All the little annoyances that bugged you, be they in the Linux, BSD or Windows world, seem to be magically gone here. No need to spend days or weeks tweaking/configuring it.

Ultimately, the powerbook and osx is what I consider the ultimate combination - the simplicity that Windows promised, the power and security of *nix, all combined in one very well designed package. It is a testament to what attention to detail and usability can do. The hardware, while of high quality, is commodity. Any other company can manufacture materials of comparable quality. However, no one can put it together, hardware and software, the way Apple has done with their computers or iPod.

Powerbook Day 4

(Originally posted 20050809)

It is closing in to my 96th hour with the powerbook and it has been a fun experience so far. The first 48 hours was when I had to do the bulk of my learning - getting used to the "Mac way", installing applications and waiting for stuff to download. After that, it has been mostly smooth sailing.

The only issues I've encountered so far is the relative slowness of the ppc chip and OpenOffice.org clunkiness. The OpenOffice.org clunkiness is just because the standard installation uses X11 and is not well integrated with the rest of the desktop at all. Things like one click in email to open a document just do not work. It is a cumbersome multi step process. I'm currently downloading NeoOfficeJ (based on OOo) but the slow download speeds in China really takes a while. Still, not a big deal.

The more serious issue is the performance of the system for number crunching. After I had set up my development environment, I was surprised to find that CPU intensive unit tests in my projects took twice as long as they did on my old laptop. Functional tests (fire up all the servers, do black box testing using simulated browsers) took 4-5 times longer. This makes the powerbook substandard as a development station.

A simple test of this is to run code like this:

a = 1
for i in range(1,1000000):
    a = (a + i)/i


On my laptop and workstation (1.5Ghz AMD Athlon, underpowered by today's standards), this takes 0.8 seconds to run. On the default python program on OS X, this takes 1.3 seconds! Using the version of python obtained from fink, this drops to 1.1 seconds, but still far slower than the Athlon systems. This is all using python 2.3.5.

Have not looked into detail for the reasons behind this, but I suspect that it is in part because OS X is tuned to be a desktop, not a server. Responsiveness of the GUI is paramount.

At any rate, this is disappointing, but not a deal breaker for me. While it means I have to run the intensive functional tests on a separate, development machine, I can still use the powerbook for most of my daily work. I always have a workstation somewhere within ssh distance of me anyway, and sadly enough, most of my daily work does not involve CPU intensive activity anymore. Things such as responsive email, web browsing and document editing are more important.

It's Powerbook Time!

(Originally posted 20050807)

I finally gave in to the dark side this saturday. Could not resist it any more. I finally broke down and ... got me a Mac. A powerbook to be exact. Retired my old x86 laptop and went down the path of OS X and the PPC (temporarily). It has been an interesting 48 hours as I tinker with my machine, getting it ready for duty as my development machine on Monday.

There are quite a few reasons for getting the powerbook. They range from the superior quality of the hardware itself, to the "It Just Works" experience that my colleagues were experiencing with their Apple laptops, to sheer lust for all the nifty features that came fully functional on a standard OS X install. All these great features and I would not be giving up the *nix environment that I have grown so comfortable on after all these years on Linux desktops.

My greatest challenges in the last 24 hours have been adjusting myself to the "Mac" way of doing things and configuring the laptop for development. I have until Monday, as there will be certainly no time for me to do any fiddling with my development system once the workday begins. 

Navigating around an OS X system is relatively easy using a mouse, but for a variety of reasons (speed, looming RSI and the unwillingness to carry an extra mouse peripheral), I prefer to use the keyboard for most of my functions. The average linux (KDE/Gnome) desktop allows you to do this rather well, but with a rather different set of key bindings. The biggest thing to get used to is the Alt/Command difference. Coming from an emacs background is both a blessing and a curse. Most of the OS X apps support emacs bindings with the control key, especially cursor movement (^f, ^b, ^p, ^n, etc). Unfortunately, they do not support the Alt keys, as the equivalent of the Alt on OS X is the Command key and keys like Cmd-b and Cmd-f are already used, being Bold and Find, respectively. These are keys I use a lot in navigation (move forward one word, move back one word), so I find myself having to use a lot more keystrokes than I used to. I'm sure that I'll get used to this in time though.

After spending a few hours learning the system and adjusting it to my preferences, I realized that I would have to repartition the system. I wanted to reserve HD space to put a linux ppc distribution on it later, just in case something came along that OS X could not do. Unfortunately, repartitioning a HFS filesystem is a destructive process at present, so I was forced to wipe the system and reinstall. Fortunately, this process is relatively painless. You pop in the disk, select a few options (less than even an ubuntu install) and you can almost leave it alone till it is finish about 30 minutes later. It was the easiest system install I have ever done in my life.

After that, the next challenge was simply setting up a development environment on OS X. OS X is meant to be a consumer desktop, not a development workstation, despite its BSD/*nix roots. It is quite a bit more effort to install the necessary applications I need to develop on. Fortunately, I could draw upon the experience of several of my colleages, particularly Adam. Following his advice, I went with fink to provide most of the resources I needed. I suppose I could have tried OpenDarwin instead, but fink gave me the familiar apt-get tools from Debian.

After downloading the necessary .dmg file from the site, installation and usage of most applications was relatively easy. The major applications such as python2.3 and postgresql 7.4.x was installed with "apt-get install x". The smaller, lesser known applications were more of a pain though. Things such as psycopg, twisted and clearsilver required source installs as they were not in the repository. I even played with DarwinPorts for a while as it had most of those packages. Unfortunately, the DarwinPorts versions were newer than what I needed, so it was back to source installs.

Finally, a little under 48 hours after I got the laptop, my development station was set up, all systems were running and I was ready to develop. It has been an interesting experience so far and the laptop has been a joy to work with.