Already long time ago I was facing Spring and so I decided to prepare myself by some literature. First of all I found the „Beginning Spring“, which I already mentioned.

My ebook-provider suggested me another series for Spring: „Spring next generation“. I started with „Core Container„, which is already Volume 2. Scott Stanlick suggested for newbies also to read Volume 1 „Thinking in objects“. As the books are quite easy to read and even cheap I decided to study Volume 1 afterwards.

Scott has a very simple and direct way to focus on the main intention of Spring:

Elminating new().

Bring together, what fits best for the context.

He describes every chapter with pictures from the real world and the one I keep in mind is how he made me first of all understand this:

Imagine you go into a restaurant and order from the carte. Spring is the chef who brings together the ingredients from the restaurant with your desires. And this is called „Dependency Injection“. Brilliant!

For everyone even interested in good literature with very simple and clean code examples I recommend Scott Stanlicks series. Next I will try the „AOP“-Thing, as I have never done it before.

So I hope in some weeks I will give you a NICE Review of my core exam…

We planned a new environment with failover instances for application and database servers, upgraded application- and database management system, docker containers to improve and simplify „up-to-dateness“, bi-directional replication.

Everything implemented we had a little integration and manuel testing. Everything seemed alright. So we did the migration of the old system.

Next morning the system had gone. No more connections possible to the database.

We have thought about definite problems and had one day of try and error…

Resolution: Nothing!

Our manager decided to break the system back down. We have installed the containers with the old setup and brought in some load tests for penetrating the system for a while automatically.

Every successful test session (of at least 12 hours) lead to the next level. We are still in the process but have already found interesting insights…

Lets say you would like to do some Coding Kata. You have already found a lot of practices to do with your team but everything without functional reference.

Last weeks I did some Coaching with a team who want to do Progress in Pair Programming. They already did some technical stuff like the „String Kata“. My idea was now to give them a little Vision and some kind of User Story Backlog. After that we would have some sprints with changing pairs.

The vision

The idea is that your company plans to create a café for the employees. Currently they plan to hire no more employees, and so the customers to be served by an app.

The first Storys

According to the motivation bringing every sprint a shippable product here are my example Storys:

As a customer I want to order something.

As the barman I need a list of all orders to prepare them.

As a customer I want to get my order to consume together at my table.

Do you already see the acceptance criterias? They are not really necessary in this cata. Depending to what you put your focus on you can strengthen this or other parts.

Starting the first sprint

First of all we want to commit on the first storys. Acceptance criteria for our planning:

We can place order by order

All orders can be output in an ordered list.

Optional: We can add amount.

Optional II: We can add a table number.

Sprint duration is 30 minutes. Go ahead!

My insights

Depending on the lead in the Pair we found different solutions. Some of them started by doing object design and planing tables, orders and so on. Some of them really concentrated on test first. In my opinion you find each strength in the upcoming next sprints when you try to commit on the rest of the User Storys.

No insight without review

Absolutely obligatory is the review after the sprint to face each team the different perspectives.

I like to present you an alternate activity for estimating large backlogs in little time. The acitivity isn’t new at all but when i first tried it during the past days I felt so impressed that I like to share this.
Another reason for me is that I also added one feature which made it easier for the product owner to track discrepancy.
But first of all let us habe a Lok at the rules that i captured in German

The product owner will distribute all the Storys as cards to the developers. Storys Schuld bei Mixer and not Onlay one Eric to one developer.

Every participant / developer estimates each Story without conversation by comparing each other according its „size of functionality“.

After estimating the Story is pinned to the Slot with the corresponding „fibunacci count“.

Each Story gets a „post-it“ with the current estimate.

After all the Storys are estimated take a short break . Then go on and let each other estimate silently on the estimated Storys.

Make sure every moved story card received a new post with the current estimate. So even after finishing the product owner can always recognise Storys that have to be debated.

Bad written or unclear Storys are estimated to 100.

Second round is over when every one starts reestimating effort or all developers talk about other stuff. Second round is really hard, so don’t be that dogged.

Our insights

100 user Storys were estimated by 4 developers in the first round in 15 minutes. Second round took another 20 minutes. I prepared a chart to keep in mind the relation of the „fibunacci counts“ which helped very well.

Another point is the estimating unit „complexity of function“. In my opinion next time I will have an introducing round with estimating housewares as described by Boris Gloger.

My impression is great for really learning about the framework. You have very good descriptions (also about technical implementations) „Try it out“ – sections for all necessary topics. Excercices finish a chapter.

The structure of each chapter is as follows.

A Table of contents gives a listed overview with links to all topics of the chapter.

First a quick Introduction of at least 3 pages describes the theme from the specification to implementations and the differenciation by Spring.

A basic implementation is described shortly followed directly by a „Try it out“-section.

The „Try-it-out„-section has a step by step guide starting on creation of a maven project, doing configuration, implementing code until finally executing test applications. A „How it works“ part describes all the steps afterwards. „Try -it-out„-sections are written for all necessary topics in a chapter.

A Summary gives a resumé of all explained features of a chapter.

Following some Excercises on the treated theme can be executed. The solutions are found well described in the Appendix.

A Vocabulary table repeats all learned technical phrases or annotation learned from the chapter with a short description. This is the only fault of the e-book: The description column can never be fully read.

The book covers all the necessary themes for a first start with spring core elements (DI, JDBC, JPA, Security, MVC…).