I wrote Firefox and Chrome extensions to get rid of it.

Unfortunately, I will not be joining Xamarin.

I’ve worked on Mono for a long time (nine years I think) and there are a lot of people on the team I consider good friends. I wish everyone at Xamarin the best of luck. They’ve got a great group of talented people.

(This was a tough blog entry to write, I could barely muster the energy to find a funny cat picture)

As for me, I am looking for exciting new opportunities. Either fulltime positions or contract work. So please email me if you know of anything.

Lots of people have been asking me about the future of Manos. As of right now its hard for me to make any promises. Manos has been getting a lot of awesome contributions from other people. So I am sure it will live on.

UPDATE: Just a couple updates regarding my employment situation: * Unfortunately, because my fiancee is in medical residency I can’t leave Boston for the next three years * I leave for my wedding/honeymoon in a couple of weeks and wont be back in the states until July 15th. * I don’t necessarily care if the technology I work on is .NET or not. I like most programming languages. What’s more important to me is what is being done with the technology.

Something really cool is happening at Mix this year. They are putting together a little party for open source projects called Open Source Fest. There will be food, recognition and prizes (hopefully ipads). Sorta like a science fair for OSS projects. Its a cool idea and its obviously being done to help stimulate the .NET Open Source ecosystem.

This reminded me of an idea I recently had to stimulate the .NET OSS ecosystem: Unleash Microsoft’s secret army of documenters on some open source projects.

Anyone that has ever used .NET has to agree that it has some of the best documentation of any software platform in the world. My understanding is that a lot of this documentation is written by a secret army of documenters that storm through the class libraries annotating every thing in site. I think unleashing this army on some popular .NET libraries would really stimulate those projects. It would make using the projects much easier, it would probably unearth some ugly APIs and would likely make contributing to those projects easier.

TODO: Insert well written paragraph about all the many benefits of excellent documentation.

Look at how awesome these docs are.

And look how bad these docs suck.

A lot of methods have been tried to stimulate open source projects. Giving away money usually doesn’t seem to help much. The Google Summer Of Code project has had some successes but there is no point in competing with that model. Obviously Microsoft doesn’t want to unleash their army of engineers on OSS projects as they do need to be careful about what code they are looking at. The cool thing about contributing documentation hours is you don’t have to worry about any issues of developers seeing code they shouldn’t be seeing.

It would be even cooler if MSDN offered documentation hosting. Imagine how cool it would be if while you were looking up the idiotic syntax for String::Substring you could swing by the Rhino.Mocks namespace and figure out how to properly inject your dependencies?

So thats my idea. There are no free jalepeno poppers and definitely aren’t any iPad giveaways but I think it really would improve the .NET Open Source ecosystem.

My apartment building is currently in the midst of a full blown elevator fiasco. An elevatopocalypse if you will. In an attempt at better understanding the problem I learned quite a bit about the elevator industry this weekend. Its actually a somewhat interesting industry (not as interesting as my other current reading topic though). It turns out that elevator industry shares some of the same problems as the software industry. Namely proprietary components and vendor lock-in.

First a quick background on how many elevators are serviced: Many buildings that contain an elevator have a full time maintenance contract with an elevator company that covers basically all repairs, preventative maintenance, replacing parts, emergency services, ect. So in the case of an apartment building, all elevator related problems are handled by this company, not your landlord.

When an elevator is first installed in a building the landlord takes bids from these elevator companies to install their elevator system and these bids include the maintenance contract. In software terms this is a lot like having a company build, install and maintain an email server for your business.

The problem is the elevator companies often use proprietary components that only they can service. Here is a quote from one of the better articles I read on the topic:

Original Equipment Manufacturers (OEM’s), as you may know, build elevator systems that can only be accessed by using a special electronic tool. These tools typically utilize patented or copyrighted and highly proprietary software to communicate with the elevator control system’s on-board computers. When such copyrighted software and special equipment is required to service an elevator control system the building owner has only one option for ALL future elevator maintenance and repairs — the original manufacturer.

Generally, the original elevator control manufacturer retains sole ownership of the required electronic tool. Purchase of the OEM’s special tool by any competing elevator service company is not allowed. As a result, the owner’s service contracts are limited to only one provider — the original equipment manufacturer.

As you can imagine this puts the building owner in a difficult negotiation position during an elevatopocalypse. You can’t just say “Screw it guys, you aren’t getting this done fast enough I’m taking my business somewhere else” because no one else has the technology to service your elevator. Meanwhile you’re getting tenants screaming at you on the phone and starting angry blogs. The elevator companies often give steep discounts on the original installation and setup of an elevator because they know they’ll have years of locked in support (whoops I mean maintenance) contracts.

On paper the original elevator bid using proprietary components probably looked like an amazing deal. It was cheaper than the other guys and came with a full time 24 hour maintenance contract! Wow, what a deal! Way better than using non-proprietary parts that don’t come with a support contract. But just like with proprietary software, you’re often left with your dick in the wind when things go wrong.

I think this serves as a good cautionary tale for the software shopper. Next time you say “But they don’t offer support” maybe that’s not such a bad thing. As with any business contract remember:

Sometimes you jerk off the bear, sometimes the bear jerks you off.

I recently read this awesome article on coming up with product names. The article details how Lexicon, a boutique naming firm, comes up with product names.

The basic process used by Lexicon is something like this:

• A team learns about the product
• The team lists concepts they’d like to convey with the name
• A number of teams with no knowledge of the product are asked to come up with words/phrases that convey those messages

Not having knowledge of the product is the key. When you have an intimate knowledge of something its hard to come up with those unique names instead of just describing the product. This is why software engineers often come up with names like File Saver Pro or Dog Picture Uploader.

As a single developer working alone its really hard to detach yourself and find those words/phrases. Asking friends doesn’t really work either because they often have background knowledge or want to have more info.

That’s where Fancy Hands comes in. As an experiment I tried using Fancy Hands to rename Manos de Mono. I’m not going to rename it, but I just wanted to see how it would work.

I sent a number of requests to fancy hands like “Please list the first 15 things you think of when I say the word ‘fast’” or “Name 15 activities that are performed at highspeed”. I also asked things like “List ten fast animals”.

That first round of questions led to some pretty good names. In fact they even came up with tornado, which is the name of the project Manos was originally based on.

In the second round of questions I asked for things related to tornados. They came up with Marvel which I think is a pretty cool name.

You might not use any of the names that Fancy Hands comes up with but I think at the very least it’s a really cheap way to help get the creative juices flowing.

Less than an hour after I blogged an ugly editor UI last week Jonathan Pobst sent me a nicer looking version. This is what it looks like now:

We decided to keep the save/cancel as real form buttons so you can still easily tab to the save button after editing.

We have a saying around the office that Mono is about making “happy developers” and we feel a big part of that is having excellent documentation. High quality documentation has become increasingly crucial now that we have so many of our own APIs and can’t just rely on MSDN. Things like MonoMac, MonoTouch and MonoDroid all require their own documentation.

So one of the things I’ve been working on for the last couple of months is productizing Kipunji and getting it to fit in better with our documentation structure. As we did this we realized that online editing of documentation would be a killer feature and allow us to create more and better docs.

Last night I pushed online documentation to monomac-docs. There are only a few of us that are authorized to edit docs, but we are planning on enabling a system that will allow non-authorized users to edit and submit docs soon.

Here’s a peek at what it looks like:

Over the weekend a totally awesome contributer was nice enough to get Manos running on Windows.

Here are the instructions he supplied:

Install Mono 2.8 (Optional)

Follow the Windows specific instructions on http://www.mono-project.com/download to install Mono 2.8.

This step is optional but you will need the Mono.Posix.dll and PosixHelper.dll when you want to compile a single Manos dll for both Windows and Linux/MacOS.

Install libev

Download the libev package from: http://software.schmorp.de/pkg/libev.html

Extract it and place it next to the libev in the source dir, so both libev-4.00 and libev are in the same directory.

Install Manos

Checkout Manos from github at http://github.com/jacksonh/manos/ and build/install it using Visual Studio.

If you do no have Mono installed you can define DISABLE_POSIX to remove the Mono.Posix dependency.

First off, for those that don’t know what Manos is: Manos is an easy to use, easy to test, high performance web application framework that runs on Mono. You can read more about it here.

Lately it seems like everyone is trying to install Manos on OS X, so I spent some time last night trying to install it on my macbook.

I think I’ve fixed most of the issues so its a relatively smooth process now. There are a few more steps than I’d like, but remember this is just alpha software.

So here we go.

Install Mono 2.8

Grab the Mono 2.8 OSX package from the Mono Downloads Page.

You need to have Mono 2.8 installed on your system. An older Mono install wont cut it. Also, if you’ve install Mono from source on your Mac, things might work, things might not work. This guide assumes you have it installed from packages.

Install libev

libev is Manos’s one native dependency. I installed this guy using macports:

sudo port install libev +universal

The key part of this is that we are installing the universal build of libev. If you leave that part out you could get a 64bit version and Mono won’t be able to load it.

You should now have a libev.dylib in /opt/local/lib/ to make sure Mono knows where to find that library, update your DYLD_FALLBACK_LIBRARY_PATH.

export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib

Install libev-sharp

libev-sharp is a managed wrapper around libev. The best way to install it is to grab it from my github:

git clone https://jacksonh@github.com/jacksonh/libev-sharp.git
cd libev-sharp
./configue
make
sudo make install

This will install libev-sharp.dll into your /usr/local/lib/libev-sharp directory and will also install a pkg-config file.

Install Manos

Now that all the dependencies are installed you should be able to build and install Manos.

git clone https://jacksonh@github.com/jacksonh/manos.git
cd manos
./configue
make
sudo make install

This will install Manos.dll, manos.exe and libev-sharp.dll into /usr/local/lib/manos. As well as a .pc file and a manos script for invoking manos.exe

Confirm your installation

You should now be able to run the manos documentation server:

manos -docs

and navigate to http://localhost:8181/ in your browser.

Trouble Shooting

1. If your build fails because libev-sharp isn’t found, you can manually copy it into your manos/build/ directory.

   erp:manos jackson$ cp /usr/local/lib/libev-sharp.dll* build/.

Note that you want to cp libev-sharp.dll* not just libev-sharp.dll. That way you’ll get the .mdb debugging file copied over also.

1. If you are getting a type load exception, make sure you have the universal libev installed:

   erp:~ jackson$ cd /opt/local/lib

   erp:lib jackson$ file libev.dylib

   libev.dylib: symbolic link to libev.3.0.0.dylib
   

   erp:lib jackson$ file libev.3.0.0.dylib

   libev.3.0.0.dylib: Mach-O universal binary with 2 architectures
   
   libev.3.0.0.dylib (for architecture x86_64):    Mach-O 64-bit dynamically linked shared library x86_64
   
   libev.3.0.0.dylib (for architecture i386):      Mach-O dynamically linked shared library i386
   

Another trick is to use Mono’s logging to see where Mono is looking for libev.dylib

 MONO_LOG_MASK=dll MONO_LOG_LEVEL=debug manos -docs

Hopefully all this works for you, if you notice any problems please let me know. Its my first pass at getting Manos running on OS X so its very possible I’ve missed something.

And remember there is a Manos de Mono Google Group

And you can follow the github project here: http://github.com/jacksonh/manos

Special thanks to Geoff Norton for answering all my ‘i dont get the mac’ questions.