Blog
Talk to the global leaders in fleet management, vehicle tracking and personal safety
Now that MiX Telematics has officially released our latest mobile application, MiX Fleet Mobile, we chatted to a developer to dig a little bit deeper into the interesting facets of how this product came to be and what makes it so special.
Chris van Wyk, takes the time to share his thoughts on the development of MiX Fleet Mobile App…
“First of all, I’d like to give a big shout out to the FM-Web team, who completed the project as I had been moved off to another product during the later stages of the development on the project.
The MiX Fleet Mobile App is the mobile offering product based on features from the flagship product FM-Web, our premiere web-based service for commercial fleet operators that services fleets world-wide.
With this in mind it does not take a lot of imagination to realize that this codebase has reached a substantial level of maturity and as a result has collected its fare share of legacy code.
What you must keep in mind with legacy code though is however best your intentions are, there are always areas within the system, which may be adversely affected by code changes and or additions. Thus, the development team had to approach all changes with precision and support a great deal of testing.
In addition to this, trying to introduce new approaches in development and architecture comes at a cost not everyone is comfortable with and or potentially willing to sink effort into. The approach we wanted to take going forward in terms of supporting the mobile applications on FM-Web was to introduce the mobile API as RESTFul services.
The challenge we faced was which framework to use while taking into consideration that the application stack is Microsoft based and predominantly using C#. Together with this, all existing web services were soap base and implements security and logging features specific to the solution. So if we were to introduce new services, these services would need to fit into the existing constraints of at least the security and logging features.
Having worked on a proof of concept project, introducing Ruby into the organization, the search was on to find a framework that would give us the same or similar benefits of Sinatra and Rack.
Enter NancyFX. The best way to describe NancyFX must be the following description taken from the projects website: “Nancy is a lightweight, low-ceremony, framework for building HTTP based services on .Net and Mono. The goal of the framework is to stay out of the way as much as possible and provide a super-duper-happy-path to all interactions.”
The selling point for me was the amazing balance the guys on the project achieved between the static typed and dynamic object world that exists in both the Microsoft.NET Framework 4 and the latest releases of Mono. Coupled with the implementation of pipelining and pre or post-request hooks snapping the NancyFX framework on top of the FM-Web business logic was as they say, taking “super-duper-happy-path”.
There are a number of things, which I am really excited about in terms of the final outcome of this project. The first is that there are open source projects in existence like NancyFx, which proves that the “we-did-not-build-it”, or it is not from Microsoft, mindset of the average .Net developer to be not entirely accurate. The second is that it is possible to devise simple and elegant solutions hooking into and extending systems sometimes thought of as “legacy” without rebuilding or reinventing the wheel, i.e. reusing security and logging features.
Lastly, and I would venture to say the most important in my opinion, that now having been able to introduce a RESTFul architecture into the FM-Web world and modularly exposing data as required, the possibilities for future feature rich mobile and web development is limitless and we look forward to pushing the boundaries to achieve the best development solutions possible.”
For the full press release visit http://www.mixtelematics.com/news/MiXMobileFleet.
Chris Van Wyk is a Developer at MiX Telematics in Stellenbosch, South Africa. He is currently focused on mobile development (iOS, Android, Windows Phone 7), Hypermedia driven RESTful APIs, Micro Web Frameworks and having fun with code.
This originally appeared on Sam’s blog, Inevitable
I recently gave a training session at my company on estimation techniques. Karen Greaves (a scrum coach friend) and I came up with the structure. She beat me to posting this (find details here) – so I’ll just give my results
Timing – at least one of the teams took the full 5 minutes for each game so there was no noticeable time saving.
The teams felt it was easier to estimate weight as they knew what animals and dogs were.
It was a good way to introduce the teams to point estimation. Usually inducing point estimation is done with only planning poker and in my experience teams get a bit hung up on trying to convert points to hours or days.
The guys who were in this session when compared to those who weren’t feel much more comfortable with the estimation process.
The ‘Affinity estimation’ game had all 4 groups with very similar points. Teams also only chatted about contentious issues. It was mentioned that if a team member wasn’t paying attention (or didn’t care) they could just go with the flow. Poker planning however forced each team member to have an opinion and thoughts behind it.
With the last game, Relativity, I did not give the teams a reference story. They noticed and pointed out how much easier it is to estimate when there is a reference.
The teams preferred Poker planning and Affinity Estimation to the other two techniques. They didn’t like the Relativity as they felt that the story points on the PP cards were not accurate enough (if you compare Elephant shrew to Elephant the largest ratio 100:1 was not large enough). I found this odd as that logic did not show in the Poker Planning or Affinity Estimation. The teams said they didn’t notice it in the other games.
Sam originally posted this on her blog Inevitable
