Help Turn the “Jersey Shore” into “Silicone Shore”

SiliconeShoreWant to work with the latest technology on a self-directed team? Think you need to be in Silicone Valley to be part of a company setting the standard in cloud and mobile computing? Read on.

Marathon Data Systems, on the beautiful Jersey Shore, through our various vertical-focused brands, serves the people who provide the services that we all count on: HVAC, plumbing, lawn care, pest control, maid services, carpet cleaning, and more. We are in the process of building a mobility solution that will set the industry standard for field service worker and salesperson productivity.

Cross-Platform Mobile

Our new cross-platform mobile client is HTML5-powered and will initially run on iOS and Android devices. The technician or salesperson is continually operating on the latest information (no more periodic synchronization) and yet can be fully functional while out of network coverage.


The new mobile client is built in CoffeeScript on the Sencha Touch 2 platform. The combination of Sencha Touch and CoffeeScript making building off-line capable, singe-page applications actually pretty fun. Sencha takes care of the tedium of rendering just the right HTML to the screen for each device, while we focus  on building great user experiences.

Since WebSockets are not yet a reality (and pull-based applications are lame), we’re using SignalR to simulate server push from ASP.NET MVC (think Node.js scalability in ASP.NET MVC).

Message-Driven CQRS Back-End

DomainDrivenDesignOn the back-end we are are building out a scalable, event-driven CQRS system built around NServiceBus, following the principles of Domain-Driven Design (DDD).

In Domain-Driven Design, we recognize that the heart of the software is the domain-specific behavior that allows its users to solve their problems. We establish a vocabulary that spans across technical and nontechnical people. We iteratively tweak and adjust our domain model to better map to the problem space. We focus on building an effective model of our domain, while minimizing entanglement with infrastructure concerns.

nServiceBus_LogoNServiceBus (NSB) allows us to focus on the semantic meaning of our commands and events and what the system’s behavior should be. NSB handles interaction with queues, message routing, retries, and other plumbing-level concerns.


Data persistence is achieved through the joy that is RavenDB. If you think ORMs like NHibernate are good, just wait until you have built a C# application with RavenDB.

RavenDB is a high-performance, second generation document database, native to C#. Queries are made through LINQ. Joins and transforms are handled through map/reduce functions also written in LINQ. The impedance mismatch between object-oriented code and a relational database is not merely bridged, but is eliminated.

Agile Team

Agile can mean almost anything you want it to mean, but at Marathon, it means…

Agile at Marathon

A belief in the core values of the agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The Scrum process, where a self-organizing team works together to plan and deliver iteratively and incrementally.

The Extreme Programming (XP) practices of test-driven development, pair-programming, continuous integration, collective code ownership.

A commitment to software craftsmanship. Being a professional means a commitment to quality work and continual improvement. Great software comes less from particular technologies that come and go, but from fundamentals like the SOLID principles and object-oriented design principles and patterns that stand the test of time.

This job may be for you if…

  • You are good, but you expect to keep getting better.
  • You can do it yourself, but you’d much rather work together with a team of dedicated developers.
  • You love cool technologies, but you care about user loving and using your software more.
  • You love coding in C#.
  • If you are not currently test-driven, you want to learn to be.
  • If you are not currently pair-programming, you are willing to give it a try.

If that sounds like you, please send your resume to Come join us as we create great software to serve the people who serve the world!

11 Reasons You Want Mobility Experience Before Building a Mobile HTML5 Application


Two forces have converged: 1) Mobility has gone from an optional differentiator to an expected component of any software offering, and 2) HTML5 has been crowned as the solution that will solve the cross-platform problem that Java, Flash, and Silverlight failed to solve before it.

This collision of forces has turned HTML5 into a buzzword with a life of its own. In fact, it appears to be on its way to becoming as detached from reality as the all-time-champion of promising technology turned meaningless buzzword: SOA.

Don’t get me wrong, I believe HTML5 is the best current answer to cross-platform mobile software. Before recommending to my executive management that we build our cross-platform offering in JavaScript, using the family of features loosely known as HTML5, I looked at pure native, cross-platform native with Mono, frameworks like Titanium.  I made that recommendation before HTML5 became the cool thing to do, and I haven’t regretted it for a second.

A sure sign that a technology has reached fad level is when articles start to appear pointing out that said new technology will not, in fact, usher in world peace. Such an article was the popular 11 hard truths about HTML5.

The title was a little ominous and I began to read it with some trepidation, as we were still a couple of months away from being ready to ship our HTML5 client application. However, as I read, I was comforted by the fact that although all 11 truths were valid challenges, our team had faced and dealt with each of them.

The article lays out eleven challenges when building an HTML5 application:

  1. Security is a nightmare.
  2. Local data storage is limited
  3. Local data can be manipulated.
  4. Offline apps are a nightmare to sync.
  5. The cloud owes you nothing.
  6. Forced upgrades aren’t for everyone.
  7. Web Workers offer no prioritization.
  8. Format incompatibilities abound.
  9. Implementations are browser-dependent.
  10. Hardware idiosyncrasies bring new challenges.
  11. Politics as usual.

It’s a scary list, and they are all true. My team was able to handle and mitigate each of these challenges largely because we had years of experience building native mobile applications and desktop Web applications and much of what we learned there applied in the HTML5 world.

If you don’t have solid answers for each of these challenges, you really ought to get someone on the team who has confidence in dealing with each of them.

You can check my current availability here.

Free Your Data, and UIs are Free

This video describes how the Massachusetts Department of Transportation began publishing real-time bus arrival data and within two months there were six compelling applications available that harnessed that data.

Joshua Robins of the Massachusetts Department of Transportation

This shows that if you make your data available, there are legions of developers willing to build applications on various platforms. Massachusetts could have spent months building a lame Web site and then making the data available. By making the data available first, they didn’t need any UI at all.

It’s easy to see how this can work with public data. I believe this same principle works inside the enterprise. If we build our line of business applications to publish their data in open formats, anyone can build the applications that display that data to users in whatever formats users need.

HT: Jack van Hoof

Update Route Tables on Windows Mobile

Our dev team needed to do something that, evidently, very few people need to do… update the routing tables on a Windows Mobile device that is simultaneously connected to both WiFi and the wireless carrier. Internet searching was very little help, but we eventually stumbled across a nifty little shareware app called PocketLAN by z2 Software. If you are doing any advanced networking on a Windows Mobile device, PocketLAN is well worth the $14.99.

Desktop Developer’s Introduction to Compact Framework Development: Part 4-LINQ on the Compact Framework

LINQ (Language-Integrated Query) is supported on the Compact Framework. However, like with every other technology on CF, there is stuff you might that isn’t there. In my case, it’s LINQ to SQL. System.Data.Linq is not provided on the Compact Framework.

Also, contrary to some reports, the Entity Framework 3.5 is not provided on the Compact Framework, either.

Domain-Driven Design Friendly Persistence on the Compact Framework

I’ve been searching for a persistence tool that will eliminate the hand coding of our basic CRUD operations. I’m looking for something that allows us to develop our domain model in plain, unencumbered C# classes, and later persist them to a data store. Ideally, I’d like to use the same tool on both the Windows Mobile devices and on the server (just so we don’t have to learn two different tools or frameworks). This is the story of my pain…

NHibernate – The first and obvious choice for DDD-friendly persistence in .NET is NHibernate. It is a true object-first ORM and seems to have a lot of interesting tooling growing up around it. Alas, NHibernate is not supported on the Compact Framework because of some unsupported reflection it uses.

LLBLGen Pro – Developers who use LLBLGen Pro seem to love it. It is supported on the Compact Framework, but LLBLGen will not support an object-first approach until version 3.0 which won’t even beta until the end of Summer 2009, which is way too late for me.

Entity SpacesEntity Spaces is yet another commercial database-first ORM that runs on the Compact Framework. I don’t see anything that it offers that LLBLGen doesn’t offer.

Entity FrameworkEntity Framework is supported on the Compact Framework and is free but does not support any kind of POCO, object-first approach.

db4objectsdb4objects was an extremely intriguing option. I had never considered using an object database before. I found db4o extremely easy to use and intuitive—perfect for the lightweight storage needs we have on handheld devices. However, db4o is offered under a GPL or commercial license. The GPL license won’t work for us and the commercial license is orders of magnitude more expensive than a tool like LLBLGen or Entity Spaces.

Given that having our developers write all of the database access code by hand is (in my opinion) too time-consuming and error prone, I’m left facing some sort of compromise approach.

One option is to create my domain model as I need to, ignoring persistence. Then, within my repository implementation use a data-first tool, treating the “entities” generated by the persistence tool as DTOs and manually translate them into my true domain objects.

The second option is to again model the domain, but attempt to back into the code we need for those objects using a tool like EF or LLBLGen. The Patterns and Practices guys seem to think this approach is true to the DDD concept (see this article). I’m not sure I agree.

I think I’ll give a go at the second approach and fall back to the first if I see that the database schema, and not my domain, is driving the conceptual creation of my object model. I’ll also have to figure out whether to use LLBLGen or Entity Framework. EF is free, but LLBLGen is more mature and may offer a better option in the next version.

Desktop Developer’s Introduction to Compact Framework Development: Part 3-C++/CLI on Compact Framework

It may seem like a waste to have a whole post dedicated to a feature that isn’t there, but knowing this fact would have saved me some wasted mental effort and disappointment.

The Compact Framework is necessarily small. Microsoft only puts functionality into it that developers will be likely to actually need. This means that a lot of stuff you’d like to be there isn’t. This also means that you might need to interoperate with native code to do some of what you want to do.

If you are like me, this means you would like to use C++/CLI (the old-school .NET technology formerly known as Managed C++) to do that interop. You, like me, would be sorely disappointed. C++/CLI is not supported on the Compact Framework, and as far as I know there are no plans to add it. Prepare to P/Invoke.

Desktop Developer’s Introduction to Compact Framework Development: Part 2-Windows CE versus Windows Mobile

Sorting out the difference between Windows CE and Windows Mobile is the key to understanding the platform versioning (which can be very confusing). Here it is in a nutshell…

Windows CE is a set of modules that Microsoft releases for hardware vendors to build operating systems custom for their devices. Because these devices are so resource constrained, manufacturers don’t want to put any functionality on them that isn’t necessary.

It turns out that there are a whole bunch of devices that need about the same functionality, namely smart phones and PDAs. Instead of having each smart phone and PDA manufacturer build their own version of CE and add in all of the niceties that are needed to be productive on those devices, Microsoft offers Windows Mobile. In other words, Windows Mobile releases are instances of Windows CE specifically built for handheld devices.

The group that develops Windows Mobile is a customer of the CE group. The Windows Mobile releases always trail the CE releases and have their own (crazy) naming and versioning scheme. In the beginning, it was called PocketPC (first 2000, then 2002), then there was a split, as they offered Windows Mobile 2003 for PocketPC and Windows Mobile 2003 for Smartphone. PocketPC was optimized for a touch screen and keyboard while Smartphone was optimized for menu buttons and a numeric keypad.

With Windows Mobile 5 and 6 (which are found on most devices today), there are three flavors: Pocket PC without phone (classic), Pocket PC with phone (professional), and Smartphone (standard).

Wikipedia has a decent breakdown of the various combinations.

Desktop Developer’s Introduction to Compact Framework Development: Part 1-Introduction

As I’ve made my transition from the Microsoft desktop platform (x86, Windows, .NET, C#, etc.) to the world of handheld devices (ARM, Windows CE, Windows Mobile, .NET CF, etc.), there have been a number of fairly basic things that I’ve had to learn the hard way. They are so basic to being productive in the compact world that there ought to be a brief guide to bring an experienced desktop developer up to speed in short order. I didn’t come across that; so, I intend to provide that here for the next guy (or gal) who comes this way.

I am not an expert on this stuff (yet) but I am immersed in getting up to speed on them. So, I will introduce the important topics and point you to resources that I found helpful for the details.

The sorts of things I plan (so far) to cover include topic like… What is CE and how does it relate to Windows Mobile? What is the memory model on CE? What are the memory limitations and strategies for working within and around them? What do you have to do to run your .NET code on the handheld device? How do you do unit testing with CF code? I’m also going to document a few potholes that initially slowed me down.

Just so this initial post is not completely devoid of actual value, I’ll start with the most basic thing you need to know. Most handheld devices are built on a flavor of RISC processor called ARM (or Advanced RISC Machine). You can get a good overview from Wikipedia and the company view from ARM itself. While the primary measure of desktop processors is speed and throughput, the primary concern in the handheld world is power consumption. You learn that pretty quickly.