Building Blocks

Given my recent combining of Tracks and Shuffle. An interesting thing happened. Something that happens when you combine two products so that they inherit features from each other.

On Shuffle’s issue list there are a few items currently regarding repeating tasks, and the ability to hide a task for a period of time. Tracks has these features, since Shuffle can synchronize with Tracks, Shuffle now also have these features. That is if you choose to synchronize with Tracks.

I’ve done a few integration projects thus far. And the ones that are truly successful are when they take the aspects and features of both applications into consideration, to create a win-win scenario between the two applications.

Here is another recent example. At RemoteX, we recently integrated a system that handles the ordering of materials, goods, equipment etc. In essence this integration feature means that you can go to a retailer, order goods, specify the order they should tag the invoice with. End result, RemoteX automatically adds the goods to the application and if possible attaches a copy of the invoice to the case. Ready to be billed to the customer. Since the other system has integrated with almost all resellers of service equipment in Sweden, the daring customers running this set-up can, at least in theory, eliminates the need for keeping stocks of equipment or goods in house.

If you understand where these synergy effects can show up you can also align the integration so that both applications maximizes the gain of integrating with the other system. This is important to think of when designing an integration, how do we achieve the maximum win-win?

I learned a new way to test objects the other day.

We had a consultant over to talk about a TDD course he will be holding for RemoteX internally. During the discussion the suggestion to test an object by mocking the object itself came up.

What you do is, you use Rhino mocks (or similar) to create a partial mock of the object under test. What you override is the methods that will result in external communication.

This requires you to put all communication code in a single method, which you then override using the partial mock. The test then becomes, is the method for external communication called.

This reduces the amount of mocking code needed for more coupled objects, and also reduces the “IoC container for testability” need. Allowing the IoC focus to be focused on interchangeable parts.

I notice now that I cannot use the tag editor I’ve created from RemoteX Applications on my personal laptop. In requires a larger screen than what I have.

Anyway, this is a working version of the design I showed to mock-up earlier

Each row has a sub-class handling each option in the drop down (Strategy pattern). Selecting an option changes the available controls for editing the tag.

I ran into a designers block while working on a new feature for the online configuration editor for RemoteX Applications. (notice the name change?)

An interesting observation was that the risk for the design has shifted. In previous features I started with QUnit and the highest risk part, isolated it, TDD:ed it and got it working. I work with the same tactic now, but the issues have moved to different parts of the view.

Now the complexity is in the editing fields all of a sudden. Forcing me to start my testing on those components.

To unblock my designers block I used Balsamiq Mocks to draw up a UI. I hade a vague idea to begin with, and Balsamiq helped me finalize my thoughts into the following UI.

(Looking at it now I notice that I forgot the “Add” button)

I’ve been working on a JavaScript client for our REST-service. So far it’s an editor for Localization and pick list options. But I was on a roll!

So we charge by the amount of users each installation, lets add an easy way to calculate the amount of users. Download the list of users, and just count them. Pretty easy when then REST server is already in place.  To the right here you can see the end result of the view of the users. I did a similar one to calculate what we call resources.

While I was on that I figured I could add some graphs. I have a small thing for visual data. I found the JQuery Flot plugin, which suited my needs quite well.

I combined the flot plugin with our REST based search API and created some graphs. All cooked together I could produce a statistics view like this:

To finish things up I added the style used on RemoteX website, to get a consistent feel. This took some sweat, as the style sheet is generated HTML and CSS from dotNetNuke, and not exactly the same as my carefully handcrafted HTML. In the end I got it in and here is the end result.

In a previous post I mentioned that I started working on a localization editor for RemoteX Applications. This last week I started change a few things on the server side.

In RemoteX Applications there are certain combobox’es where you can change the content to customer specific lists. Previously they have been stored as XML files on the server, but this caused long process round trips for changing them. It also added cost to our Operations department at RemoteX. Currently were trying to reduce process costs and delays for our Operations to free up resources for tasks with higher value.

The list configurations are now stored in the database of the system, and is accessible through the REST service. Allowing me to create yet another web based editor.

This one was very similar to the first. Pick a list to edit, add or remove some keyword; then save.

The work was straight forward as it was so similar to the precious editor. The separation of concerns between the classes allowed me to just implement a few classes to get a first prototype up and running. The whole solution was completed in a couple of hours.

I added both editors to the same page, and quickly noticed one thing. If you changed editor you needed to enter your password and username again. This couldn’t do.

So I used the technique outlined in my other post about AJAX and Basic Auth, to add a single login dialog forcing the user to login when the page loads.

With some JQuery UI I got the above login dialog. Now the login state is available the entire duration of the “visit”.

I don’t realy know what to do right now, so I thought I’d share some of the latest work on RemoteX Applications.

RemoteX Applications has support for multiple languages being used in the same hosted installation. Basically we install a set of languages for each installation. Now most of our customers want to make some changes to the standard localization. These changes were made by our operations team, who would verify the installed language on each system installation.

While this is all fine and good, the problem is when we update the localizations. All of a sudden there is a lot of different customer specific language packs which needs to be updated with new keywords and translations. Others might need to be removed.

What we have done now is to separate out customer specific changes from the standard language packs. The operations teams can handle the standard language packs and the customer specific details are separated out and can be managed independently, thus not slowing down upgrade scenarios.

But it doesn’t end here, I finally got some use for my JQuery work for RemoteX Applications. I just completed a minor web application to handle the customer specific changes in an AJAX interface, talking with our REST-service.

RemoteX Applications Localization Editor

The screenshot above shows the interface. The editor allows the user to make changes to different languages on different applications. The interface displays the keyword, and the standard translation, allowing the user to enter his or her own translations in the text box.

Changing Localization details

The text box saves the override to the server. There are also options for adding new keywords, updating specific keywords without finding the specific text box to edit.

What is fun about this application is that the idea just popped into my head a few days ago. The implementation time is around 2 days of TDD work. There are roughly 84 tests checking the Javascript using QUnit.

There are two things I especially like with the implementation. One is that the separation of concerns was separated out quite nicely, this was greatly beneficial for the testing. I also noticed that there are some quirks in the interface which wouldn’t have been there if I hadn’t used TDD.

I had an idea of how I wanted to make the interface from the start. But my initial plan was to write it using WPF and host it in the Windows Client. However since I made this in JavaScript using JQuery the approach was a bit different. I’ll walk you through roughly how my plans evolved during the development process.

1. The greatest risk I was was with the XML generation which was to create the messages I sent to the server. To mitigate this I started by isolating this functionality in a “class”.
2. Once I saw that the tests were achieving the behaviour I needed from the XML Writer I started with the interface. I knew roughly how I wanted it, so I focused mainly on the behaviour. I work heavily with DIV’s, if I know I need to display something I add a DIV for it. This allows my to do formatting later as a separate step.
3. The third class was the controls for selecting languages and buttons for loading. I knew from the start that I didn’t want any logic in these classes, instead I wanted to create a Controller pattern to handle all logic. This turned out great.
4. The fourth class is where I started to notice some interesting synergies popping out from the code. The isolation level of the components allows me to reuse previous components to solve business needs through composition.
5. Lastly, the controller logic is tied in to complete the application. The controller mainly ties all the UI together using AJAX. Interesting to note here is that I tested the AJAX by mocking the AJAX calls. Previously I’ve tested AJAX for doing GETs by having a static XML document to fetch. Testing it with mocking was quite easy and allowed for different kinds of testing.

The editor is now tested to be working in IE8, Chrome and FireFox.

This August Microsoft wrote a piece on RemoteX Applications. The article highlights the benefits of Software + Services, and using Microsoft technologies to develop it. Being a central player behind the solution for RemoteX Applications, it’s always great to get the kind acknowledgement of the resulting product. Event if it is somewhat sales oriented.

The article is available here. If you want to read it yourself.

I’ve been working allot on RemoteX’s Windows Mobile application recently. The goal is to make it run faster.

I started using EQATEC profiler, as its the only profiler I found that can run compact framework and profile performance. The Microsoft provided profiler only profiles memory usage.

I started by profiling features in isolation, starting with the offline functionality. The reason I started here is because the data access is affected by the offline functionality. Secondly I start to test the user interface.

After some profiling I noticed a single method, which took between 1000 ms to 500 ms to execute. What was special about it is that I knew that this specific method was executed on the UI thread. It took some refactoring, but now it is changed to execute only if that part of the UI gets shown.

I also noticed that setting Form.Owner is an expensive operation, so avoiding it seemed like a good idea. For me it meant checking if we actually need to set Form.Owner before setting it.

End result, now the UI is much faster. The refactoring I made affected roughly 75% of all views in the application.

Today was the first day after my vacation, at work. Most of the time is spent on planning and discussions how we’re going to move forward with the product. But I did manage to get some code in place.

During the discussions we also figured out a way to deliver some value to our customers in a minor feature. The initial idea was to create an excel spreadsheet that could fetch the data needed from our REST service, to create a report. This isn’t what were doing.

Instead were allowing printing on some new entities in the domain, extending our printing feature to be able to produce the desired output. This was roughly one hours work for me, as the printing feature was built just for this type of extension. Along with a change-set I had I could also add the ability to print entities by right-clicking on the anywhere in the application.

Now the extension points working in a design is one thing. But the design of this particular feature caused quite a bit of commotion in the days it was implemented (It touched on breaking DRY, since the presentation models for printing were closely similar to the entities). So it’s comforting to see that the design is holding up even as the feature grows.