At TOPdesk our Development department is working closely together with our Operations department. This collaboration started off a bit rough, but through several initiatives this was smoothed out. In this post I’d like to show how we used Deployment Pipelines to break down the wall between Development and Operations.
How do you become the best software developer you can be? We talked to Viktor about it. He works at TOPdesk’s office in Budapest and besides being a great programmer, he’s also got an adventurous streak. Curious how Viktor brings programming to the outdoors? Keep reading!
How to test whether your API can handle anomalous HTTP responses.
Today I was exploratory testing my Service, which performs sequential HTTP requests that depend on the response of the previous request. I wanted to find out how our API would handle a variety of HTTP responses. I also wanted to see what would happen if things went wrong. What if the response contains an image? Or an error code? Or what if there was a timeout?
To answer these questions as quickly and easily as possible I ventured on to the web. With some effort, I found what I was looking for, and on the way I discovered a few tools that are just great for exploratory testing your API’s response handling. If you test or debug API’s on a regular basis, here are a few free tools you’ll definitely want to check out.
I started working with Docker at TOPdesk almost a year ago. Security is an interest of mine, so I did some research. You can’t look at Docker without thinking about Microservices, although they are separate topics. It is often said that Microservices can greatly improve your security. But also, that if you do it wrong, security can actually get worse.
So, what do you need to do to improve (Docker) security, rather than get rid of it? For most security concerns there is already a good solution, although not all of them are widely adopted. Let’s have a look at our concerns and how we take care of them.
(Don’t get us wrong. We actually like it.)
TestNet Spring Conference: Trends in Testing
A week or two ago I went to the TestNet 2017 Spring Event. I’m not going to recount the content of each talk or workshop I attended. Instead I want to combine this event with my experience at other conferences, and give you an overview of the biggest trends in agile testing right now.
Node.js and Express server as seen by a Java developer
This post is about Node.js basics, mainly from a pragmatic point of view. The majority of TOPdesk developers have a Java background (I previously focused on backend), but during the development of my latest project my team decided to use Node.js. We have surprisingly positive feelings about it, and we think it is worth sharing our experiences.
Today we use the web for almost everything. With continuously growing numbers of users for their web applications, developers face the issues of performance and scalability more than ever. This is also the case here at TOPdesk: while there used to be a small group of people developing performance tests, we now aim for the goal that each development team is able to write and run their own tests. To make it easier for teams who are new to this, we are collecting guidelines and documentation. Here is an introduction into performance testing with pointers for further reading.
- Which parts to test
- How to model the workload
- How much load to apply
- Where and when to run the tests
Text: Jos Brakenhoff & Bogdán Bikics
Illustration: Bogdán Bikics
What makes TOPdesk TOPdesk? When you ask around, it all comes back to our corporate culture. TOPdesk gives its employees freedom to explore and experiment, coupled with the responsibility to use this wisely. Just one example of this is our International Hackathons, where self-selecting teams work on a project of choice. At the latest International Hackathon, TOPdesk colleagues from all over Europe gathered together in Kaiserslautern for three days of innovation and fun.
Hackathons – An Agile Development Microcosm
International Hackathons at TOPdesk are a microcosm for the way that TOPdesk tackles the challenges of Agile Development. Nobody is going to breathe down your neck and tell you how to do your work. No, sir.
Instead, we give individuals the space to experiment. Teams look critically at their own processes, and select those methods that lead to the best results. You see this in the variety of tools and techniques in use at our (currently) sixteen Scrum teams. I want to share a few of the tools my International Hackathon team selected to make our project a success. Come, take a peek into the world of Agile Development at TOPdesk.
At the core of the TOPdesk culture are freedom and responsibility.
At TOPdesk security is an important topic. It always has been, but in the last year the way we approach security is changing fast. We think we’re on the right track, and today we’re announcing the next step to help developers enjoy secure development.
The whole software world is backed by Version Control Systems, providing history and traceability to code changes. But you don’t have to restrict its usage to code. Read on to learn how TOPdesk enjoys the benefits of a VCS by employing it in 5 alternative ways.
You want your documentation to live as close as possible to the code it describes. Putting your documentation right next to the code in a VCS allows you to keep both up to date. People who work with a certain revision are automatically presented with the relevant documentation for that version.
Few people possess the knowledge that TOPdesk’s senior developer Roel Spilker has about Java. Not only is he actively working with this programming language since 1999, he is also co-inventor and creator of Lombok. This is a game-changing tool that enables tens of thousands Java programmers on a daily basis to code quicker and prevents them from making mistakes. “In many cases I wonder how to improve the code.” But how does he do it? And what can other developers learn from this in order to keep improving their developer skills?
Today is the very first Valentine’s Day since we launched our Techblog. We would like to take the opportunity to thank you, our readers, with a puzzle! Take a small break from coding to complete the following analogue challenge:
Some TOPdesk developers master this skill already. As a result, you will often find our workspaces and huddle rooms cheerfully decorated with colorful flowers and swans.
Download the TOPdesk_DIY_fold-flower_2017
(This story originally appeared on https://martijnvanlambalgen.wordpress.com/2016/12/27/code-reviews/)
Recently, I’ve read several articles, and heard multiple discussions on the quality of code reviews. To order my thoughts on this topic, I decided to write down my own ideas. Perhaps it helps someone, or it might lead to even more discussions.
So, what is a good code review? Obviously it depends on the situation. How big is the code change, how important is the feature, how many people are going to read that particular piece of code in the future, are there deadlines, etc. Let’s focus on the situation where there’s a reasonable amount of time available (no emergency fixes), for a feature change that has average importance, in a medium-sized team. Note that when I talk about a ‘code review’, usually I don’t just do a review of the ‘code’, but also of all the other parts my colleague has worked on. According to me the reviewer should for example also look at design and documentation, and check whether the acceptance requirements for the story have been met.
Company culture and office atmosphere
An attractive environment helps team productivity, even managers know that by now. Everybody enjoys working in a nice office atmosphere. A variety of things can help to reach this goal. For example personally customizable workplaces or aesthetically pleasing office design which usually includes colorful furnishing and decoration. Often, simply providing all the necessary tools to accomplish the job in a good manner can also be enough to achieve this.
Of course, this is only a fraction of what leads to a good work and office atmosphere. Besides the mentioned tangible options there are also social characteristics.
It started with a two-week computer science course for girls when she was a teenager. Fast-forward fifteen years and Anna Maier is a successful developer who has been going strong for over 8 years at TOPdesk and who takes pride in solving the most complex of problems on a daily basis. We had the pleasure of asking her several questions about how she continually improves her programming skills – and how others can do the same.
Anna, what sparked your interest in programming?
Recently Team Alfonzó, with help from the Build Team, took the next in adopting a new build infrastructure. We wanted to move away from Jenkins and the TOPdesk DockerHub registry, towards a more distributed infrastructure. Our Implementation Wizard project gave us the opportunity we were looking for to start making use of GitLab’s CI and Registry features.
How does GitLab compare to a Jenkins pipeline script?
If you have ever written a pipeline script for Jenkins you will probably find GitLab’s solution more refined and aesthetically more pleasing. Here – instead of Jenkins’ Groovy based DSL – you write a yaml file in which you list the build stages and specify the scripts that should run at each stage. Yaml syntax provides you with a sensible structure, while preserving the freedom you need to configure the build. Unfortunately it lacks the possibility to try out scripts without committing and pushing to the code base. You might want to be aware of this before unwittingly flooding the change history with CI-related experimental changes.
This image perfectly pictures my first feelings about the conference, but let me go into a bit more detail first.
I signed up for the Google Testing blog more than a year ago. There I found a lot of interesting and useful reading about the world of automated testing. When I later got an email from Google informing me that there would be a conference held by them, I was not entirely sure wether I should apply. Is it relevant for me? Am I experienced enough to contribute? Well, what’s the worst that could happen? So I applied for it and did not regret it in the end.
Lately I have been focusing upon subtly improving the way I commit my work to the repository, trying to write a story with my commits.
New team, new procedures
Not too long ago I transferred to a different development team within my company, and besides the different social culture I also encountered a distinctly different technical culture. I think this is mostly due to two things.
First, my new team lacks a dedicated tester, making each developer ultimately even more responsible for not only their own code, but also for the code that they test from the other developers. Second, the team is responsible for one of the real back bones of the product. In other words, mistakes tend to become showstopper problems that disqualify builds for use.
So, to make sure that the quality of our work is up to snuff, the team has introduced a mandatory peer review step before code is even considered ready for testing. This means that another developer of the team, who wasn’t involved in creating the story, has to sign off on the code as if it was his own. This has the added benefits of knowledge sharing as a side effect!
Going into the transfer to this team, I wasn’t really worried about my code being reviewed. Additionally, reviewing other people’s code is proving to be a great learning experience. But lately I have started to notice that maybe I could have made life a little easier for my colleagues.
“Please tell me you’re seeing this too.” Read all about this year’s Hackathon.
On 13 October, our developers across Europe teamed up for the Hackathon, a day to mix up the teams, take a break from regular development tasks and focus on original new ideas.
Now that we know the basics of NPM, Gulp and TypeScript, let’s start our step-by-step tutorial. At the end you should have everything you need to get started with a TypeScript project. Even if you need a few extras at a later point, you will already be on the right path and will be able to figure things out relatively easy.
Before we start, I’d like to ask your forgiveness for the suboptimal folder hierarchy we will set up. In a real project I would go for a more complex hierarchy. For now, I kept it simple for two reasons. Firstly, so that I don’t have to refer to long paths in code snippets. Secondly, I hope that this will be more understandable for you, the reader. After finishing this tutorial you should be able to adapt your knowledge easily on any folder hierarchy.
In Part 5 (Step 6: Gulp) we built up our fully working ecosystem with TypeScript. It enables us to use TypeScript, compile it automatically on every change, clean up, handle dependencies both for internal and external node modules. Now it is time to put the cherry on the top of the cake: let’s add Jasmine tests written in TypeScript!
What is a Root Cause Analysis?
Think for a minute. What usually happens when a serious bug makes it to production?
Someone walks by and asks you to look into it. ‘Find the cause’, they say. So you go in search of the cause, with the goal of fixing it as soon as possible. This is good, but it is by far not the most ideal situation. Let me explain.
Consider the very real error that led to the immediate destruction of an aircraft before take-off. In an unfortunate turn of events, instead of flipping the switch for raising the flaps, a pilot accidentally flipped the switch for raising the landing gear. Although nobody was injured the pilot’s mistake inconvenienced customers and led to expensive repairs. The cause of the failure was noted as pilot error. Why wasn’t this the end of it?
Reporting a bug right away after finding it might not be the most useful thing you can do. What.. how? Here is an example and the theory behind it.
Looking at the bug itself, not only what it can cause
Some time ago we were looking for a database connection pool library to use at TOPdesk (here is a good introduction to connection pools if this term is new to you). There are many open-source connection pool libraries available, so we did not lack the choice. But with so many options it becomes difficult to choose most suitable one, which is why we decided to do a bit of research. Here are some of the things that we learned.
The first step was to decide which are the most important features we needed. Based on previous experience with our older connection pool (which was developed in-house) and on reading newer documentation, we settled on:
Performance is always high on our wishlist, but one thing we find more important is reliability. We therefore planned to check the number of open bugs in the libraries that we were considering. Especially undesirable are deadlocks, a problem that some connection pools have when misconfigured. It actually happens quite often that connection pools are incorrectly or not optimally configured, and one of the causes is that some of them have unexpected default settings. We were therefore looking for a connection pool that is straightforward to configure and has reasonable default settings.
One thing to keep in mind is that the results of a performance test for connection pools are significantly influenced by how the pools are configured; and of course, the type of load used in a test might not be similar with the load that a real application will have in production. So, although we took into account the results of some performance tests that we found online (for example, this performance test) we also wanted to make sure that the connection pool that we choose will have a good performance in our own environment with our own configuration.
For our application we needed a few specific features from the connection pool, such as support for Hibernate 4+ and being able to configure connection properties like the default type of transactions and the default isolation level. We also wanted to be able to configure when and how the connection health checks are done, in a way that is appropriate for the infrastructure and database server being used (our application supports both Oracle and Microsoft SQL Server).
Documentation & user community
Working with well documented libraries is easier, so we planned to check this aspect as well. We also prefer to use libraries with a larger user community, since they are usually better maintained.
One of the great things about working at TOPdesk is the freedom you get to organize your own events, like the recent Pecha Kucha evening that the Agile Community held, or our annual innovation Hackathon. In this post I want to share what it’s like to participate in a Lean Unconference (a conference with no schedule), a concept I first encountered in the Leancamp Startup circle.
What is a Lean Un-conference?
The Lean Unconference started with a kick off. Together with around thirty young professionals and entrepreneurs, the organisers gathered in the lobby. They first recapped the format and goals of the (half) day and gave everyone time to fully arrive and focus on the present.
The organisers underlined elimination of waste is at the heart of Lean. A Lean Unconference thrives on the premise that we have all come to learn or to share. If you are not doing one or the other, you risk wasting not only your time, but the time of others who are trying to learn or share. We agreed to use the law of two feet. If a session is not as relevant as hoped, use your time wisely and join another session instead.
Instead of a passive conference experience, the Unconference organisers did a good job in activating the participants. For a short time, they said (and they were right!), we had access to a wealth of knowledge, experience and expertise. It would take weeks, or even years to share all that we had learned. We only had half a day, so let’s make the most of it! An introduction like this generated a noticeable drive among those present to make it time well spent.
An Un-scheduled conference?
When I say an Unconference has no schedule, this is not strictly true. An empty schedule posted in the central area displayed six slots of a half hour, each with a number of available rooms (say, four or five).
Before each block of three slots, participants could pitch their session to the group. We then assigned post-its to a room big enough to seat those interested. While everyone was welcome to prepare, keeping the schedule empty ensured that all proposed topics were current, relevant and interesting. It was perhaps more reminiscent of open spaces or breakout sessions than a traditional conference.
What can the sessions be about?
This is another advantage of Unconferences. Sessions can be about anything! You might follow a particular theme (Agile Testing, Customer Feedback) or simply leave your options open. To make the outcome as useful as possible, pitches should be relevant (address a current issue) and personal (based on experience).
- You might ask a question: How does user experience fit into Agile Development?
- You could share tips or experience: How I made Risk Poker really work for my project team.
- Maybe you want to teach a new skill: Mind-mapping for user scenarios.
- Or get advice: How do I get my team to talk more about unit testing?
For each session, the host could choose from a number of interesting session formats.
Almost a year ago, and after six years working in a research center, I decided to start the search for a new job. I had lived all my life in a small region of Spain and thought that the time had come to “see the world”. So I began to look for something that could fulfill my desire and change my life. It took time, a lot of telephone and Skype talks, rejections from my side and being turned down. At one point I even started doubting whether I was making the right decision at all.
The chosen one
Things changed when I saw a really interesting company claiming to be almost exactly what I was looking for: TOPdesk. The first thing that really caught my attention was the job offer. It was original and creative, with a hint of humor. It came from a company that really seemed to consider their developers more than just a bunch of people you hire from a recruiter to replace the ones that just left. That got me interested right away! But as you probably know, there are a lot of attractive offers which turn out to be the exactly the opposite. Luckily for me, the opportunity just kept getting more and more interesting.
One year ago we set ourselves the task of doing Continuous Deployment on the SAAS environments running our application TOPdesk. Today we’ve improved our release rate from once every 6 months to once every week. These are the steps that brought us success.
Step 1) Set a clear and ambitious goal
In June 2015 we started out by setting a clear and ambitious company goal:
80% of our customers’ environments have to be updated weekly starting from May 2016.
Setting this goal really helped us to move forward in two ways. First, it changed the discussions from “Should we do this?” to “How can we do this?”. These discussions were much more fruitful and helped us resolve a lot of our problems. Secondly, it helped us align people throughout the organization. Doing Continuous Deployment is not a Development or Operations effort. It affects how you sell, implement and support your product. We’ve spent quite some time getting everybody on the same page.
We make a product which is used by all kinds of different companies. Some of those companies are small and just have a limited user base, while other companies are multinationals, with end-users all over the globe. Typically this means that you have many users from different time zones, all working together in the same environment.
Time zones. A dreaded word in the world of software. Even though most people take these for granted, the concept time zones can sometimes pose quite interesting challenges for us software engineers…
Works on my machine! Or does it?
One day, we received a call from a customer in Brazil, telling us that the Plan Board would crash when opened in a certain week. The Plan Board contains a planner which allows the user to assign tasks to people in an efficient way. When we got the call, initially we were a bit mystified by the bug. Our first thought was that perhaps the customer’s database got corrupted somehow, causing the crash. When we checked the data however, nothing seemed out of order.
In my early programming days at TOPdesk, communication with the Testing department was deceptively easy: throw the feature over the wall, and some time later receive a notification that it was okay (or not). Luckily we learned that the easy way is not always the best way, and we introduced scrum and agile techniques.
This shortened the lines of communication and the contact between programmers and testers became a lot more intensive. We started discussing the story details and the biggest risks together. With everything written down, while the programmers were writing the code, the testers could already start writing test specifications. Next to writing unit and component tests, the programmer could already do some manual testing themselves based on these specifications, before leaving it to the tester to take a second critical look.
Not long after, we introduced automated GUI tests, on top of our unit and component tests. This did not only increase our test coverage, but also our confidence in that all features were tested well. As the automation frameworks took over the repetitive work of clicking through the GUI, the testers were able to do a smarter job, thinking about what should be tested exactly.