Avoiding "Emacs Pinky"

My recent switch to using Apple Macintosh has had a surprising painful side effect sometimes called "Emacs Pinky".  Emacs Pinky is wrist pain associated with using the Emacs editor all day, or in my case any other editor which uses the Control key a lot.  I have never experienced this problem before, but it seems that the Apple aluminum keyboard which I recently began using is part of the problem.

Apple's aluminum keyboard design does look very cool.  It is very sturdy looking, and the keys feel nice.  However, compare it to ergonomic keyboards which have been designed to avoid RSI (Repetitive Stress Injury).

• Ergo keyboards are curved whereas Apple's keyboard is straight
• Ergo keyboards are elevated whereas Apple's is relatively low and flat
• Ergo keyboards have an attached palm rest to keep your wrists from bending, Apple's keyboard does not

I do not believe that Apple makes an ergonomic keyboard.  I did see some third party ergo keyboards online that are designed for Apple, but most were pretty expensive.  So, I headed down to the local Best Buy store to see what they have.  I noticed that Microsoft's Wireless Comfort 5050 with mouse was on sale, and reading the back of the box it said it works with Mac OS X.  Sold.

There is one minor gotcha with the Microsoft keyboard.  It is, naturally, designed primarily for Windows and therefore has Alt and Windows keys instead of option and command keys, but this is less of a problem than it sounds like.  It turns out that the Alt key is really the same as Apple's command key, and the Windows key is really the same as Apple's option key.  Unfortunately, their position is swapped.  However, in MacOS it is quite easy to go into System Preferences->Keyboard->Modifier Keys, select the Microsoft keyboard (once it's been attached) and swap the function of the Option and Command keys.  Problem solved.

Testing out the Microsoft keyboard, it seems to work fine, although it has a lot more buttons than on an Apple keyboard and I haven't taken the time to try them all out.  The volume buttons work as expected, and so does the pause/play, previous and next buttons (tested in the Spotify app).  The PrtScn button doesn't do anything, but Mac users should be used to not having a PrtScn button.  (Actually, since PrtScn is just F13, it is possible to map a keyboard shortcut to use this, but the Macbook's internal keyboard has no F13 so it won't work when the external keyboard is not attached.)  Interesting, I discovered Microsoft actually has a support page describing Keyboard mappings using a PC keyboard on a Macintosh.

The one other thing I have run into so far that I don't like about the Microsoft Comfort 5050 keyboard is the Esc key and function keys are very small, and as a Vim editor user I use the Esc key a lot.  Note that the newest MacBook Pro actually eliminated the esc key, and one of the suggested solutions to bring it back for Vim users is to remap the option key to act as Escape.  I could try something similar with the Windows keyboard, but it might mess with my muscle memory which tells me the Esc key is "supposed to be" in a certain place.

By the way, the Wireless Comfort 5050 also came with a mouse which works quite well.  I wanted a keyboard that came with a matching mouse so that I would still need just the one USB port.  Unfortunately, Microsoft does not provide a Mac driver for the mouse, so MacOS treats it rather generically and it isn't as customizable as an Apple moue or a Logitech mouse made for Mac with Logitech's driver.  However, you can download a third party shareware driver called USB Overdrive which will allow you to customize settings of virtually any mouse.

Of course, there are probably other things I could do to reduce my risk of RSI, but this was a quick fix for a very specific problem.  Other suggestions for avoiding "Emacs Pinky" include:

• remapping the Caps Lock key to be be another Control key
• not sure how to do that on Mac or if it is even a good idea as it might cause other problems
• pressing the Control key with your palm or knuckle
• palm seems super awkward for me... knuckle might work
• using Vim (or Vim IDE plugin) instead of Emacs
• I already use a Vim IDE plugin, and don't use Emacs
• using both hands for control key combinations
• I must admit that I'm in the habit of using the left control or command keys for copy and paste, which is possibly part of my problem, but some keyboards, including the Macbook's internal keyboard, do not have a a control key on the right side.  You could potentially swap the option and control keys, but that might cause other issues.

(See How to Avoid the Emacs Pinky Problem for more information and ideas.)

So far after switching to the ergonomic keyboard I am not experiencing the "Emacs Pinky" pain.  I'll update this blog later once I've decided if this is a long-term success.

Mac OSX Web Developer Challenges

The point of this blog post is not to bash Mac OSX.  I like my new Macbook, my wife loves her Macbook even though it's getting quite old, I just bought one for my son, and OSX has many advantages over Windows.  However, since switching to OSX away from Windows for web development I have experienced some frustrating problems.

Most IT organizations doing web development use Windows for developers and Linux and/or Windows for their servers, although as I pointed out in a previous post Apple hardware is becoming more common.  Of course, Apple got out of the server business around 2010 and there's no sign of them jumping back in.  There are actually some hosting companies that will rent out OSX in the cloud, but that's not very common, and it's not an area that is making much money for Apple.  So, those of us doing web development on Apple computers are kind of an exclusive group.

The vast majority of Mac users are not going to run into the kind of problems I am having, because they are not web developers using development tools and languages not created or supported by Apple.  I do a lot of programming in Java and Javascript.  This is a programming blog, so I am assuming the audience is other programmers, but if you are an OSX and/or iOS developer doing ObjectiveC or Swift, maybe you are in the enviable position of having everything basically always work as you expect.  That's not the world I live in, at least not in my current job.

One of the first difficulties (I won't even call it a problem) that I ran into with my new Macbook is that there are so many ways to install software on OSX.  

1. App Store (note that somebody also created a cli for the mac app store)
2. DMG (disc image) files
3. application files
4. archives
5. Windows-like installers
6. Macports for installing ports of Linux and Unix software
7. Fink, an alternative to Macports that provides a Mac implementation of Debian Linux tools like dpkg and apt-get, concentrating on pre-compiled binary packages to improve performance over Macports
8. Homebrew, another alternative to Macports.  Homebrew does not like the other competing package managers, it takes over /usr/local and doesn't like other installers to put anything there, and, similar to Macports, installs can be excruciatingly slow when it has to compile from source.  However, even with the drawbacks Homebrew seems to be better than Macports or Fink and makes it much easier for a developer to install certain software.
9. SDKMAN, for installing Java and Groovy SDK's

To be fair, there are multiple ways to install software on Windows and the various flavors of Linux as well.  However, I am just pointing out that using a Mac is generally expected to be simple and intuitive, but that is probably not going to be the case if you are a web developer.  Even if you don't want to run any software ported from Linux, there are at least 5 ways to install software on a Mac.

Some problems I have experienced as a web developer are particularly frustrating because they seem to be very specific to particular versions of OSX.  Therefore, other developers I work with may not see these issues even if they are also using a Mac.

Recently I have been working on a Node.js app that uses something called deasync.  Now, I don't want to digress into a conversation about Node.js, but suffice to say that deasync is a C hack that changes the way Node.js behaves at a low level and should probably not be in our project, but it is, and I have to deal with it.  Unfortunately, it turns out that deasync gets errors on my Macbook.

What is most frustrating about this Node.js problem that I am having is that it doesn't happen under Windows or Linux, and it doesn't seem to happen on all versions of OSX either, so basically I am the only person on my team having this problem.  And the only workaround I can find for this problem is to completely avoid it by running the Node.js app from inside an Ubuntu Linux VM.  The permanent fix should be to stop using deasync, but that would require a lot of re-writing on a project that is running out of budget.

Now, this deasync/Node.js bug is not Apple's fault, it's not even the fault of the Node.js developers.  The author of deasync doesn't want to take responsibility for it, because the error actually occurs in libuv, which is used by Node.js and deasync.  However, the libuv developers would probably say it is a problem with OSX.  I could try to fix libuv myself, it is open source, but I am a bit outside of my comfort zone with such low level C code.

Of course, these are just a couple of examples of the kind of difficulties one may run into.  I would really like to know how many web developers use Macs in their work compared to Windows and if they tend to run into similar issues or if I've just had a bit of bad luck this time around.  Also, I am hoping that with increased familiarity I will just know how to avoid problems in the future.

Can One Write Too Many Comments?

A friend of mine recently was watching a youtube video where somebody said coders should not comment their code.  My friend blamed this way of thinking on the TDD "fad".  His solution:  javadocs.

I asked my friend if he had read anything by Robert C. Martin and suggested the book "Clean Code".  He said the name was not familiar to him.  He said he doesn't read a lot of books but gets most of his ideas from the internet.  One exception he noted was a book called 21st Century C, which I am not familiar with.

Anyway, this argument about comments has been going on for as long as people have been promoting TDD (Test Driven Development) philosophy, and perhaps even longer.  When Martin Fowler wrote his book on Refactoring in 1999, one of the first books that mentioned JUnit, he categorized comments as a "code smell".  To be fair to Fowler, he said comments are a "good smell", but that they are often used as "deodorant" to to cover up for bad code.  So, too much comments may be a sign of problems.  This idea was just one part of the "extreme programming" mindset, which represented a paradigm shift which was difficult to fully accept but brought many advantages for developers.

Lean principles and my own experience tell me that too much effort placed on activities that do not directly impact the end product, such as comments (and documentation in general) can be a waste of time.  (It suddenly struck me as a bit ironic that I'm making a statement like this while writing a blog post which itself may not be the most productive activity, but whether anybody else reads this or not at least I can justify that this is an exercise useful for helping me organize my own thoughts and think through my own opinions.  Perhaps the time spent on documentation is kind of like that.)

Years ago I had a professor that insisted every single line of code should have a comment.  I have never met anybody else that wouldn't agree with me that this is a wasteful extreme.  I also have worked on projects where every function and/or file had to have a header comment, every variable had to have a comment describing what it was, and/or every change to a file had to be explained in a comment.  I even worked on one project where the rule was to never delete code, you always just commented it out.  People running these project obviously felt their rules were important, but I did not agree.

I have also worked on waterfall projects where business analysts took so long to determine requirements that there was not enough time left for actual coding the project.  I would rather produce something useable within budget constraints than try to create something perfect that never gets finished.  As they say, "perfect is the enemy of good."

In Clean Code, Martin acknowledges that Javadocs are good for describing a public API, but goes on to say that most other comments are bad and devotes several pages to support this assertion.  Has Martin gone too far?

Back to my discussion with my friend, we agreed that extremes are generally not good.  In fact, I think everybody, including managers who sign off on software projects, intuitively know that, and so I think the naming of "extreme programming" is sort of unfortunate.  XP practitioners labeled their own ideas as out of the norm, perhaps even unproven or risky.  I think they were going for the "coolness" factor calling to mind "extreme sports".  Perhaps they would not have gotten anybody's attention without the cool name, but in the long run "agile" and "scrum" sound more positive and safe.

I think comments can be helpful when they relate why a developer implemented code in a certain way.  I often put in TODO or FIXME comments in code when I know there is probably a better way to do something, but I just do not have time to explore it further.  Sometimes when I copy code from examples I find on the internet I like to put a comment giving credit to the original author and/or a link to the web site where the code came from for future reference.

However, I do not believe in hard and fast rules for such things.  I understand why managers create such rules.  I have been in management roles myself, so I know how much pressure there is to succeed and how hard it is to ensure some level of quality while getting things done quickly and minimizing risk.  But from a programmer's perspective what we run up against is that each new project has a new set of arbitrary rules.  One project might implement Uncle Bob's rule of almost never writing comments, while another project goes to the other extreme.

As programmers we just want to do a good job, but we don't want a stifling set of arbitrary rules.  We value creativity and individuality.  The agile manifesto states this quite clearly.  So, some things should be a topic for discussion amongst programmers and not something that should be imposed from the top of an organization or even by tyranny of the majority of programmers in a team.  I would argue this is one of those cases.

My First Experience With An All Javascript Project: Angular, NodeJS, and Mongo

I recently wrapped up a 9 month web application project using NodeJS and MongoDB for a backend and Angular Material on the front end.  I had a little Angular experience before, but many of the other technologies on the project were new to me.  It is quite an interesting experience taking on a lot of new technologies at once.  It can be kinda frustrating at first, but overall it was a fun project and I'm glad to have worked on it.  Anyway, I thought it would be a good time to share some of my thoughts about the technologies we used.

MongoDB

One of the most controversial decisions for this project was the use of MongoDB.  The company the project was created for has a long history with Oracle databases.  Some people have a vested interested in continuing that tradition.  However, I was tasked right at the beginning of the project to justify the use of Mongo.

It is quite easy to find articles on the internet about all the reasons that you should never ever use Mongo for basically anything period.  These articles can be kind of scary for some people, and if you have personal reasons to not want to use Mongo it is quite easy to point to these types of articles and say "see, I told you so."

Unfortunately, you can easily find negative articles like this about any technology you can name.  Whatever it is, somebody out there hates it enough to write an article about how it is inherently bad and deserves to be shunned by everyone.  This has been the case ever since the famous "Goto Statement Considered Harmful" article published before most of us were born.

Suffice to say that in the end Mongo was not in the least harmful to our project.  On the contrary, it was a key in allowing us to get a lot of functionality out the door in what was record time for the company in question.  Almost nobody thought we could do what we did, and I credit a big part of it to the flexibility of MongoDB.

MongoDB was a great fit for a NodeJS project, but also it allowed us to evolve our database in an agile fashion rather than designing it all upfront with ER diagrams and without a single argument over column naming standards.  It was a breath of fresh air compared to many other projects I have worked on.

NodeJS

Some of my feelings about NodeJS are summed up pretty nicely by Gavin Vickery, although I'm not sure about his conclusion that Python is a better solution.  I don't have a lot of Python experience.  Although I keep hearing about how Python is so popular, currently the 4th most popular language behind Java, C, and C++, according to the TIOBE index, while Javascript sits at 8, if I search for jobs in my area for each of these languages, there are a lot more javascript jobs that Python.  And there are significantly more NodeJS jobs than Flask jobs.  So, while some developers are confortable sticking with their little niche technologies, I am concerned a lot more about job security and marketability.

Anyway, the biggest problem I had with NodeJS is "callback hell".  This is the term often used for the difficulty in thinking in terms of asychronous code in Javascript.  I found that people have so much trouble thinking in these terms and getting the code right that they tend to look for ways to get around the problem rather than learn to do it the right way.

An example of somebody trying to get around doing callbacks the right way is a project on github called deasync.  The original author of deasync says on github that it is "...just a hack and I'd strongly recommend not to use it for anything."  The deasync project relies on C++ code that can cause strange errors depending upon the OS and version of NodeJS.

Another example is a project called node-fibers.  I thought at first that node-fibers seems like a more elegant approach than deasync, but it solves a slightly different problem, and it also relies on C++ code to do its magic.

I think it is better to stick with the standard Javascript way of doing things than to try to hack a solution with C++ code which could easily become invalid with some new version of NodeJS.  However, that really means you should bite the bullet and deal with "callback hell" until some future version of Javascript solves the problem.

Alternatively, if you do not like asynchronous Javascript, write your backend using another language such as Java or Python.

Restify

We decided to use Restify on this project rather than Express.  I don't have much to say about it other than it is pretty easy to use and worked fine for our project.

AngularJS

When we started our project, Angular 2 was still in beta, so we stuck with Angular 1.  The biggest problem we had with Angular was performance problems around digest cycles.  This has to do with two way binding from browser DOM to and from the model.  For sample/toy applications that you see in typical tutorials you won't run into any problems, but as an application grows the computation of keeping the DOM and model in sync can become a significant bottleneck.

Angular 2 tries to improve performance, but on future projects we are considering React instead of Angular.

Angular Material

The decision to use Google's material design had it's pros and cons.  Of course, in the future if we go with React we can no longer use Angular Material, but we can still use material design with some other library.  Angular Material was fairly limiting.  It didn't always behave as one might expect.  More often as not this is because the Material Design spec itself is so limiting.  So, we ended up supplementing with jquery controls.  For example, we did not use the Angular Material calendar but the one from jquery-ui wrapped in our own Angular directive.

The Material Design look and feel was originally crafted for Android devices, and it feels a bit strange elsewhere.  It doesn't look anything like the native look and feel you would expect on any given OS, and a lot of business users will not be content with the limited selection of controls it provides.  I don't think I would use it on my own personal projects.

Macs Still Don't Suck: IT Professionals Increasingly Prefer Apple

In the last couple years I have noticed an increase in IT departments being willing to purchase Macbooks instead of Windows laptops.  It turns out that there is evidence beyond anecdotal experience that, according to a 2015 article, Apple Macs are replacing PCs across enterprise at ‘unprecedented rate,'

It wasn't that long ago that people were writing articles informing us of all the reasons Why Mac Sucks, which impassioned others to counter that, no, actually Macs Don't Suck.  Not to be out-done by Apple, Microsoft invented Windows 8, and now the number of "Why Macs Suck" articles on the internet is totally eclipsed by "Why Windows 8 Sucks" articles.  Windows users and IT departments have so little trust in Microsoft that they regularly refuse to upgrade to newer versions of Microsoft's software, instead preferring to stay 2 or 3 major versions behind.

I have mostly used Windows, but recently got a Macbook Pro.  This prompted some of my colleagues to ask why I would want such a strange machine.  After all, it has a weird keyboard with the control key in the "wrong" place, and there is supposedly no right mouse button (or so they thought until I showed them otherwise).

Long-time Windows users are sometimes surprised and annoyed that Apple keyboards and mice and other things are slightly different from what they are used to.  However, Microsoft has for decades copied ideas from Apple, so it would be a bit silly to expect Apple to then turn around and blatantly copy Microsoft.  If Apple had copied what Microsoft did with Windows 8 it would have been a huge mistake.

It should also be noted that before Microsoft made Ctrl-C mean "copy" under MS-DOS it already meant "abort", and it still does mean that if you are typing at a command prompt within Windows.  Microsoft could have used Alt-C (the precedent set by the once popular WordStar word processor).  Then there would also not be this inconsistency between Windows and MacOS.  (On a side note, the Emacs editor did not introduce "Cua Mode" (to allow C-c, C-v, and C-x) until version 22.1.1 around 2007.)

I not only have experience with MacOS X and Windows, but also with Unix and Linux.  Depending upon who you talk to, MacOS X is either the best of both worlds (between Windows and Linux) or the worst of both.  There is certainly room for differing opinions, but I think the truth is somewhere in the middle.

Some people still think of MacOS X as Apple taking something that should be free and charging money for it (i.e. Linux).  However, MacOS X is not Linux, does not have Linux under the covers, and actually has nothing to do with Linux.  Both just happen to be related in some way to Unix, an OS that few people actually use anymore.

In fact, Linux is not even a complete OS.  Linux is merely a Unix-like OS kernel.  A Linux distribution (or "distro") is a combination the Linux kernel with a bunch of GNU software (licensed under the GPL).  Companies combine these things together, add their own enhancements and slap on their own branding (such as Red Hat Linux or Ubuntu Linux).

MacOS X is a complete operating system descended from NextOS, which pre-dates Linux, based on BSD (Berkley) Unix with its own kernel called XNU.  XNU is descended from the Mach kernel created at Carnegie Mellon University.  As with Linux distributions, MacOS X does ship with quite a lot of open source tools, and Apple does contribute code back to the open source community.

MacOS X also, of course, has a standard GUI, which has long been one of the best and most obvious features of the Mac.  Linux has no standard GUI.  Linux users have to choose from one of at least 8 different desktop GUI environments, which is great for people who like lots of options, but not so great for people who just want something that works.

Long-time Linux users may be annoyed that MacOS X doesn't have a command-line tool for installing open source software packages and their dependency like apt-get or yum.  There are some open source projects that try to fill that need.  The most popular seems to be Homebrew.  Homebrew is pretty good for installing many software packages ported from Unix or Linux to MacOS X.

Most Mac users will probably never mess with something like Homebrew.  They will get all their software from the App Store or distributed as disc image or installer.  However, as a developer there are things I need that are easier to install via Homebrew.  It can be slow, and it does not play well with competing package manager solutions, but it gets the job done.

The reason I recently made the switch from Windows, at least for my work laptop, is that the Dell laptop they had given me crashed constantly with sudden blue screen.  The IT Help Desk couldn't fix the problem, and I got tired of dealing with it and asked them to get me a Macbook instead.  After my new Macbook was ordered I figured out that my Dell problems were caused by a bad memory card, but the Macbook was already on its way.

I bought a Macbook for my wife several years ago, because I got tired of constantly fixing the problems she had with Windows, like viruses or the dreaded "blue screen of death" that occurred seemingly at random.  The Mac turned out to be a good choice for her.  I was happy that I didn't have to help her as often, and she was happy to have something that is easy to use and just works nearly all of the time.

In the years since I bought my wife's Macbook, I went through several less expensive Windows laptops.  I tried HP, Asus, and Toshiba and unfortunately had quality issues with all three.  The reason I kept buying them hoping the next one would be better is that, of course, I am cheap.  Actually, Apple computers only seem more expensive because they do not offer a low-end product made with cheap hardware.  If Apple wanted to sell low-end hardware, of course they could.  As they say, you get what you pay for.

Apple is primarily a hardware company, which is why they hired Microsoft to create Microsoft Word for the original Mac.  They do not have a business model like Microsoft's where they expect to make a lot of money from their software or like Google's where they try to make money by giving away free services and charging for advertising.  They make money by producing innovative products that their customers are willing to pay a premium for.

Anyway, once you get used to the differences in the GUI and the keyboard layout, a Mac can do basically everything a Windows PC, and you can even run a lot of Windows software in a virtual machine or with Wine (the Windows emulator).

But you shouldn't get a Mac because it can emulate a Windows PC, but because of the reliable and enjoyable user experience.  You will never see another "blue screen of death", you will not have to worry about your computer becoming infected with viruses (thanks to XProtect and the fact that most viruses target Windows, but if you want additional protection there are several free antivirus offerings), and you will never again feel that you should keep your operating systems 2 or 3 major releases behind the latest.

GNUstep with Eclipse CDT

Although GNUstep has its own IDE and editor, It is possible to use Eclipse for Objective-C projects using CDT, the C/C++ Development Tools.


If you are using Linux, the first thing you need to know about Eclipse is not to install the version packaged with your OS. Ubuntu, for example, is several releases behind on Eclipse. Rather, first make sure you have the latest Java installed (eclipse needs Java), then go to the eclipse.org web site and download it. If you want to use it for both Java and CDT, you can download the one for Java and then add CDT. It's easiest to just install it under your home directory simply by unzipping it there with a command something like...

tar xzvf eclipse-java-galileo-linux-gtk*.tar.gz

Unfortunately, CDT does not directly support GNUstep. You cannot easily import an existing project created by Project Center or create a new GNUstep project with from scratch within Eclipse. Here is one approach suggested in the help-gnustep mailing list by Anne van Rossum (I haven't yet tried this).

- Create sample.m file and GNUmakefile in ObjCProjectExample

- run $GNUstep root/System/Library/Makefiles/GNUstep.sh

- make (that should go fine)

- start eclipse from same console (building/running should go fine)

- add new C project and import directory structure (from ObjCProjectExample)

- at Project - Properties - C/C++ Make Project - [tab] Environment push button Select

- select all environment variables with GNUstep in their names

- apply changes


(Re)Starting Eclipse from whatever location should be fine now. The GNUstep.sh shell script is no longer needed.

[Nicola Pero added...] By the way with the current gnustep-make from trunk, you can also do:


* make sure GNUstep's appropriate dirs are added to your PATH and ld.so.conf [or equivalent to ld.so.conf on your system]


(ie, something like

PATH="$PATH:/usr/GNUstep/System/Tools:/usr/GNUstep/Local/Tools" and adding

/usr/GNUstep/System/Library/Libraries and

/usr/GNUstep/Local/Library/Libraries to your ld.so.conf and rerunning ldconfig regularly)


* set the GNUSTEP_MAKEFILES environment variable (it should be set to
something like /usr/GNUstep/System/Library/Makefiles/)
And then 'make' should work. ;-)

All the other variables are then read automatically by gnustep-make from
the GNUstep config file in /etc/GNUstep/GNUstep.conf.

However, these steps actually seem overly complicated to me. I was able to import an existing GNUstep project into the latest version of Eclipse with the latest CDT with the following steps:

Create a new empty project...



Right click on the newly created project and select Import. Then select General... File System and click Next.


Browse to the project you created in Project Center, click Select All and Finish.

You should now see all your files in Eclipse and should be able to build and run the project.

One oddity is that when you open up a .m file it opens with gedit instead of opening the Eclipse editor. I assume this is because the Eclipse editor doesn't know Objective-C syntax. However, gedit seems to do the color syntax highlighting just fine.

GNUstep Look-and-feel

OpenStep originally was supposed to fit into the look-and-feel of the host system. Consequently, the Solaris and Windows versions of OpenStep looked different, and when OpenStep became the basis for Cocoa on the Apple, the look-and-feel got a Macintosh face-lift. However, Linux has no standard look-and-feel. It all depends on whether you are using KDE or Gnome or whatever.

The GNUstep developers chose to keep the “retro” NeXT look. There is even a desktop on Linux called Window Maker (or wmaker) that is part of GNUstep (or used to be) and implements the old NeXT look-and-feel. However, few people would seriously consider using Window Maker on a regular basis instead of KDE or Gnome (my apologies to Window Maker fans). There is also something called GWorkspace which takes over your desktop and tries to make it look like NeXTstep, but it didn't work right for me when I tried it under KDE4 or Gnome.

By keeping this “retro” look, GNUstep unfortunately makes itself uninviting to most potential users. It also creates a confusion between GNUstep the development environment and GNUstep as a desktop environment.

One feature of GNUstep that can be annoying is the big application icons that appear in the bottom left of the screen when you run a GNUstep application. In Window Maker these would be organized neatly along the right side of the screen, but other window managers just don't know what do do with them.

To get rid of the big icons (I can't think of a reason they will be missed), open a terminal window and type the following command:
defaults write NSGlobalDomain GSSuppressAppIcon YES

You can also change the freestanding menus to be at the top of the screen like in MacOS X using the following command:
defaults write NSGlobalDomain NSMenuInterfaceStyle NSMacintoshInterfaceStyle

However, this will affect other things such as scrollbar style.

To change it back use:
defaults write NSGlobalDomain NSMenuInterfaceStyle NSNextStepInterfaceStyle

There is also a NSWindows95InterfaceStyle, but it won't make your menus appear inside the main menu.

(I think if you set these for your application's name instead of NSGlobalDomain, it will only affect your application.)

In fact, these settings also exist in MacOS X in NSInterfaceStyle.h.

typedef enum {
NSNoInterfaceStyle = 0,
NSNextStepInterfaceStyle = 1,
NSWindows95InterfaceStyle = 2,
NSMacintoshInterfaceStyle = 3
} NSInterfaceStyle;

Apple and Microsoft don't have to support any look-and-feel besides their own. However, if you are producing a cross-platform development environment (like GNUstep), and especially if you are the underdog (as GNUstep is), your programs should behave as expected in whatever environment they are running in. This would be much easier if the GNUstep developers would just abandon the old retro look that simply doesn't appeal to most people anymore.

Creating a GNUstep Project

I got the book Developing Business Applications with OpenStep. It's not all I would have wished for. You don't get to your first sample application until Chapter 7, and wading through the first 6 chapters is a bit of a chore. I found Chapter 4 on the Application Kit contains no sample code at all, but it is good for insomnia. Anyway, now that I'm to Chapter 7, Building an Application, I am going to try creating the sample application (PayPerView) which is their only working example and which they add to later in the book when they introduce more advanced topics (this may be the last chapter I read in the book).

PayPerView has a class called ProgramController, which isn't really what it sounds like. The word “program” in this context refers to a pay-per-view tv program. The ProgramController keeps a list of Program objects and interacts with the UI. There is also an OrderController, which controls the process of a user placing an order for a Program. Why there isn't also an Order class I do not know. More classes are added later in the book when the application is expanded to persist to a database and one to use distributed objects. (I am not actually interested in either of these at this time.)

First thing to do is to create the project. In GNUstep, we do this through ProjectCenter. Just like the original Project Builder as described in the book, you choose New... from the Project menu. (Sorry. I am too lazy to paste screen shots in here right now.) I had already created a folder in my home directory called projects_objc. GNUstep creates a GNUstep folder in your home directory for its own configuration files, so better to keep your code separate from that. I'm going to call my application PayPerView and define it as type Application. The default project type in GNUstep is not application but Aggregate. An aggregate project contains multiple sub-projects or “make targets”, meaning it will have multiple executable applications. (You can add new subprojects later even if you select Application at this time.)

On the project window there are noticeable differences between GNUstep's ProjectCenter (PC) and Project Builder. For example, the icons are different. (Still too lazy to do any screen shots, so you'll have to trust me until I feel like adding them.) PC has a screw driver instead of a hammer icon for the Project Builder icon. The remaining icons in GNUstep are different but still reminiscent of the original. That's okay, because there were even significant differences between the NeXT Project Builder and the one that Sun created for Solaris (and, of course, Apple has made significant changes in XCode although it still has the familiar hammer icon). They are the Project Launcher (or Run) icon, the Loaded Files icon, the Project Finder icon, and the Project Inspector (or Attributes) icon.

BTW, at this point if you've never seen XCode it might be best just to ignore it for a while, because it looks so nice while GNUstep looks the same as it did 10 years ago. Just remember that GNUstep is free and not commercially supported.

When you click on Interfaces (as instructed in the book), you will see instead of a .nib file some files related to Gorm, GNUstep's Interface Builder. You get into Gorm by double-clicking on the .gorm file. (Sorry. I am still too lazy to paste screen shots in here right now.)

The format of .nib (NeXT Interface Builder) files were difficult to reproduce in GNUstep, because there is no real .nib file standard. The .nib file is actually just a file containing serialized objects. Duplicating it exactly would have been difficult and possibly required reverse-engineering which probably would create legal problems. However, in newer versions of Gorm, you can at least export to a Nib file by selecting Save As on the Documents menu in Gorm. (I don't think you can import a Nib file created in Apple's XCode and expect to be able to use it in Gorm.)

Anyway, so I will continue later with using Gorm and maybe stop being lazy and add screen shots.

Unit Testing GNUstep Programs

As a Java developer who has been trained in test-driven development, I would like to have something similar to Junit for GNUstep/Objective-C. Evidently, around 2005 Apple added a unit testing framework to Xcode 2.1 called OCUnit. OCUnit was not something created by Apple, but they chose to make it the defacto standard by including it in their packages. Unfortunately, this essentially killed off two other competing frameworks, UnitKit and ObjcUnit.

UnitKit is stuck at 1.1 and evidently no longer supported. The GNUStep port is still available from the etoile web site.

http://cvs.gna.org/viewcvs/etoile/Etoile/Frameworks/UnitKit/
http://cvs.gna.org/viewcvs/etoile/Etoile/Services/Developer/UnitTests/

The GNUstep port of ObjcUnit, stuck where is was back in 2002 (v. 1.2) is at:

http://gentoo-portage.com/gnustep-libs/objcunit

Since Apple is distributing OCUnit and the other two are now unsupported, it would at first seem to make sense to try using OCUnit. It is available at...
http://www.sente.ch/software/ocunit/

Unfortunately, although it does support GNUstep, evidently it works only on Mac OS X. Bad news for GNUstep on Linux.

So, we are stuck with using one of the two older, unsupported frameworks or simply doing unit testing with no framework.

Before the creation of Junit it was quite common to test a Java class simply by putting test code in the main method since each class can have a main method. That begs the question, how many main methods can we have in an Objective-C application? Is there one per class or one per application? The answer is one per application, because Objective-C is an extension of C, and there is one and only one main function in any C program (same goes for C++).

I remember in my days as a C++ programmer, I knew people who did unit testing by creating a bunch of Unix shell scripts that called their program in different ways. However, most people didn't even do that. Back then unit tests were usually just a documented list of steps that had to be carried out manually along with expected results. Essentially, you ran the program and if it works without noticeable problems then it passes.

The first unit testing framework that all the others are based on was SUnit by Kent Beck in his 1998 Guide to Better Smalltalk. So, of course, nobody was using these frameworks before then, which makes one wonder if it's really all that important. It has been my experience that most of the time developers don't do true "test first" development in the context of "extreme programming" principles. They write their JUnits after the fact and often only because they are required to by management. Also, unit testing frameworks are pretty good for testing back-end code, but not so much for testing the GUI part of an application.

Don't get me wrong. I like test driven development. However, all things taken into account, I'm not sure I want to spend time writing a bunch of unit tests for a GNUstep program if I can't use OCUnit and there are other ways to get around the testing problem without the need for a testing framework. That's especially true for a program which is only a prototype.

GNUSTEP Projects and Applications

It is entirely possible to create a project manually using a text editor by creating a .m file to contain the Objective-C code and creating a GNUMakefile containing something like the following:
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = LogTest
LogTest_OBJC_FILES = source.m
include $(GNUSTEP_MAKEFILES)/tool.make

The above is also from the GNUstep manual.

It is also possible to create an application in Gorm (the GNUstep interface builder) without using ProjectCenter.

However, the normal way to create a project would be with ProjectCenter. ProjectCenter will create several files in the project, including AppController.m. This file doesn't get created when you start an application in Gorm instead.

One of the turorials I found on the internet did not show ProjectCenter creating this AppController.m file, but it was written way back in 2001, so evidently this feature was added since then. This is the tutorial linked from the gnustep.org web site, and it's quite disappointing that a more up-to-date one isn't available. Worse yet, there seems to be no other documentation for ProjectCenter other than a FAQ list.

Another tutorial mentions the AppController, but then since it has you create the application in Gorm, bypassing ProjectCenter, you end up having to create AppController.h and AppController.m in a regular text editor.

There is another program called Project Manager which is supposed to be “an alternative Integrated Development Environment (IDE) for GNUstep”. However, I have noticed that when I'm in ProjectCenter and go to edit code it uses Project Manager. It doesn't seem to matter how I set the editor in preferences. It always uses Project Manager as the editor. I assume this has something to do with the way that GNUstep has been packaged for Ubuntu. Unfortunately, I also have had trouble figuring out how to make the font bigger in Project Manager's editor window, so it is kind of annoying. Of course, you should still be able to edit the files yourself outside the IDE using vim or kate or whatever.

GNUstep Renaissance is an alternative way to develop UI's. It allows you to create GUI's for both GNUstep and Cocoa described by XML documents instead of using Gorm or Interface Builder. I haven't explored this too much yet. It kinda feels like a non-standard way of doing things and it seems like one should learn the standard way first. Also, I don't think there's any way to develop iPhone applications using Renaissance. (You can't develop iPhone applications using GNUstep either. However, you could prototype applications in GNUstep and later port them.)

Installing and Setting Up GNUstep in Ubuntu

Under Ubuntu/Kubuntu, it is quite simple to install GNUstep using the provided packages, but it is another thing to get it to work. The applications will run, but when you try to compile anything it won't find the required make files.

Before you can compile anything, you have to source /usr/share/GNUstep/Makefiles/GNUstep.sh or /usr/share/GNUstep/Makefiles/GNUstep.csh. I think the easiest way to make sure that this always happens is to put a file in /etc/profile.d, call it GNUstep_profile.sh and add the following line to it (requires sudo privilege of course):

. /usr/share/GNUstep/Makefiles/GNUstep.sh

Note that the location of the GNUstep.sh may be different if you install GNUstep from source.

Objective-C

The choice of NEXT (and by extension Apple) to use Objective-C is largely a matter of timing. Java and C# are both derived from C++, but Objective-C has no relation to C++. Stroustrup published his first book on C++ in 1985, the same year Jobs left Apple to start NEXT. At the time, there was, of course, no way of knowing which object-oriented language would become dominant. C++ compilers were not widely available until about 1992.

Fortunately, since Objective-C is also an extension of ANSI C, the syntax is familiar until you get to the object-oriented extensions, but at this point it is, in the words of one blogger, Alan Storm, “deeply, deeply weird”. The syntax for declaring a class and it's “messages” (instead of methods or member functions) is one of the weird things. Here is an example from the GNUstep manual (with comments stripped out).

#include

#include

@interface Test

+ (const char *) classStringValue;

@end

@implementation Test

+ (const char *) classStringValue;

{

return "This is the string value of the Test class";

}

@end

int main(void)

{

printf("%s\n", [Test classStringValue]);

return 0;

}

(This code goes in a file source.m.)

C++ basically duplicated the syntax of a struct in C and added member functions. In fact, if memory serves (it's been years since I've written any C++) you can have member functions in a C++ struct as if it is a class. Then Java got rid of the structs and just has classes. Objective-C took a different route entirely, adding syntax that frankly looks very out of place with the rest of the language. The @ reminds me of annotations in Java.

Not only is the syntax different but the message passing mechanism behaves differently. “The Call vs. Message Sending semantics seem, on the surface, to be the same thing, but my book has promised me there are subtle, yet deeply important differences. The first I’ve encountered is, an object will accept messages that haven’t been defined (it silently ignores them) whereas Java/C#/PHP5 would yell at you for calling an undefined method.” [Alan Storm] Objective-C is also more forgiving if you try to use a null (nil) object.

GNUstep vs. Cocoa

I recently became interested in the idea of writing iPhone apps when the client I was working for mentioned a possible future iPhone project. I wanted to start learning the skills needed for such a project, but didn't have a Macintosh. Then I discovered GNUstep.

GNUstep is a free implementation/extension of the OPENstep standard developed by Next (bought by Apple around 1996) and Sun (recently bought by Oracle) based on NEXTstep. (I initially assumed that the NS that prefixes so many OPENstep class names stands for “NEXTstep”, but some people say it stands for "Next" and "Sun".) Cocoa under MacOS X is also an implementation/extension of OPENstep. Both use the Objective-C programming language and both have an IDE and GUI builder. The main differences between the two are as follows:

• Cocoa is for MacOS only whereas GNUstep is a cross-platform system used primarily on Linux but also can be used on the Mac or even under Windows.
• GNUstep does not implement the Mac's Aqua look-and-feel for two reasons:

1. the original intent was to emulate the look-and-feel of the NEXT computers, and some people supposedly still like the retro look (really?)
2. implementing the Aqua look-and-feel under Linux might bring Apple's lawyers down on the Free Software Foundation

• GNUstep does not implement the UIKit classes required for iPhone development (UIKit has many classes that are similar to AppKit classes, but the UIKit classes are named differently, starting with IU instead of NS, and there are other differences).
• Cocoa is professionally and commercially developed and used by a fairly large community of developers where as GNUstep has not received much attention even from the Linux community.
• Cocoa is, of course, well documented by Apple and in a number of books that can be purchased from any bookstore. GNUstep documentation tends to be years out of date and incomplete, so you have to be willing to spend some time figuring things out on your own.

In the posts to follow I plan relate some of my experience as I start learning OPENstep in these different environments and move toward producing some iPhone application that I might be able to sell on iTunes.

Microsoft Security Essentials

I hate paying for anti-virus software. The last time I paid for anti-virus software was back in the late 90's. My computer at home became infected when I took a floppy disk to a school computer lab and later used that floppy disk at home. So, I bought IBM Anti-virus. IBM Anti-virus eventually got bought by Symantec and became part of Norton Anti-virus. I got a free upgrade to Norton and used it for a couple of years until they changed their licensing. A couple of times I bought a new computer and got free anti-virus for a year each time.

However, a couple years ago I was finally forced to decide whether to buy anti-virus protection or use one of the free programs that are available. In the meantime, spyware came along and the malware problem became worse. I started using AVG Free and tried various free anti-spyware programs, including Windows Defender from Microsoft and Spybot Search and Destroy. However, I continued to have problems with spyware. Then one day my laptop became very slow and I discovered it was caused by AVG. So, I switched to Avast. Unfortunately, Avast is big and slow, and Spybot is also slow.

Today I discovered Microsoft Security Essentials. Apparently, it combines something called Windows Live OneCare with Windows Defender to provide both anti-virus and anti-spyware protection. Combine this with Windows Firewall and we are finally at the point where Windows provides full security protection for free.

Symantec's web site said MSE has one of the lowest anti-virus detection rates, and, of course, I know Windows Firewall is only a one-way firewall, not two way like Zonealarm and Comodo. However, I also get tired of the constant popups from Zonealarm, and I get tired of my computers being slowed down by the security programs, so I'm going to give MSE a shot. Maybe it will provide "good enough" protection without being so annoying.

SGI is Back

I missed this a few months ago. Silicon Graphics, that great company that gave us the hardware that generated visuals for movies like Jurassic Park, is trading on NASDAQ again (as of May, 2009). I just saw this on the cool site SiliconBunny.com. They are also the original creators of the OpenGL standard, a cross-platform graphics API which pre-dates and competes with Microsoft's DirectX.

Rackable Systems, Inc. (NASDAQ:RACK - News) announced today the completion of its legal name change to “Silicon Graphics International Corp.” The company also announced today that it will change its NASDAQ stock ticker symbol from “RACK” to “SGI.” The stock ticker change has gone into effect for the trading community on Monday, May 18, 2009.

And in September they released a new workstation, the Octane III, advertised to usher in "... a new era of personal innovation in strategic science, research, development and visualization." Whether the hype is true or not, it's nice to see the company trying to make a comeback.

Back in my days as a Unix Admin in the late 90's, I worked on Unix workstations from Sun (both BSD-based SunOS and the newer System V based Solaris), SGI (Silicon Graphics, running their IRIX OS), NeXT (Stephen Job's company after he left Apple that later got bought by Apple and whose technology melded into MacOSX), HP (HP-UX was the first Unix I ever used back in college), and AT&T (I had the "pleasure" of working on an AT&T 3B2). I can definitely say back then SGI was the coolest computer company around. Unix techies and scientists were well aware of SGI, but they only briefly managed to get much notice from the general populace due to their computers being featured in Jurassic Park.

They had everything from personal Unix workstations designed for 3D graphics better than anything a standard PC could do at the time (this was back in the days when PC graphics cards were comparatively primitive) to "low end" super computers (they eventually bought out Cray, the original super computer company).

The new machine will not run IRIX. It will instead run "Red Hat or SUSE Linux (which SGI’s excellent ProPack enhancements) or Windows HPC Server 2008". SGI actually IRIX on MIPS processors in favor of Linux on Intel a few years ago, so this is not really a surprise. I wish I had the money to buy one, but these are definitely high end machines.

Oh, well. At least I can try fsv on my Linux boxes at home for that SGI/Jurassic Park nostalgia. If you're a Windows user, you might want to try StepTree.

The Totem Pole

I got an interesting e-mail. Actual company names have been changed.

"I had some interesting news you should keep somewhat confidential. The contractor rates at [Client X] went up again effective [date withheld]. But here's the real catch: only some contractors were given this benefit. Apparently, the managers went through some sort of vote on who should be allowed to have their rate back to the [original date] levels. I'm not certain how high level these managers were. My [Consulting Company A] recruiter estimated about 80% of our staff got the nod. I don't know about [Consulting Company B], but there's a few from [Consulting Company C] I had lunch with on Friday that had the same news to share. The consulting firms and [Client X] have to keep a lid on it, so we're not supposed to tell. I think it's pretty crappy the way they are playing favorites, and secrets like that never really stay buried anyway."

I can't be surprised about this sort of thing. The company in question has been having problems and has been trying to save money, but undoubtedly they lost some good consultants when they dropped their rates, maybe some of their best.

The decision process they mentioned reminds me of an old way of determining raises that was used at a company I worked for in the past. The process was called the Totem Pole. Employees were ranked by managers, supposedly based on performance. Their names were then placed on a graph as the x coordinates in order of this ranking, and their salaries became the y coordinates. They then did some least-squares method to draw a line which represented what their salaries should be based on this ranking. If your salary was above the line, you were over-paid and didn't get a good raise (maybe cost of living). If you were below the line, you were under-paid compared to the other people and would get a raise.

The whole process of drawing a pretty graph was all to make the whole thing seem more objective and scientific. The ranking, was, of course, highly subjective. In any case, if you don't get a raise in such a system you know that either they think you're already over-paid, or you are at the bottom of the totem pole. Either way is not good. If they think you are over-paid, you can kiss any raises goodbye for the foreseeable future. If you're at the bottom of the totem pole, you not only can kiss your raises goodbye, but you may be on the short list for the next layoff.

Still, knowledge is power. Once you know you're at the bottom of the totem pole, you can try to improve your ranking somehow. If you don't think that's possible because you're already performing well, you can just hope things work out or you can start looking elsewhere.

Yeah, I know. Doesn't have much to do with programming, but it's it's just one aspect of life programmers have to deal with in the trenches.

Test Code Generation

Yesterday I started evaluating a product that claims to be able to generate test code for you. As a Java developer, I am mainly interested in JUnit test code. I am a big believer in test driven development, but I often find myself inheriting code with low test coverage. So, the question is, are there tools out there that can help one quickly and painlessly generate test cases for under-tested code?

In a past job I used a product called AgitarOne that purported to do just this sort of thing. The tests that were generated, of course, captured the current functionality whether correct or not. It could not produce truly intelligent test code. Also, it was big and expensive and required a lot of resources. Worse yet, generated tests extended a proprietary class, so the more you used it the more you were locked into their product.

I tried to use a free tool called testgen4j, but I didn't have the patience to make it work. Its user interface is a Unix shell script. I tried running it under Cygwin, but found the script didn't like being run with JAVA_HOME set to something with "C:" in it. I may eventually try it again, but what I really want is something that runs as an Eclipse plugin.

With that in mind, I started googling, and I found something called CoView. This product offers a Community Edition and an inexpensive Premium License. I downloaded and installed the community license file and the Eclipse plugin. However, to my disappointment, it simply did not work. It got errors whenever I tried to go to the preference page to tell it about the license file.

With a little more googling, I found CodePro AnalytiX. This is a much more expensive product, but I thought I might as well try the 15 day evaluation. It turns out that AnalytiX is just what I would like to have. It runs as an Eclipse plugin, it does a fair job of generating test code, it uses EasyMock, and it does not rely on some proprietary base class.

Unfortunately, when I set the CodePro preference to always generate mocks for all interfaces, this caused it to generate some code that wouldn't compile due to duplicate local variables. Selective use of mock objects worked better.

I had a number of classes that extend JdbcDaoSupport. Even after enabling generation of Spring tests, CodePro couldn't generate usable tests for these classes. The generated tests all had comments that said: "An unexpected exception was thrown in user code while executing this test...".

I guess the bottom line is that these kinds of tools can be nice, but even the really expensive ones will never generate usable tests for all code much less optimal, intelligent tests. They are largely a crutch for people who do not have the discipline to do proper test driven development, and, unfortunately, not a good solution to low coverage on legacy code.

OS Wars and Plugin Woes

Personally, I'm a fan of Linux/Unix. I have to use Windows at work, because that's what they give me. Otherwise, I'd be using Linux as most anything I do on the job I can do just as well with Linux.

I do use Linux at home, but even there I am still sometimes forced to use Windows even though it is more vulnerable to virus attack and it boots slower (at least on my computers). The latter is in part because of all the extra anti-virus and anti-spamware software I have to run under Windows. I have found that because I have multiple people using my computers and home, including for game use, I get a lot of malware. I have to have multiple scanners installed and occasionally do a registry clean in order to keep them running fairly well.

One reason I am forced to retain Windows at home is because the majority of PC games work only in Windows. There is other software that also only works in Windows, but for the most part it can be avoided by using open source alternatives. Games are different. Every game is unique, and most game developers don't develop for Linux.

Another reason I have recently been forced to run Windows is that I couldn't figure out how to get HDMI output working under Linux. This could be my own ignorance and deserves more research as I see other people on the internet who claim to have gotten this to work just fine.

However, increasingly the reason I am forced into using Windows is because of browser plugins. There are two important browser plugins that are not available under Linux. One is Shockwave and the other is Microsoft's Silverlight.

Personally, I could live without Shockwave, but my kids play games that use it. However, I recently became a Netflix user, and I've found that their "Watch Now" feature requires a browser with the Silverlight plugin.

In addition, I have found that the Linux version of Flash seems to be slower than the Windows version. So, I can watch Hulu videos under Linux, but the quality of the experience suffers.

Some day I may switch to Macintosh. With Apple's computers you get a Unix-like OS, better support from software developers and hardware vendors, and it's not a difficult sell to all the iPod fans who are already familiar with Apple. Of course, the downside to the Mac has always been that it's more expensive.

Linux, by contrast, is free and runs well even on older machines. I recently installed it on an old machine that had been gathering dust. I plan to use this as an experimental web server running Tomcat. I used Xubuntu Linux, and was able to easily install Tomcat. It seems to work fine.

Games and Netflix are certainly not important to everybody. If you want to get up and running on the internet just to stay connected with your friends and surf the web on a limited budget, an older machine running Linux will work quite nicely. I recommend some flavor of Ubuntu Linux for all Linux installs (I have tried several Linux distros and find Ubuntu to be the easiest to install and maintain). Personally, I like Kubuntu (which runs the KDE desktop, Linux Torvald's favorite desktop) for newer machines and Xubuntu (which runs the XFCE desktop) for older machines with less memory.

Scrum vs. XP

I have worked on both XP (extreme programming) and Scrum projects. There has been a lot written about the differences between Scrum and XP. Here are my personal observations.

First off, XP follows a simple set of rules and practices which can be summarized in a single page whereas Scrum is so complicated that there is a ScrumMaster certification.

There is a perception that XP does not scale well to large projects. XP projects should have one team maintaining a single code base, because "collective ownership" is one of the XP rules. Scrum projects, on the other hand, may have multiple teams working on a single application with several simultaneous branches working towards different releases. Developers are then only allowed to work on the branch that their team has been assigned.

I have found that in such large projects people are afraid to make changes for fear of creating new problems. So, opportunities for improvement are ignored. Although Scrum may scale to a larger team, it will not fix this problem. It should be obvious that a large team will be less agile no matter what methodolgy is being followed.

Scrum does not require TDD (test driven development) or pair programming. In point of fact, many developers don't want to do TDD or pair programming and will resist doing so even after they've been told to. The larger a team/project gets, the more trouble you are going to have convincing people to change the way they work.

I feel that TDD and pair programming should go hand-in-hand. Developers who don't want to write their tests first will not do so unless they are paired up with other developers who are in the habit.

Developers who aren't doing TDD will resent having to write unit tests, because it is an added task which makes it harder for them to get their work done on time. So, they will not put much effort into them. Without pair programming, nobody will know the difference until somebody later has to maintain code with crappy unit tests.

Developers who do TDD will be testing and coding simultaneously and finish both at the same time. So, the testing just becomes part of the process and is not an added step.

In addition to helping to encourage TDD, pair programming eliminates the need for separate peer code review since the peer review is happening simultaneous to coding. By contrast, formal peer code review meetings tend to nit-pick and make the developer feel that she is under the microscope intead of the code.

Unfortunately, most developers will resist pair programming as much as they resist TDD. One reason is that they may not like having two people crammed into a cubicle designed to fit one person. The ideal pair programming workstation will have two monitors and two sets of keyboards and mice. Another reason is that they cannot check their e-mails and such when they are at another person's desk.

So, TDD and pair programming require a real cultural shift and encouragement from the top down. Usually the project managers and architects will have to force the issue.

However, most people do not understand the benefits of these XP practices and the tendency of managers is to think pair programming will require twice the number of programmers to accomplish the same amount of work. I would simply counter that if pair programming requires more developers, why is it that XP projects usually have less devlopers as per the argument that it doesn't scale well to large projects?

The fact that XP requires team members to work more closely together should not be a cause for concern. The word "scrum" is a term borrowed from the sport of Rugby. Unfortunately, the way software development usually works with the Scrum methodology is that team members get together for the daily scrum, sprint planning meeting, etc. However, then they are sent out to work independently on their assigned tasks as if they are not part of a team. The result is that the success or failure of the iteration becomes dependent upon the weakest link.

I believe that XP teams can accomplish much more with far fewer people with less risk, and it is entirely possible to do both Scrum and XP so that you receive the benefits of both. Companies could save a lot of money if they would really embrace the XP practices, but in all honesty it is not the easiest path.

Is open source killing Sun?+

Okay. I am going to ask some questions that might sound like heresy to fans of open source, but desperate times call for brutal honesty. We are talking here about a company which changed its stock symbol to the name of their popular but free language, JAVA.

I have always wondered, how does a company make money by producing something that they then give away for free? Of course, they do have their hardware business, but despite that, is it any wonder that Sun is going under when they give away so much for free?

Java: free programming language
NetBeans: free IDE
Star Office: not free, but Open Office version is free
Open Solaris: free Unix OS (which also has to compete against Linux, also free)

In fact, Dave Rosenburg of cnet news recently wrote an article titled "How Linux killed SGI (and is poised to kill Sun)". Amazingly, when talking about Sun, Rosenburg doesn't even mention Java. Java is like a 500 lb gorilla in the room that nobody seems to notice. However, he does say, "There is a vast array of Sun software that costs a lot to maintain but doesn't deliver much revenue. This is arguably the area in which Sun's strategy has been so off the mark." Could this be an indirect reference to Java?

Rosenburg then sites MySQL as Sun's best software, which is humorous since they only acquired MySQL just over a year ago. He says, "With the exception of MySQL, there aren't many Sun software products that generate significant revenue." Say what? Sun's stock has been going down ever since they bought MySQL in early 2008 for $1 Billion. Sun CEO and President Jonathan Schwartz was quoted at the time as saying, "MySQL was clearly the crown jewel of the open source marketplace. As far as we can see there are no higher value assets for us to be acquiring."

However, John C. Dvorak seems to have got it right when he wrote his opinion piece, "The Sun-MySQL deal stinks Commentary: Oracle is the only winner in this deal." John said, "... Sun cannot actually afford to spend a $1 billion on a company producing a mere $60 million in revenue and working outside its core competencies." I guess at the time Sun thought they were doing pretty good with a 4th quarter 2007 profit of $320 Million and could afford to expand, but these days they are in the red. (By the way, John also manages not to mention Java anywhere in his article.)

So, is open source killing Sun? Well, sort of. That and spending huge amounts of money on a stupid merger right before the economy tanked. On top of all this, it would seem that IBM recently offered to save them from the mess they got themselves into by purchasing them, but Sun screwed up that deal too.

Of course, IBM would love to be in control of Java and maybe that wouldn't be such a bad thing. In the wake of Sun falling apart, I can imagine a world where two or three different companies attempt to take over stewardship of Java, which Sun has made open source. It could be like the days when we had AT&T and BSD versions of Unix before Sun made the switch from BSD and everybody standardized on AT&T just before Linux came along to largely replace them all.

In fact, I am wondering... couldn't IBM save a lot of money by forking their own version of Java and letting Sun just die?

Meanwhile, Microsoft does have their own open source strategy, but as Sam Ramji, Microsoft’s Director of Platform Technology Strategy put it in a 2008 interview, "Our focus is getting OSS on top of Windows... And I’m focused on (providing) interoperability between the LAMP (Linux, Apache, MySQL, PHP) and Windows stacks." So, their priority is making sure that people continue using Windows even if they are also using Linux. They are not trying to make money off of open source. (Once again, no mention of Java.)

Honestly, I am not trying to bash (no pun intended) open source. I happen to be using Linux right now. Some companies like Red Hat have made good money selling support for Linux while contributing to its development. Red Hat is doing pretty well. They not only have their Linux but also have acquired JBoss, which they reportedly purchased for $350 Million. Was it really worth that much? I doubt it. However, Red Hat, as I point out, made their fortune on open source whereas Sun did not. So, maybe Red Hat knows what they are doing and won't make the same mistakes Sun has.