Reasons for a new provider

The web application we are working on – Camping.Info – needed new server power. The site visits grow by about 70% each year, and there is much traffic especially in the summer months.

Our three “old” servers are at Hetzner. So, the easiest thing would be to rent another one there. But we had some not so good experiences with Hetzner. Yes, they are cheap and their service is ok. But we wanted better reliabality. One of our servers at Hetzner is restarting without any apparent reason (about twice a week).

Finding the right provider

So I took on the task of finding a new server hoster. Not quite easy, since the market is filled with many providers. We defined some requirements:

• data center must be in Germany, since our main traffic comes from Germany
• should have Intel processors, because they usually perform better
• should have at least 8 processors
• should not have setup costs, because we may not need the server after the summer
• should come with Windows Web Server 2008 R2
• should have sufficient bandwidth and high enough traffic limit

First I made a list of potential hosters: I looked in the iX magazine, and searched online. I also looked for websites which compare providers, but they were sparse, had limited information and few search options. After that I just brute force went to all the websites of (nearly) all the hosters and aggregated the information in this Google Spreadsheet.

Our choice

We then ended up renting a server at webtropia. I know, a slightly strange name for a serious business. All in all we are satisfied with our choice. The price is low, the server was shortly available, and we always have a separate connection to our servers (without RDP). A few drawbacks are worth to mention, though: The image of the Windows Web Server 2008 R2 had not the SP1 upfront, so we had to go through a lengthy update process. When we wanted to rent a second server, their purchase process failed to recognize us as a existing customer, so they had to put our servers together afterwards.

I think, after the summer we will probably rather discontinue one or two of the Hetzner servers, since they are older, have worse performance, and are not as reliable as the new ones from webtropia.

Yesterday I once again participated in a coding dojo – it’s been a while. These events are organized by the ALT.NET User Group Berlin.

We were 13 people. We formed three groups with one Laptop each. Each group got the same assignment – the tennis kata. It is a pretty simple task, which has to be completed in about an hour and a half with TDD.

What is interesting is not so much to implement the best solution. To me, it is more absorbing to see with what ideas the others in my group approach the problem, and their art and philosophy of coding. It’s always inspiring to see other methods performed live. Solving the problem is then more about finding a common language and agreeing on one solution and, if possible, on one coding style. It’s challenging to persuade the others that the approach one has in mind is a good one. The setting of four people per one computer enforces cooperation – a good skill to hone.

I like the coding dojos, and will try to participate again in the next one. Landau Medien was fine host – they provided their conference room and sponsored soft drinks, beer and pizza. Thanks also to Jan and Mike for organizing.

I have been again to the .NET Open Space in Leipzig. This time with my colleague Oliver.

I have written a Review last year. I want to take the opportunity to write what has changed in teamaton since then:

• We took a few steps towards a more agile development. We think these were steps in the right directions :). Since we started with two new projects, we could practice different approaches. I still haven’t looked closed at Scrum and XP.
• We implemented a good GIT workflow, even without the git flow software.
• We are by far more disciplined when testing – even though there is still room for improvement. Mark has automated many of our Selenium tests. We work much more often according to TDD. With our last project we started with SpecFlow, that is with behavior driven development.

Back to the Open Space of this year. I liked it. It was refreshing to see so many developer from the .NET, and talk to them. The first day was not as interesting regarding the sessions as the second day. The atmosphere was good – there were more than 150 people, many from Berlin, where our office is. Everyone could kegel, get a massage, and participate at different lotteries.

Here are a few topics, where I joined the discussions.

Message Queues (RabbitMQ)

I haven’t thought about message queues a lot. Yet, we do have an area of application for those: Sending emails from within a web application.

Why should one use MQs?

• separated systems – therefore a higher reliability of the different components
• scalability with all the pros which come along
• no waiting on feedback – important for long actions
• the queue is persistable – does not get lost in case of a crash

How does it work? One or more publishers push messages into a queue. There are one or more subscribers listening to the queue, and work off the messages. Publishers can push different tasks to different queues, which then are listened to by different subscribers. One can imagine a system of prioritization with this feature.

Tools: We discussed a small example with RabbitMQ (und EasyNetQ). We talked about the differences to MSMQ und NServericeBus. As it seems, RabbitMQ is more powerful (applicable to different platforms), but MSMQ is easier to understand for beginners.

Agile Development

First we discussed the division between ProductOwner and ScrumMaster. Then we talked about how detailed UserStories should be written out, and who should create them. All in all we concluded that UserStories should first be roughly described by the ProductOwner and then refined with the help of a developer while talking about the problem at hand.

As a takeaway I will try to promote more feedback meetings or retrospectives in our firm. We should compare more often our expectations and the reality and impediments. Many other firms organize estimation meetings, where they also define acceptance criteria – maybe we should do something like that, too. I want to look into Scrum, even though we are not enough people for this process, but there may be ideas we can apply to our little firm.

CQRS

There were a few sessions to CQRS, because it was new to many of us, and very interesting. Command-Query Responsibility Segragation is an architecture pattern, has many different aspects which for themselves are already patterns. It is also found under the name of CQS (Command-query separation).

It is (for me) a totally different approach at saving data and retrieving it. There is much emphasis on the thought process and the domain model. The patterns starts with the user and his/her actions, not with data objects. These actions are translated into commands, which are processed and generate events. These events are basically incremental steps to changing the state of the database. They are saved in an append-only database, so they do not get lost. These events can then be used to update denormalized databases where the views are saved. That way you can get fast access to the data you want to display to the user. (See also the CQRS-Website from Gregory Young with a long introductory video, and an article byMartin Fowler.)

We looked at a small Example (quellcode), where you can see that it does not take much to apply this pattern

I hope that we at teamaton will try this architectural pattern out on a new coming project. I like it a lot, especially the focus from the beginning on a sophisticated domain structure.

At last a few smaller things I ran into at the Open Space:

• As a developer you often come to point where you ask yourself: Should I use existing software or program it myself? We should try to estimate the costs without a bias towards self-development. We should try to analyze the existing software more thoroughly.
• I would like to learn more about REST and RESTful web-services.
• I will read through the articles on heise online “Clean Code Development in Brownfield-Projekten”: http://www.heise.de/developer/artikel/Clean-Code-Developer-in-Brownfield-Projekten-855114.html
• If you start with a Brownfield-Project, you first should write acceptance tests.
• I was not at the session about Software Craftsmanship, but I will look into this site: http://groupspaces.com/softwerkskammer.

Next year will be again a .NET Open Space in Leipzig: 20th and 21st of October 2012. Thanks for the Organization!

After listening to the interesting interview from Mark Phillips by Tim Keirnan, I wanted to jot down a few points which I think are important to us as teamaton.

• Project managers are not only there to distribute tasks. They should understand the customer and his or her needs. Afterwards he has to define goals for the project, and translate these goals for the different groups involved in the project (designer, developer, tester). Only after that has happened, can he transfer these goals into tasks.
• Most of the difficulties (80%) occur because they are weaved into the project from the very beginning. There needs to be a clear vision (definition is crucial) – otherwise there will be friction and competing visions.
• Work expands so as to fill the time available for its completion. That rarely happens in our team. Our difficulties arise from not making estimates and not having a fixed point for completion.
• Multitasking is not a good idea. One should concentrate on one project, instead of trying to push two, three or even more forward. If you have more than one project to work on, try to separate them (don’t switch during a day or even a week).
• Projects should be prioritized. So when time is getting scarce you know which projects can be halted to free capacities.

After that I looked at theTheory of Constraints and the five focusing steps:

1. Identify the Constraint:  We are now working more with Kanban, and are sure to see at which stage work is piling up.
2. Decide How to Exploit the Constraint: We try to distribute the work according to the load. We try to let the developers focus on programming, because they are usually the bottle neck, and give their other tasks to someone else.
3. Subordinate Everything Else to the Above Decision: We can be more effective in this step by defining precise priorities.
4. Elevate the Constraint: We are thinking, for instance, about hiring a student software developer.
5. If the Constraint Has Been Broken, Go Back to Step  1: We haven’t reached that step, but will keep that in mind – trying to better the performance of our projects.

We (teamaton) are beginning to develop a new web application, a ToDo-Management-Tool. It is our goal to be better at everything revolving around the process of developing this new application. Everyone at our company is diving into reading about and testing new tools and processes.

I took on the part of reading about different approaches to developing software, finding out about the pros and cons, figuring out which one probably suits best our needs, and gives us great power to develop the application effectively. I found the Wikipedia article on software development methodology, and went on from there to the different approaches.

Different Approaches

One approach is the Waterfall model, which is a sequential development approach with the following stages: requirement specification, design, implementation, integration, testing and debugging, installation, maintenance. This model assumes that all requirements are specified at the beginning. This is seldom the case.

There are many approaches which try to overcome the deficiencies of the Waterfall model. Seemingly all of them fall under the category of Software prototyping. Its main features are risk reduction, ease-of-change during the process, and involvement of the user.  For large projects some companies use Spiral model. Here the system requirements are defined in as much detail as possible to identify and resolve risks in the software development process. Our project is as yet not that large. Therefore we analyze risks only rudimentarily.

Rapid application development comprises many modern software development methodologies, like Agile software development, Lean software development and Scrum. The project is broken into smaller segments to reduce risk and provide more ease-of-change. Users are being actively involved in the process, and the software is build iteratively.

Iterative and Incremental Development Methodologies

Since requirements may change or the product owner may not now all requirements at the start iterative and incremental development methodologies are being used. The basic idea is to develop a system through repeated cycles of planning, design, implementation, testing and evaluation – and develop small portions of the software at a time.

One example is the Unified Process framework, which is iterative and incremental, use case driven, architecture centric and risk focused. Similar frameworks are the IBM Rational Unified Process and the Agile Unified Process.

Agile Development

Essentially we will use Agile software development. It allows for changing requirements, regular adaptation of the process, delivering working software frequently, getting feedback, and higher customer satisfaction. It promotes simplicity and trusting in motivated individuals involved in the process.

There is still much to learn about agile development. It is the superordinate concept for different software development methods like Scrum, Feature Driven Development, Extreme Programming. I will read about these in the near future. As a team we will need to adopt the mindset of agile development more thoroughly. The biggest mistake for teams using agile development seems to be to put implementation of the process over changing the way of thinking.