Building Blocks

Encapsulation is your friend. Nurture that friendship and it will reward you in the end. Neglect it and you will suffer the consequences.

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.

We have a document checked-in in the root of our source-control system for Applications. The document is the development principles we strive for. Most of them are basic, SOLID principles with highlights in how our code works.

Currently we’re focusing on automating the installation process for applications, the goal is to be able to handle a lot more installations without increasing the amount of people needed to handle our operations department. We’re removing a lot of manual error-prone steps, and were doing it using PowerShell.

Now my colleague is doing a lot of PowerShell work, and research, to automate different parts of the installation process. We identified that we needed to have a document to make sure that the PowerShell scripts follow guidelines just like with the rest of the code.

Now Johan has been doing a lot of work on this and we’re trying to get a lot of feedback on the guidelines. To increase the feedback we can get Johan has published the PowerShell guidelines on his blog. Please, have a read and any comment is appreciated.

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.

I have a good friend whom after university focused on first communication and then management. But now he has turned to development. We’ve been having a few discussion over the past few days about SOLID and REST and Grails. IoC containers and what not.

He hasn’t seen these kinds of concepts in his development so far. But he finds the concepts interesting and he is eager to learn about it. Which has given me a unique opportunity to learn how to communicate these concepts.

Now I’ve been an assistant teacher at the university. But I found that some of the benefits of these concepts are hard to explain, simply because to me their very abstract and I usually don’t discuss them at this level. I’d also like to mention that my friend is great at asking the right questions.

So this is a shout out to Joel. Thanks for teaching me how to communicate these concepts and their benefits.

We had a problem in RemoteX applications, not a big one, but an old structure that had to be refactored. Our open method only accepted URIs as arguments. This forced most of our commands that create new entities, to first save an empty new version of the entity to make it accessible by using a URI for it.

This in turn caused unnecessary round trips to the data access layer, but also caused problems with potentially empty data.

So this Wednesday this code died. In the old implementation; the general OpenView command accepted a URI. Now it can both take a URI but also an actual object.

To allow this I had to change the targeted end-point urls to activate a class instead of a delegate, as it was before. This has two great benefits.

• By using classes I open up for taking advantage of Castle for setting up the different code for opening. Previously all the setup was made in one big wiring class, resulting in excessive class coupling CA warnings on that class.
• Each class that opens an entity view conforms to SRP. It has one purpose, to open a view for a specific entity.

As I implemented the ViewOpener I noticed that all the delegates for opening entities had one thing in common. The first thing they did was to open the entity from the data storage.

By breaking out this behaviour into an abstract base class I could reduce the amount of code, simply by having the base class fetch the entity and then let the more specific view opener setup the UI.

This resulted in the structure illustrated below.

ViewOpener structure

So what are the insights of this refactoring?

Having delegates for a specified behaviour is a code smell. By having simple short classes with a single behaviour instead, we make code easier to refactor. Its easier to simply add another simple class to the Castle wire up, than it is to implement the same behaviour in a large complex class that handles all UI setup.