Code Retreat Sibiu
Primul Code Retreat din Sibiu va avea loc pe 28 Ianuarie 2012 si va fi facilitat de Costin Morariu. Daca sunteti prin zona, merita.
Detalii si inregistrare: http://coderetreat.org/events/code-retreat-romania-sibiu
20.01.2012 – Maria Diaconu’s Account of Agile Transformations
AgileWorks Iasi is proud to be the guest of Maria Diaconu, Lean/Agile Coach and the founder of AgileWorks Romania!
In her first meeting with our local Agile community of practice, Maria will share with us some of her experiences with Agile transformations in various companies.
We'll welcome Maria on Friday, 20.01.2012, 18:30. The location is yet to be established, so suggestions will be highly appreciated!
Global Day of Code Retreat in Bucuresti, Timisoara si Cluj
România este parte din Ziua Mondiala a Code Retreat! Bucuresti, Timisoara si Cluj-Napoca vor gazdui aceste evenimente.
Va invit sa va inscrieti la unul dintre ele cat mai sunt locuri. Inscrierile se fac folosind grupurile meetup corespunzatoare orasului (vezi sidebar dreapta).
Mai multe detalii despre code retreat sunt disponibile aici.
Evenimentele sunt sponsorizate de:
- Toate: Mosaic Works (tricouri, promovare, organizare)
- Bucuresti: Bit Defender (locatie, masa, after-party)
- Timisoara: ACI Worldwide (masa, after-party), UBIT (locatie)
- Cluj Napoca: Three Pillar Global Inc (locatie), ACI Worldwide (masa, after-party)
25.11.2011 – Case study – Agile/Scrum implementation at FITS
One of the key objectives of our Agile community of practice is to share experiences and learn from one another. In this respect and according to the wishes expressed during the retrospective we had two meetups ago, we open a series of case studies with a description of how Agile/Scrum is implemented at FITS.
Friday, 25.11.2011, 18:30, FITS - Str. Sf. Lazar Nr. 27, Et. II 217
How to avoid brittle tests when testing the service layer
There are many ways to test the service layer of an application. The goal here is to show how to unit test this layer in isolation, by mocking out the interactions with the database entirely.
This example will use Spring 3 for the dependency injection, JUnit, Hamcrest and Mockito for testing, but the technologies can vary.
The layers
The typical java web application will havea service layer, on top of a DAL/DAO layer which in turn will calls the persistence layer.
The Service Layer:
The DAL/DAO layer:
Motivation and blurring the lines of the unit test
When unit testing a service, the standard unit is usually the service class, simple as that. The test will mock out the layer underneath - in this case the DAO/DAL layer and verify the interactions on it. Exact same thing for the DAO layer - mocking out the interactions with the database (HibernateTemplate in this example) and verifying the interactions with that.
This is a valid approach, but it leads to brittle tests - adding or removing a layer almost always means rewriting the tests entirely. This happens because the tests rely on the exact structure of the layers, and a change to that means a change to the tests.
To avoid this kind of inflexibility, the scope of the tests will grow from the single service class to all the layers. Now, when testing the service layer, it's not the layer below that will be mocked, but the final layer which is directly interacting with the database - in this case, the HibernateTemplate:
Now the test only focuses on a single responsibility - when creation is triggered, does the creation reach the database?
The last test uses Mockito verification syntax to check that the save method has been called on the hibernate template, capturing the argument in the process so that it can be checked as well. The responsibility of creating the entity is verified via this interaction test, without the need to check any state - the test trusts that the hibernate save logic is working as intended. Of course that needs to be tested as well, but that is another responsibility and another type of test.
Conclusion
This technique invariably leads to more focused tests, which makes them more resilient and flexible to change. The only reason the test should now fail is because the responsibility under test is broken.
Check out the original article on baeldung.
Code Retreat
A code retreat is a one day free community event for software developers. The idea of the event is to remove all pressure and allow a self-selecting group of developers to experiment new and better ways to write software. It usually takes place on Saturdays.
The code retreat format is the following:
- one day event
- we work on a problem, generally Conway's Game of Life
- 6 sessions of 45 minutes, 3 sessions in the morning and 3 sessions in the afternoon
- during each session, we work on the problem in pairs and at the end of the session we delete all the code. Yes, really delete all the code.
- after each session we discuss what happened, change pairs and start over again
The problem cannot be finished in 45 minutes. If you do finish it, it means you haven't tried hard enough to write the best code that you can.
Did you know that the Romanian community was the second in the world to do code retreats, right after the first 2-3 in US? Since then, the format has changed and improved. Maria Diaconu and Alexandru Bolboaca were the first facilitators and they have helped improve the format.
What you learn at a code retreat depends on you. Usually, we touch on technical practices like:
- Clean Code
- Simple Design
- Test Driven Development
- Object Oriented Design
- Working in more programming languages, in some of them for the first time
- Functional programming
- SOLID principles
- and others, depending on the audience.
The typical agenda of a code retreat is:
- Start time: depending on the facilitator, between 8:00 and 9:30.
- Participants arriving, coffee, socializing – 30’
- Introductory speech by the facilitator – 30’-45’
- Session #1 – 45’
- Retrospective #1 – 15’
- Session #2 – 45’
- Retrospective #2 – 15’
- Session #3 – 45’
- Retrospective #3 – 15’
- Lunch – 90’
- Session #4 – 45’
- Retrospective #4 – 15’
- Session #5 – 45’
- Retrospective #5 – 15’
- Session #6 – 45’
- Retrospective #6 – 15’
- Retrospective of the day, group photo – 30’
- Optional, after party
Did you know that more than 20 code retreats were organized in Romania?
Photos from Romanian Code Retreats

History
Corey Haines and a few other people (Gary Bernhardt, Patrick Welsh, Nayan Hajratwala) thought of this in January 2009, at the Codemash Conference.
In May 2009, Maria invited Corey to speak at OpenAgile Romania. Alex and Maria met him then and learned about the format.
In June 2009, the first Romanian code retreat took place. It was probably the third or fourth in the world and certainly the first in Europe. Maria and Alex facilitated together most of the Romanian code retreats.
In January 2010, Corey came back to Romania and a code retreat facilitated by him, Maria, Alex took place. JB Rainsberger was one of the attendees. At that time, Corey had his ideas and we had our ideas. We discussed all approaches and came up with improvements. He helped us use a standard format for the code retreat, while we introduced a few changes: the final retrospective and the idea that the code retreat should not be focused on one single programming language.
During the Berlin code retreat in August 2011, Alex did the final retrospective in a different way.
So, the format is evolving. More than that, each facilitator has his own style. This is good, because it allows improvements.
More history: http://coderetreat.com/history.html
What makes a good code retreat?
The role of the facilitator is very important. He or she has to push the attendees, to make them expand their horizon. He needs to ask questions and try not give answers, but guide the attendees on a discovery path.
Bad facilities stand in the way. If the facilities are good, people won’t notice them and focus on learning.
In the end, how much people learn depends on them. The facilitator cannot push them harder and hope they learn more. Instead, he needs to keep explaining the principles of the code retreat and help them take advantage of the environment created for them.
4.10.2011, Code Duplication
One of the most important principles of simple design is to remove duplication. But what is duplication? What types of duplication are out there? Let's explore together the topic of duplication and look at some code samples to see how many types of duplication we can notice.
This meetup will be about code. If you don't write code, you might not be interested.
29.09.2011 – Real Life Agile Engagements – Discussion
Hi All!
I'd like to share some of our experience in working with a set of customers that are some of the largest financial institutions in the world. The interesting fact is that many of them demand agile development, are very aware of agile, have hired agile coaches and are moving towards agile on an enterprise scale (workforces of sometimes thousands of people).
I can give you a little history of how agile came into the picture for these companies, what are the advantages they see in agile and how a complex agile engagement in a complex environment works and the various ways in which Endava teams have dealt with it and the lessons we've learned.
When and where: Thursday, 29.09.2011, 18:30, Endava Iasi Strada Palat 3E, Palas, United Business Center, Etaj 5, Iasi
Thanks,
Andrei Postolache
Delivery Unit Manager, Endava Iasi
01.09.2011 – Iasi Agile Community Retrospective
We had seven meetings (!) already and it's about time that we take a step back and reflect on where we are and were we want to go with our Agile community.
When and where: 01.09.2011, 18:15 at FITS - Str. Sf. Lazar Nr. 27, Et. II 217, Iasi, Romania.
Teste bune, teste rele
De ce să scriem unit teste? Testarea automată încetinește ritmul de dezvoltare! Am scris teste, dar acum mai mult ne încurcă.
Acestea sunt doar câteva din întrebările legate de testele scrise de dezvoltatori. Soluția? Să înțelegem ce înseamnă teste bune și ce înseamnă teste rele.
Următoarea întâlnire din București (24 august 2011) pe teme de Software Craftsmanship va fi despre aceste întrebări. Vom discuta despre principiile de urmat pentru a avea teste bune, dar mai ales vom citi teste și vom discuta pe marginea lor. Ne vom gândi care sunt problemele și cum am putem îmbunătăți testele.
La finalul acestei conversații sper că toți participanții vor înțelege ceva mai mult despre ce înseamnă cod de testare bun, și își vor dori să exerseze mai mult. Și, cine știe, poate ne și arată ceea ce au învățat într-una din întâlnirile viitoare...

