We have just finished our first release of Omni Software Localization. The feature set is very basic and what the user interacts with seems very.. rudimentary. This is expected. Here are the features that are currently supported:

  • Upload Localizable Resources
  • Edit Localizable Resources (Current Supports PList only)
  • Select and Download Localizable Resources (Currently Implemented, but not accessible via UI)

This is a small, but high risk subset of our features. We also ran into a bug during development. We were unable to get Apache set up correctly on the Production server. Check @projectosl for updates on when we have fixed this.

In the next release, we are going to implement a user feedback system so that we can get feedback from everyone out there! That release is planned for November 3rd. So get ready to start giving us some feedback!

Lessons Learned

After the first release cycle, we learned a few things. Bugs tend to manifest themselves at the end of a cycle. Automation really does help with pushing to a test server and/or production server. Testing prevents bugs in refactoring. That our time we spent refactoring and cleaning code was not wasteful.


We didnít find bugs during development during the first 1.5 weeks. I think it is because of the mentality that ìweíll get to it later.î So, the bugs manifest at the end of a cycle. This is fine as long as we analyze and prioritize these bugs in the next release cycle (as we have done).


Automation is a life saver. It removes all of the pain and agony that happens throughout development. Our team has scripts for pushing to test server, pushing to production server, automated continuous integration, git scripts, and documentation scripts. These automation scripts mean that we no longer have to think about any of those operations. It reduces the mental load of development and allows us to focus on producing value.


I think this should be a given, but testing has been a positive thing for our team. We do not feel as if we have ìwastedî time on tests and have ensured that refactoring / adding features do not break existing code. Also, testing helps us manage dependencies.


Weíve seen the effects of refactored code already. The code is easier to read and manage. It also sets up a better design that allows us to add, edit or remove features from the system. For example, in our system, we wanted to have a more Mac-like interface. We changed no code in either the Models or the Controllers and only changed the View class for that particular object. It was a good feeling that we are handling separation of concerns well.

Software Architecture

Our software architecture is starting to take shape. It follows the MVC pattern but is slightly modified. A more detailed version of the architecture will be outlined by Chandler in the near future.


The following metrics were obtained from our metrics generating script.

Number of Methods: 63
Number of Tests† : 26
Tests per Method : .412
Number of Classes: 24
Methods per Class: 2.625

Our tests per method is way too low. Weíll hopefully rectify this in the next release. This is most likely due to the fact that a lot of our code is UI code which, as of yet, is untestable.

Our methods per class, however, is very good. It is hovering around 3 which is a good place to be. This means that classes are likely being responsible for only one thing.