Continuous Integration for (non)hipsters

Continuous Integration? Soooo ooold, so ninetees. Not hot anymore, not trendy. Currently even Continuous Delivery sounds like something regular, typical, borig. Everybody does CI... or do they?

In order to answer this question, let's refer to the excellent article, published by Martin Fowler here. Headline states:

Continuous Integration is a software development practice where members of a team integrate their work frequently (...). Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

That's it.
Code (yes, this includes tests!)
Commit.
Pull/push (integrate).
Let something (a CI server for instance) run tests and confirm that everything is in order

Four easy steps. However, the devil is in the detail.

First of all, the steps should be executed at least once a day, preferably multiple times a day by each team member. This way, any integration issues will be discovered on the spot. If your team has a habit of keeping private branches for a long time, without source integration and pushes (triggering a full CI build), well, you're not doing CI! If you use feature branches, which are a good thing, keep them public, so that CI server can watch them during development time.

Second of all, tests are the cornerstone of CI. Usually not all tests are run during build - in order to make it faster, only quick, small unit ones. If project build isn't fast, developers won't build before pushing changes (we're all always super busy, aren't we?). Therefore all expensive tests - especially integration ones - should be left for CI server. It's a general rule for a bigger builds. This way if an issue fits into this 1% not covered by unit tests, it should be found by the end of the day. By the way it's really a good habit to have a blame mails enabled in the CI server. The name is a bit misleading - it's not about the blame, it's all about fixing broken build (or bad tests!) as soon as possible.

All of what was above can be found in the aforementioned Martin Fowler's article - in a more elaborate way. Yes, it's a quite old one, but still very, very relevant.

GeeCon part two

A little late (almost two weeks!) but finally completed. Second day of GeeCon (https://www.geecon.org/). How was it? Continue reading to find out.

Improving Java EE with reactive - Ondrej Mihalyi

The presenter started with an outlook of what "reactive" in terms of a web application really means. The idea he focused on was that in order to improve the latency, execution of a request should not block - never, even on I/O. Also, in order to utilise the resources (CPU) as efficiently as possible, there should be ideally as many threads running as there are cores in the system. In a typical, J2EE based application, there goals are impossible to achieve, as each request is served completely by a separate thread which blocks if there is eg a dependent service or a DB call. There are however libraries that can help to make such application more "reactive". In his demo application ("cargo"), Ondrej showed how to use built-in Java 8 CompletableFuture or external RxJava (https://github.com/ReactiveX/RxJava) observables in order to avoid blocking the execution thread. He also mentioned (although he was short on time) that the UI part should be improved as well by using technologies like WebSockets or CDI events.
Whole presentation was quite good content-wise. It was nice to learn how a performance can be improved in an existing application by refactoring it to use some "reactive" stuff. The presenter could improve a bit on a technical side. Keeping an eye on the clock and minimising "live coding" favouring ready, refactored examples would make whole presentation better from reception point of view.

Reactive Spring - Josh Long 

START. DOT SPRING. DOT IO. I could write that this was the second "reactive" presentation, taking on the topic from new Spring library perspective. But no, this was not an ordinary presentation. This was a show. A Josh show. The topic itseflf is very interesting and the Spring implementations are interesting (and impressive) as well. Reactive versions of repositories (Mongo DB implementation here), Reactive Streams (Subscriber, Publisher, Processor) and Reactor (Flux, Mono) concepts, Web Sockets or Server Sent Events for publishing. They even have (in the upcoming release) a reactive, non-blocking security! I had however a strong impression that Josh would be able to make an interesting and involving presentation on any topic... even PHP ;-) Besides strong interest in the Spring reactive what took out of the presentation is - START. DOT SPRING. DOT IO! :-D

Microservices - stages of maturity - Jarosław Pałka / Jakub Marchwicki

The multi-threaded presentation run on two cores in parallel ;-) It was a mixed one - a bit about the main topic (microservices), a bit about a working in a tech organisation. The microservices-oriented part dealt a bit with such principles as being event-driven (publish, publish, publish!) and asynchronous, even in terms of application logging. Also, the Customer Driven Contracts for better APIs were mentioned. The message from the presenters here was that many of the microservices world ideas can be applied to the world of monoliths. The organisation-oriented part was, from my point of view, much more interesting. Jarek and Jakub said many things that may seem obvious, but need to be stated aloud from time to time, just to remind everyone about them. Amon others, the words of wisdom I remembered from the presentation were:
- legacy products - usually nobody to work with these, but usually these are the ones that bring MONEY!
- 3rd Newtonian law of management - if you push people, they will push back even harder
- ignoring the infrastructure is a wide road to failure
- developers should be assigned responsibilities, not roles
- during development focus should be on building a resilient system, not a perfect one
- in general, it's better to fix what's failing than on blaming others (famous "witch hunt")
- never ever do any manual changes on production - if you need to, your product is crap ;-)
Overall, I liked the presentation, especially that my work experience results in similar conclusions as voiced by Jarek and Jakub.

Consumer-Driven Contracts to enable API evolution - Marcin Grzejszczak

Consumer-Driven Contracts is the pattern to enable service evolution, as described by Martin Fowler (https://martinfowler.com/articles/consumerDrivenContracts.html). In his presentation Marcin focused on how CDC can be enabled for a web application using Spring project called Spring Cloud Contract (http://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html). The idea behind is quite simple - allow writing Contract on an API using a statically typed Groovy DSL, that can be later on automagically converted into stubs used for (client) intergration testing (in a most hyped microservices architecture ;) ). As an added bonus, the same tool will generate (server) acceptance tests out of the same Contracts.
To make long story short - easier decoupling of services for testing and less boilerplate code provided by one nice tool. I like that! :-)

To sum up - this year's edition of GeeCon was both entertaining and educational. I learned few new things, I met some friends from good old days, I ate some cookies. One of the most important aspects for me was an opportunity to see how different things are done in different companies. Having a broader overview is never a bad thing!

GeeCon has arrived! Day one

GeeCon 2017 is finally here!. Packed with presentations, ranging from higher management talking about how organisations work in a big picture to a "geeky" CPU internals. Everything in a Multikino, providing what's needed for a presenter (and attendees) spiced up with a really good catering. 

Here's my very short report on what I saw today.

Keynote - David Moore

A very interesting presentation, especially taking into account that usually higher management talks are a bit.. boring (so to speak ;-) ). He talked about approaching refactoring / replatforming on an organisational level. Most of his observations were exactly aligned with my experiences, both concerning things that work and things that don't.
What is worth remembering is Convay's law - "products mirrors organisations". Tech organisation with bad communication or bad structure will always create lousy products. Period! Leaders of any sort should also take with themselves the statement that their role is usually to hire great people, trust them, let them loose and get the hell out of the way ;-)

Caching - Michael Plod 

General introduction to caching in typical business web applications, that is applications that can't allow "eventual consistency". Some basic concepts (local cache, clustered, distributed, local off-heap), some examples, some real-world cases (issues). Overally, nice presentation from both technical (way the presentation was delivered) and meritorious point of view. Some (salut, Grzegorz!) would say that nothing new / leading edge was presented, but in my opinion it was worth attending anyways. Perhaps the title - "best practices and gotchas" suggested something different, that is much more detailed, technical presentation? I personally especially liked that whole speech was focused around what basic questions should be asked when introducing a cache into a system and how these should be answered, step by step.

Last but not least - quoting the Author, remember that a cache will not solve performance issues of an application - first optimise, than introduce local cache, then eventually a distributed one (to tackle scalability issues etc.). And never ever implement your own cache! :-)

Domain Driven Design - Cyrille Martaire

Brief introduction to DDD, mixed with funny cats and some jokes (5 minutes into presentation - we're done, thank you!). Basic concepts (ubiquitous language, Value Objects, Bounded Context). Some examples to help the audience visualise the ideas behind DDD. From my perspective the presentation lacked a clear example, comparing small application (MVP) written with and without DDD. Such exercise would be very helpful to see a value that can be brought by introducing DDD and which problems can be solved. Then it would be much easier to decide if benefits outweigh additional costs.

How SCRUM moved away from developers - Matthew Brylka

By reading a title - and just a title - I understood that the presentation will be a critic of SCRUM implementations in many companies, where the process no longer helps deliver value but s rather a good excuse for added paperwork loved by all sorts of bureaucrats. What I got instead was mostly overview of SCRUM principles (with some emphasis on what is not there) along with particularly interesting "how to succeed" section. Two thoughts from the presentation to be remembered:

• Use agreements with stakeholders instead of contracts / demands
• Technical excellence, debt backlog and refactoring are constant practice - every manager should understand this, instead of pushing refactoring further, deprioritising it or asking for a separate, estimated task (that could be saved in the backlog forever)

After this presentation I got an impression that besides developers also line managers and allmighty architects of all sorts should attend the GeeCon conference! ;-)

Developer Plantations - Wojciech Seliga

Writing code (aka "coding") is becoming a commodity. Soon everyone after few months of training will be able to write *something*, just as now literacy is common compared to XIX century. In order to stay ahead of the crowd, we (meaning - skilled engineers) need to understand why is a product created, besides knowing how and what it is. These are main thesis for the future of our industry. A bit of a "lifestyle" presentation, without any technical aspects. Worth listening to just for a glimpse of a different perspective (different than another tool, library or architecture).

To sum up - an interesting day. On day two I plan to attend some more "technical" presentations. Stay tuned!

Is software development akin to ice cream making?

Surprisingly much more than could be suspected.
As nicely explained by Martin Fowler on his blog here, famous ThoughtWorks "stole" its operation model from a ice cream company. He describes the model as founded on three pillars. They're as follows:
1. Sustainable Business - this one is fairly obvious and boils down to "you need money to survive in business". However, one special thing is noted by Martin: "revenue is like oxygen - you need it in order to live but it isn't what you live for". I like it :)
2. Professional Excellence - seems to be obvious as well. One should always strive to do the best possible job. What's interesting, Martin argues that this sometimes involves *not doing* what customer wants. Particularly, he elaborates about features that don't pass their (internal!) usefulness evaluation. Now this is something different than I've experienced! Additionally Martin claims this pillar includes improving not only how his company works, but also the industry as a whole. He believes that if his company invents/finds something interesting or makes a breakthrough, it should share. My belief is that some *big* IT companies could benefit from this pillar a lot.
3. Social Justice - contrary to the first impression this not about giving out stuff for free ;) It's rather another incarnation of (in)famous Google phrase "don't be evil". Martin's explanation here is that a company should care more than simply "if they pay we will do". He strongly advises that each piece of work done should be valuable to customers and society. What surprised me was his claim that ThoughtWorks had rejected many profitable and technically interesting contracts because of negative third pillar impact. Well, again - that's something that didn't occur too frequently in my practice ;)

Personally, I'm fascinated. In Martin's words TW sounds like a perfect mix of two differnt company types: start-up (technically savvy, interesting top-notch projects, caring about sth more than money) and corporation (financially stable, believing in good processes). I encourage everybody to read full Martin's post and establish own opinion.

Spice up your Java with Lombok

Verbosity of Java language has been discussed for years. Almost since inception developers keen on clean and concise code were complaining about writing resource management code (lengthy if-try-catch with JDBC) or creating getters/mutators in Java beans. Simply put, Java language forces devs to write lots of boilerplate code. Some most painful spots are being addressed by language enhancements, like Automatic Resource Management (ARM) in Java 7. Yet this process is complex, cumbersome and takes time.
Is there any better (faster) relieve then? It seems there is! Presenting Project Lombok. Nice utility to speed-up development using source-code annotations. Some most useful features are as follows:

• @Getter/@Setter - simply annotate any field to have appropriate method generated. What's more, getter can be "lazy" without any explicit locking code.
• @Cleanup - ARM is here, no need to wait for version 7 release.
• @NoArgsConstructor, @RequiredArgsConstructor, @AllArgsConstructor - used along with @NotNull instruct Lombok to generate appropriate constructors with arguments checking. Beautiful :)

Full list can be found here.

To entice you more, just take a look at following example:

@RequiredArgsConstructor(staticName = "of")
@AllArgsConstructor
public class Bean {

    @NotNull @Getter private String name;
    @Getter @Setter private String value;
    @Getter @Setter private int count; 
}

Isn't that appealing? ;-)

Why is "your Agile" failing?

Have you ever wondered why is this famous "Agile" failing in your company? Why, after spending some time and money on various consultants it doesn't give expected performance/quality/customer satisfaction boost?
If so, check out this talk by Dan North from ThoughtWorks: http://vimeo.com/10380489. It may shed some light ;-)