This seemed like a no-brainer. SalesLogix is a Windows application, all the development tools run exclusively on Windows, and even though it does support a Linux database server (with Oracle) the vast majority of our customers are even running their database server on Windows. Nevertheless, Windows as a developer’s desktop has some serious issues (even more so for SalesLogix-specific development) and after realizing that I was spending most of my time inside of virtual machines anyway to work around 64-bit and IIS7 issues (and to take a break from Vista’s constant security nags), I decided to run a little experiment to see exactly how usable (or not) using Linux as a desktop for development of a Windows-based program would be. I loaded a copy of Ubuntu Linux on my workstation and started experimenting – I used the Linux desktop for email, web and editing, and used VirtualBox images for SalesLogix development.

The results? Well, they are in the title of the post! I don’t know if the Linux desktop will be a permanent thing on my home computer but it is definitely a big benefit on my work machine. It turns out that:

• Installation and updates is quite a lot easier thanks to the built-in package manager – no need to look for, install and keep up to date 2 dozens third party programs because everything is included
• The desktop has a few neat features that make it a perfect work environment – virtual desktops is the big one for me, it basically emulates additional monitors. The mouse focus is also nicer (you can get those effects with 3rd party programs and tweaks on Windows but not as well integrated). All in all the desktop is a bit more comfortable to me – could be because I was already quite familiar with it though.
• A lot of neat and actually useful toys that come with the box. For example, there is a widget to which you can paste images to send them directly to an image sharing site – it’s great for posting screenshots on the SLX forums. Or a sticky note app (there is one in Windows 7 too but it is not terribly useful for me as it can’t sync between computers). Again, because they come with the system I do not need to spend additional time looking for them and keeping them up to date.
• 32bit vs 64bit issues are non-existent – no “WoW64″ here. Oh, the sweet relief. I believe it was all worth it just to get rid of that nightmare.
• Git. Git is not that slow on Windows, in fact it is a lot faster than the alternatives. But the first few times I ran it on Linux it happened so fast I thought there was a bug and it was not picking up my changes. I am not exaggerating – a local git clone of a Saleslogix repo goes down from 30 to 2 seconds. The integration with the merge tools is also better (a lot better). So now when I need to do a big merge I bring the repo to my Linux filesystem, do the merge, and send it back. Words fail to express how much more pleasant this is.
• Warm fuzzy feeling from using an open source OS? Maybe

Now to be fair not everything is rosy… First of all be prepared for a fairly steep learning curve if you have no experience with Unix at all. To make things worse there are usually 2 ways to do most things – the “intuitive” way, through the UI, which takes a lot of clicks and is not always terribly reliable (though usually about the same as what it would be on Windows), and the “easy (not)” way, through the command line, which is very fast but requires you to know what you are doing. Even so, some operations require a bit of Googling and gentle coaxing – for example installing and configuring the NVidia driver for multiple monitors was not quite a point-and-click operation. A lot of the desktop functions are not extremely stable or polished – for example, the file browser crashes on me every few days, the UI stutters a bit when doing a disk-intensive operation (though it has no problem coping with the memory pressure of having 6 VMs running at a time, unlike Windows), Adobe Flash applications don’t always work fine, and because some of the fonts available on Windows are not present some web pages display incorrectly. And external devices are usually not “officially” supported – I have had good luck so far (I am actually able to customize all of my keyboard buttons which is better than what I could do in Windows, and my older scanner which does not have a Vista driver works fine on Linux) but I am sure esoteric USB devices or certain graphic cards might cause some issues. Well, these are the reasons I am still not quite sure I will keep it as a desktop OS for my home computer.

More importantly for work and development, while the integration with the Windows file shares is good, it is not perfect – sometimes I have to copy a file to my system, edit it, then copy it back. And I do miss Outlook (not that it is a fantastic program in itself – but the level of integration with Exchange is great). If I was using the Outlook calendar a lot I might be very unhappy – as it is I manage fine from my Blackberry.

My conclusion is not to encourage anyone to switch to Linux. Rather, an invitation to keep your mind open, as the ideal solution may not always be the obvious one!

PS: I opened an alternate blog at Nico’s Linux with the Linux-specific stuff, since it is not directly related to CRM.

One of the new possibilities I was pretty excited about with the 7.2 web client is that we can finally start using our standard source control tools (we use Subversion – very simple yet powerful) to manage revisions. It is still not perfect because there are a few tidbits that are hard to get out of the database but in practice I have not found that to be much of a problem (UPDATE – see below). What source control gives us is a nice, easy to use way of:

• tracking changes between revisions (i.e. what the heck did I break between last Wednesday and today). Also makes it a bit easier to apply the Sage bundle since I can apply the bundle and then use the source control to tell me what changed.
• archiving your source code (other than backing up the whole database, which can be a bit of a hassle to restore).
• collaborating on changes between users (i.e. if I am messing with something and Joe is messing with an unrelated feature, we don’t have to worry about temporarily breaking the website, since we are working on separate copies – though obviously we have to watch out when merging the changes back together).
• it also lets you have several projects against the same database (eg for experimenting with a new feature without having to set up a new database). And when you are done experimenting, you can toss it out, or automatically merge into the production copy. Anyone who has ever used the Bundler will recognize how wonderful that is!

Here is what I had to do to make it happen, like I said it was pretty easy once I found where everything was:

• In your “Project Workspace Manager” right click and select “Add”:
  
• Enter a meaningful name: the project workspace manager does not filter the list so you will have to be able to recognize it among all the other projects you might be working on!
• Enter the path to export, make sure it is on the local drive and not too long: some of the files in AA are pretty long and combined with something like C:\Documents And Settings\domain.user\Documents\Visual Studio 2008 Projects… well it gets past the limit pretty quickly as I found out first-hand.
• And finally, make sure you check the box to “Export Files Upon Creation”, and click “Create”:
  
• Now double click on that shiny new project to open it. Any change you make to the entity model or the quick forms will now be saved to the specified folder instead of into the database. There are still a few things pointed to the database, for example, the Sage.Entity.Interfaces.dll that is generated when you build the project, and the support files (which includes all the assemblies used by the web site). It is possible to get the support files out but not really worth the hassle – first of all it is a pretty big directory, a lot of it is binary files that will just end up cluttering your repository for no practical purpose, and secondly I prefer doing my changes by copying the files to a separate directory and modifying them there, this way I can see exactly what I am working on (I have a build script that automatically deploys them from there to the web site, but that is another story).
• You can now browse to the folder and import it into your repository using whatever is appropriate… for example with TortoiseSVN I just right click and import.

That’s it! One more thing I have to say if you are not familiar with source control is that it is even more fantastic when it is used with actual source code (as opposed to the XML form used by AA which is pretty verbose and automatically generated thus a bit harder to use in comparisons). This is where it really shines enabling you to see who did what and when and decide how you want to combine it.

UPDATE (2008-01-19): In light of a recent misadventure where I accidentally overwrote the database-stored VFS I would indeed recommend storing the support files into the source control as well. There is about 26 megs of them, and most of it is binary file, and they are not going to change often, but you know what, I’d rather know where they are. To do that, expand the portal (”Sage Saleslogix” or “Sage Saleslogix Customer Portal”), right click on the “Support Files” item and select Copy File. Select an empty target directory. Next, right click, select “Set Source Path”, and point it to your new directory. Check it into source control. There is STILL going to be some stuff saved into the VFS (eg the Sage.Entity.Interfaces file), but we’ll have to let it be for now. And the good side is, the base is going to be the same on all databases, so what I do is store the “Vanilla” 7.2.1 files in a specific path and have all databases reference to that same path. Then, I store the “delta” in a separate folder. I am considering doing that with the model too now (by storing it as a branch in subversion) but not quite there yet.

UPDATE (2008-03-17): On Saleslogix 7.2.2 you may get an error when compiling the platform, something that looks like “Unable to read snippet file, ‘\Entity Model\SalesLogix Application Entities\LeadAddress\.svn\text-base\Sage.SnippetLibrary.CSharp.@.07ffd774-6142-4b8a-a48a-09616effccea.codesnippet.cs.svn-base’. Unknown extension. Supported extensions are: .cs, .vb“. Sage tries to compile every file that contains “codesnippet” in its name. A small update to the Sage.Platform.dll is necessary to get past this – I may write more fully on the subject of how to patch the Sage libraries later but you can download the patched dll here (copy the dll to your C:\Program Files\Saleslogix\Architect\Platform folder) or the patched source code here (compile it with ilasm.exe).

Background-color set in containing divs causes some of the child divs to disappear, sometimes.

Come back here later on.

Check layout for PoolView with background-color set on tbodylt (on SEL)

Prompt for:
* Aggregate Root (eg SSSWorld.Common)
* Root Folder (eg …..\Projects\SSSWorld\Common\src\Common) -> should be same as solution??
* Sub-Namespace, eg Data for SSSWorld.Common.Data

Tool will determine final location: src\Common\Data
Set version in AssemblyInfo.cs to 1.0.0.*
Check the “generate documentation”