- 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.
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.
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!