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
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.
(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.
In Part 4 (Step 5: Using Browserify) we used Browserify to work better together with NPM imported modules, and to use our own code in a Node styled modular way. It’s time to automate all the build tasks we have so far with the help of Gulp.
In Part 3 (Step 4) we managed to use Knockout.js in TypeScript. The dependencies were resolved by Require.js. In this Post, we are going to use Node style modules with the help of Browserify.
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.
After successfully writing our first working TypeScript application in part 2 (step 1-3), in this post we are going to have a look at how to use JS libraries (in this case Knockout.js) in TypeScript with Typings. We are also going to use Require.js to take care of dependencies.
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!
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.
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.