Four KubeCon Highlights from the Developer Experience Team

Posted by Joep Weijers on March 26, 2024

The Developer Experience team in front of the KubeCon + CloudNativeCon 2024 sign.

Last week, a delegation from the Platform Layer of our Development department attended the KubeCon+CloudNativeCon in Paris. The hundreds of sessions, loads of vendor booths and thousands of attendees provide great ways to catch up to the latest and greatest in the Cloud Native space. Here are four interesting topics that we learned about this KubeCon.

Read more

Why you should go to a conference in person

Posted by Joep Weijers on September 12, 2023

TOPdesk provides each developer a budget and time to broaden and deepen their knowledge. I recommend to invest such a budget into visiting a conference in person.

Why attend conferences?

TOPdesk SEE conference
TOPdesk SEE conference

In an industry that is changing as fast as the software industry, it is imperative to keep your knowledge up to date. A conference is one of the tools to stay informed on what is happening in the industry. Other examples include reading blogs, following industry leaders on Twitter, or listening to podcasts. A conference bundles a year worth of innovations and best practices and offers then in a one or multi day package.

Read more

Upgrading from JavaEE to JakartaEE using OpenRewrite

Posted by Joep Weijers on April 26, 2023

In our software, we have transitive dependencies on code from Java’s Enterprise Edition (JavaEE). The code is typically in javax.* packages. The owner of Java, Oracle, opensourced the JavaEE specification and has donated it to the Eclipse foundation. This however came with one very impacting condition: that the trademarked Java name is no longer used in the specifications. The specification rename to JakartaEE was pretty easy. Renaming all the packages to jakarta.* was not. This means that all code depending on JakartaEE has to be updated to use the new packages. Although some libraries manage to handle both javax.* and jakarta.* packages at the same time, you really only want to have only one of them. That also means that all libraries that you use have to be updated to use jakarta.* packages before you can successfully update your own code. Here is how we did it:

Read more

Solving the “artifact has been relocated” warnings in Maven 3.8.3

Posted by Joep Weijers on January 21, 2022

After updating to Maven 3.8.3, we have several warnings regarding the relocation of artifacts in our Maven builds. See for example the output of using Maven’s dependency plugin to analyze the dependency usage of an empty Maven project:

$ mvn dependency:analyze
[INFO] --- maven-dependency-plugin:2.8:analyze (default-cli) @ relocation-messages ---
[WARNING] The artifact xml-apis:xml-apis:jar:2.0.2 has been relocated to xml-apis:xml-apis:jar:1.0.b2
[INFO] No dependency problems found
Read more

Understanding Java Native Calls

Posted by David McCann on March 4, 2021

When programming in Java, you usually don’t have to care about how the JVM interacts with the operating system. However, there are cases where a basic understanding of these mechanisms can be useful. In this blog post, I will give a brief overview of how Java native calls work. I’m going to show you how to use that knowledge to track down bugs in your application.

Read more

Extracting a Heap Dump from a running OpenJ9 Java process in Kubernetes

Posted by Joep Weijers on November 26, 2020

At TOPdesk we run many Java services in our Service Architecture. We use the AdoptopenJDK OpenJ9 JRE as base image for our services running in Kubernetes. In this post we will find out how to get a Java Heap Dump from a Java application running on OpenJ9 JRE.

A Java Heap Dump is a snapshot of all the objects that are in memory in the JVM at a certain moment. Typically, a heap dump is created at the moment a Java application crashes because it runs out of memory. The heap dump can then show you what the application was doing in its dying moments, providing insight into potential memory leaks.

Read more

Frontend Testing with Jest – Mocks

Posted by Anna Maier on July 5, 2019

Jest is a popular unit testing framework for Javascript. In an earlier post, we have looked in detail on how you can use assertions in Jest unit tests. In this post, let’s look into using mocks in Jest tests.

So, what are mocks?

In unit tests, you want to focus on one functionality only and ignore the logic of functionality you are dependent on. This is where mocks come into the picture. They make it easy to provide dummy objects for dependencies . Additionally, mocks keep track of all interactions with the mock. This way, you can check if your code calls the dependent code in the right way.

Read more

Pipelines: breaking the wall between Dev and Ops

Posted by Joep Weijers on October 11, 2017

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.

Read more

JavaScript based server for JavaScript, Java based server for Java

Posted by Orsika Labuda on May 16, 2017

Node.js and Express server as seen by a Java developer

Introduction

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.

Read more

Performance testing for web applications: a quick guide

Posted by Corina Stratan on April 27, 2017

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.

Contents

  1. Which parts to test
  2. How to model the workload
  3. How much load to apply
  4. Where and when to run the tests

Read more

Put EVERYTHING in version control!

Posted by Joep Weijers on March 15, 2017

Screenshot of Revision HistoryThe 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.

1. Documentation:

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.
Read more

Code Reviews Done Right

Posted by Martijn van Lambalgen on January 20, 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.

Read more

Committing to a story

Posted by Joppe Kroon on November 15, 2016

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.
Read more

Front-end with TypeScript Tutorial – Step 1 to 3: Minimal TypeScript

Posted by Bogdán Bikics on October 27, 2016

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.

Read more

Front-end with TypeScript Tutorial: First Some Basics – NPM, Gulp, Browserify

Posted by Bogdán Bikics on

This series of posts is written with the purpose of helping people who are starting with a new front-end project, or to those who want to introduce TypeScript in their already existing JavaScript project. In This Post I am going to kick off by introducing all the basic tools involved, like Npm, Gulp and Browserify. In the upcoming posts, I will present a step-by-step tutorial to help you get started.

Read more

Front-end with TypeScript Tutorial – Step 7: Adding Jasmine Tests

Posted by Bogdán Bikics on October 25, 2016

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!

Read more

Choosing a database connection pool

Posted by Corina Stratan on September 8, 2016

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.

Our criteria

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:

Reliability

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.

Performance

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.

Functionality

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.

Read more

Time is not always on your side…

Posted by Jan Stankiewicz on July 28, 2016

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.

clock_timezone

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.

Read more