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.
Cyclists who stay close to the leading male and female runners, as well as the leading veteran runner will be equipped with tracking devices, enabling us to track the positions of those in the lead. Positions will be tracked using GPRS and displayed on a live map for monitoring. In addition, tracking of fleet vehicles, which include ambulances, emergency response and sweeper vehicles, will enable quicker response times and better vehicle management in emergency situations.
Our involvement at the Argus Cycle Tour and now the Two Oceans Marathon, are strong examples that demonstrate how our systems continue to link people to information, in a reliable and innovative way!
A story map is a high level view of the application being developed, from a user’s perspective.
Story Mapping forms part of Release Planning, and is an excellent tool for identifying the Minimal Marketable Features (MMF) for the next Release. This is done with the Product Owner, ideally before starting the development of a new product, and then before each additional release.
To prepare for the Story Mapping session you should identify beforehand:
The leader of the meeting, being a very abstract person in terms of approach to any subject, in the space of an hour taught me things that I am pleased to say will serve me well in my career in Scrum. In that session, Product Owners had brought some stories for “help and advice on” and actually take learnings from the discussion with this fairly gifted mind and go forth and conquer any business requirement thrown their way by the employment of simple guidelines. Alas, we move the great stones of the pyramids, with all our technology, slow…. even today!
Anyhow, I digress. Every time a story was read out to us that clearly needed some work, one simple response as it repeated enough times, began to resonate and strike that subconscious high-pitched note in my mind.
Whilst this is by no means the most powerful use of the latest innovation on MiX Mobile, our Camera View feature does allow you to find your vehicle in parking lots. In fact there are many other applications for this visually-rich positioning information also known as Augmented Reality (AR) such as Wikitude World Browser or Layar Reality Browser.
Augmented Reality essentially allows you to superimpose data such as location and status from your vehicle l via your camera view. This gives you a 3D view of where your vehicle is located as well as its current position in relation to you. You can simply follow your phone to lead you to your car.
Augmented Reality demo
Augmented Reality options
Since I’ve started at MiX Telematics I have become a self-confessed Apple fan boy. It all started with an iPhone and progressed to a MacBook. Nothing up to know has beaten the “unpacking” experience of each of these devices. The attention to user detail is really amazing. This post however, is not to convert people to Apple, but rather to show what can be done with some C# coding for the iPhone. Yes, it’s not a typo, C# code was used to write a basic iPhone application.
Objective-C, however much touted as user friendly by Apple, I have up to now found a cumbersome language to get into. Based on this and having followed the progress of Mono, the open source implementation of .NET languages such as C# and Visual Basic, I decided to invest some time in MonoTouch.
MonoTouch as described on the Mono website: “Create C# and .NET apps for iPhone and iPod Touch, while taking advantage of iPhone APIs, and reusing existing .NET code, libraries, and skills.” And I must admit, the last part of the above ”…reusing existing .NET code, libraries, and skill.” so far has proved to 100% on the mark.
I love agile games – they make learning fun and interesting. Also people tend to remember the lesson as they experienced it.
I did a kanban introduction game at work with our support team who are using Kanban and our Development team is using scrum. Most people dont know what Kanban is or why we are using it – so the aim of this session was to demystify the word kanban.
To start off with I briefly explained that Kanban meant “Visual Card”, and that it was a pull as opposed to push way of working, that it was responsive to change and based on Just In Time actions. I then went through the core concepts.
This originally appeared on Sam’s blog, Inevitable
So its one month later… what has happened?
After 1 week we started adapting the board. The first change we made was to add blocks numbered 1 to 10 in the todo column so that it was clear what was highest priority.
After 2 weeks some more board changes occured…
The second change was to move to a bigger board! We had all the issues that were being worked on pre-kanban on the board, but we excluded them from the limits on the columns. The result was a really messy board.
The third change was to introduce a “parking lot” column. Many issues were with customers or hardware, and they got “blocked” stickies but were holding up the process due to column limits.
The fourth change was to add a swimlane for “pre-kanban” issues. This way we could easily identify the issues with the current support team and those outside of the team.
All of these changes resulted in a much cleaner board, and made adhearing to (and noticing) the limits much easier. One glance at the board could now show bottlenecks easily.
After 3 weeks we held a retropective with a representative from each column attending. In order to get feedback from all people involved we also sent out an email asking everyone who was involved for feedback.
The questioned asked were:
General feedback – overall for the 3 weeks how did you feel about the new support process?
Select one:
Happy ………….. OK …………. Disappointed
Other comments:
What worked well:
What can be improved:
What doesn’t work:
Any suggestions:
Important to note is that everyone agreed that making issues and bottlenecks visible on a board works well – better than any previous attempts at managing support items. YAY!
Looking at the data collected we then used dot voting to highlight which problems were most important to the group and thus needed to be addressed first.
These were:
Clearing the backlog – Currently the backlog items are piling up as we are limiting how many issues the support developers can look at.
Knowledge Transfer – There are a handful of developers with loads of domain knowledge. As such they do more or less everything around those domains. We need to start the painful prcess of transferring this knowledge. Naturally as the domain expert is not doing the actual work it will be slower. The suggestion here was to try dedicated time from the experts – 2 hours a day for 3 weeks.
Support Process Flow – documented. Whilst the kanban idea was explained to the first group of developers going through it – it has not been explained to the second group, so they were a bit lost for the first day or so. Also the testers in the support team have never worked in an agile way so the stand up routine is still a bit odd to them. We agreed to do a basic diagram of how the board works and what each roles responsibility is. This way anyone can look at the diagram and quickly come to terms with the new process.
One additional small item was actioned:
Template for sticky – each sticky on the board looks slightly different – and it does get confusing. We will put up a template (start date top left, end date top right etc) for people to follow.
Our standup process has changed. We were going around the group – each person saying his bit but that meant jumping around all over the board and it was very confusing. After attending a Kanban course our Support Manager made the suggestion of starting from the last column and addressing all tasks there then working our way backwards to the first column. This is much better!
Moving from right to left emphasises the PULL of kanban, we are also able to discuss blockages in any of the columns as soon as we discuss the column rather than waiting till the end of the stand up. After some internet searching I came up with a new format for our stand-ups. This is now printed up on an A3 paper and stuck up next to the board as a reminder.
Another contentious issue is when to do full solutioning, when to apply a quick fix and when to add a change required to the product backlog for the development team to do. We have decided to have this discussion after our first column (Dev Analysis) and present the choices with pro’s and con’s for the Support Manager to decide on.
To add a bit of fun to the board I created South Park characters with some space to scribble your name underneath. We have 3 of each character. So each person on support can pick one that personifies them, add their name to the bottom (it wipes off) and stick that on the tasks they are working on.
We started with 3 developers rotating through support for the duration of a sprint. The idea is to balance this evenly between all 6 development teams and rotate amoungst them so that everyone gets a turn to be in support.
We’ve had some good days and some bad days. All in all, based on feedback and observations we are all getting more comfortable with the new kanban process, and starting to make it work for us.
Our Communications Manager, Tammy recorded this video at the launch of the first ethanol-powered bus in South Africa on the 12 October, which will reduce carbon emissions. MiX Telematics and Scania tested the exhaust fumes on a white handkerchief in the video below.
What are you doing to reduce your carbon footprint?
