8 tracks ranging from Microservices, Datacenter Automation, Test Automation, Internet of Things, Big Data, Continuous Delivery, Agile to Software Development; Xebicon 2015 took place in the Westergastfabriek in Amsterdam last week. Whole day long you could participate in Handson labs on Go, Docker and the Internet of Things! We went there with a couple of collegues and we would like to share our notes with you.

Go Data Driven NOW!

By Friso van Vollenhoven

Big Data and Data Driven are some of the biggest buzzwords in the tech industry. Either you have it or you want it, but few actually know what it entails. Large companies are jumping on the bandwagon and investing millions in Big Data and data science departments and often missing the crucial points required for being a "data driven" organization.

During the GoDataDrivenNow presentation at Xebicon, Friso van Vollenhoven mentioned a few things in order to simplify the whole "data driven" hype. Everything is data nowadays: tweets, posts, weather logs, maps, images, articles, etc. are just a few of the millions of data sources available today. To be "data driven" you must understand that there’s a lot more at play than just having / collecting a lot of data. If it can be distilled into a term, it is more of a mindset than anything else, meaning that the first thing you think of when posed with a question or problem is: "What kind of data is available to help me make a decision". This already is a change in approach for most.

In addition, data is like an optical illusion, the image you see depends on you perspective and expectations. The realization that data is only useful if you look at it the right way is crucial, you have to ask the right questions. But finding relevant insights is easier said than done and requires the room to experiment quickly and efficiently.

Finally one of the biggest challenges in being "data driven" is learning to trust in the quantified priors rather than gut feelings or instinct. Or simply put start making informed decisions instead of gambling on instinct.

– Visited by Jan

Beyond Single Page Applications with Isomorphism

By Gert Hengeveld

The presentation began with a short story of how web development evolved over time. We start out with just server responses to enhancing the experience through JavaScript to full blown single page web applications.

There is a large gap from going from single page web application which is controlled in the browser to a solution which also works on the server side. Gert explained how isomorphism can solve this issue by creating shareable code which is used in both front and back-end.

It would be great if developers don’t have to write code two times in different systems and get the same results on both systems. This will save the developer a lot of time and adds the advantage of maintaining a single code base for different concerns.

At the time of writing is only possible using JavaScript, since that is the only language that works in the browser. For the server was can use Node.js for handling JavaScript. This way, in theory, code can work on both platforms. Gert showed a few frameworks which power the concepts of isomorphism, but sadly didn’t go any deeper into them. It would have been interesting to see code both working on front and back-end.

All in all a good talk to get people familiar with the concepts of isomorphism, but not as indepth as I was hoping for because the concepts of isomorphic code were already clear.

– Visited by Gaya

The Agile Engineering and Leadership Culture at Spotify

By Kristian Lindwall & Anders Ivarsson

The keynote was by Spotify’s agile coaches Kristian Lindwall & Anders Ivarsson and started with the statement: It starts with why!

Everybody should always know why the solution he’s working on, brings success to the team and company.

They pinpoint 4 behaviours that indicate a strong team:

1. Explore your context actively!
   You’re actions/solutions affect others by definitions, you need to be able to find out what the best solution is within the context of your team, department and company. A leading vision (explainable by everyone) is needed.

2. Deliver value early and often
   Define success with the team. Organise your work to accomplish that. Deliver early and prototype: you’re rarely right the first time.

3. So keep improving
   Embrace failure by creating an environment where it’s safe to fail. Do retrospectives (or whatever non-scrum name you use to reflect on work) and do them well. It’s the ultimate time for learning.

4. Do kickass engineering
   Create a collective ownership of code and make it easy to do great engineering. Hence: automate all boring things —> continuous delivery and automate all possible tasks.

To behave like these 4 bulletpoints, you need to know why you’re doing your job. If you know, you’ll rock.

– Visited by Wouter

How to stop drowning in monitoring data

By Mark Bakker and Lodewijk Bogaards

More components being added to the system every day, more (specialistic) monitoring solutions are added to keep a tab on the system. This starts to create an information overflow, where important errors threaten to get lost in the masses of notifications. Secondly drawing conclusions and finding the source of the problem from the generated errors and warnings is becoming harder and more time consuming due to the dependencies and complexity of the system.
In other words there is the need for a dashboard, where components in error and their relations with other components can be visualized, so it is clear what actions should be taken.

The actual monitoring is only the first step. Automating actions based on errors would be the next step, but this is only feasible for some types of problems / components. When humans need to take action, we need to automate the problem finding process. The third step therefore is to create a chart of the components and their dependencies and color them if they are in a state of warning or in error. Automatically processing information from various monitoring systems and converting them to state changes on the chart is done by StackState, a open source tool developed by a new startup that is part of the Xebia Group. The components are also visually categorised in business processes and infrastructure, so problem components and their impact seen in one view.

The 4th and last step in monitoring heaven would be that you can go back to any moment in time and view the states of the stack at that moment and this will also be possible in the next version of StackState to analyse for instance in what order components started failing.

I think that it is crucial to develop these kind of insights and this session gave me the inspiration to start working on this. Implementation can start with a simple map of components and their dependencies, where you can manually set the states. From there you can start automating the updating of the states monitoring service by monitoring service. So even if you do not implement the whole StackState solution, there are ideas you can put into practice easily.
– visited by Hanneke Gieles

Acceptance Testing for Continuous Delivery

By Dave Farley

To start off Dave Farley explicity explained he wasn’t going to talk about Continous Delivery but only a small, but very important part of it. Acceptance Testing is very important in the Continous Delivery proces. Mainly he talked about Acceptance Testing in enterprise systems. In his talk, Dave described approaches to acceptance testing to allow teams to: Work quickly and effectively; Build excellent functional coverage for complex enterprise-scale systems;Manage and maintain those tests in the face of change.

To be clear he; was talking about automated test cases.

The first thing he pointed out was that you have to describe "What" you are going to test, and not "How". Don’t describe step by step what will happen. Teammates probably won’t understand what you are willing to do with the test. In complex systems there are numberous of tests. If one module is changed you have to figure out where this module is used in all of your tests and rewrite them.

To maintain scalability of your program you will have to add an extra abstract layer. In this layer you will write test cases for a certain goal. For example the name of a testcase could be createAnInvoice(). The test contains steps for creating an invoice. Also these steps will also contain by the businness understandable functions, describing what will happen step by step. Like prioritiseNewlyAddedOrders() and getLatestProductPrice(). Eventually when you change a module, the abstract testcase will stay the same. You will have to change the underlying function, but the function is reusable in the different testcases.

Before you start your test, determine what you want to test. If a testcase contains step A->B->C and your only made changes to step B, then only test step B.

For development I think this means that you have to develop in an abstract way. Creating reusable code for different cases.
– Visited by Erwin

Videos, slides and photos

Presentation videos, slides and photos of all tracks of XebiCon 2015 will be available for download soon at https://xebicon.nl.