When I grew up I had some issues with my back. Nothing special, more normal bad posture and spending too much by the computer. When I got my first RSI problems. I forgot my back problems until I talked to a therapist one and a half years ago that got me thinking about RSI as a secondary effect from bad posture and back problems. That’s the most important help I’ve ever gotten!
A while ago I started reading the book It’s Not Carpal Tunnel Syndrome! It helped me get more pieces in place. It’s by far the most important book for all computer users! Much of my own ideas and experience are similar to those in the book. Here are my three most important factors to beat RSI (all are presented in the book as well).
Get stronger in your back, shoulders and neck. By far the most important step has been to strengthen my back. If you’re back hurts it tries to tell you something. If you don’t listen, it might have to tell you through your arms. Three years ago I had never been to a gym. Now I’m a regular.
Do some high pulse work out. Not sure why it works but it does. The best explanation for this is that your muscles heals better if you get more blood passing them. If I have pain in my arms when I go running it disappears immediately. It’s so nice!
Care about your work place and work habits. Stop using a tiny laptop, get a good keyboard, chair, desk, mouse and monitor. Also try to make your work less intensive. Take breaks. If possible do pair programming. It not just helps you cure your hands but also produce better code. It’s a win-win! Stopped do instant messaging. Remember; it’s nicer to meet or call your friends!
The work included building a MetaModel for Service-Oriented Architectures (SOA) using DSL Tools and compare the results, both in the time it took to develop the MetaModel and the number of elements in our language, with existing studies on similar techniques (UML MetaModel extensions and UML Profiles).
Since no definition for SOA existed a literature review was conducted as part of the work. This resulted in a requirement specification for what elements that should be included in our SOA based on in how many different studies an element was mentioned.
The work was very interesting since no previous work on DSL Tools were available and that DSL Tools will become an important technique when developing software.
The fifth semester (at the IT University) I was part of a six person team that analyzed an existing application written for Mac OS X (in Objective-C), with the ambitions to reuse as much as possible of the application, though changing requirements for it.
The first requirement added, was that the new application (Socio) should be available on other platforms than Mac OS X. This requirement was achieved by building the new code in C# / Mono and embedding both the Mono runtime and the Objective-C runtime in a C application.
The second requirement added was to make the current monolith application extendable. This requirement was solved by creating a Plug-in architecture where the whole application runs as different plug-ins for the complete functionality.
The first thing that was done was an analysis of the current application followed by the creation of a requirement specification and architecture for this application (no requirements or architecture documents were available). Then we added the two requirements and created a new architecture that was implemented.
The hardest part in this project was to understand, learn and make all different techniques work together.
My roles in this project were as architect and developer.
The following artifacts were produced during the project:
Article – An Evaluation of Porting and Reuse Activities
The forth semester’s project (at the IT University), SEAGRID, was aimed to create a simulation of an automatic container harbor. The project was a mid size project with about 50 team members. To organize the project all team members where split into nine different teams, all with its own responsibilities.
I had two roles in SEAGRID where the first was as a team leader for the project team responsible for the network connection between all different nodes in the system. My other role was as a developer on parts of the network code. There are much learnings from being in such a big project, of which the most obvious is to realize how much work information and knowledge synchronization between different teams requires. Another learning is that the overall architecture and requirements affect how effective the organization works. A clear architecture is crucial to split the work load between different teams as early as possible.
Reports and source code from SEAGRID is available below: