With 2019 coming to an end, it’s time to look back at 25 years of NDS once more. What better way to celebrate all those years, than by letting the people who’ve been here for the ride do the talking. In the upcoming weeks, our people will tell you what these years have been like and how NDS and PADS4 developed during that time.
First up: Jeroen Smits, our PADS4 Product Manager, aka Software Developer. He’s been with us for quite some years and knows all about our PADS4 Server. He’s been able to spare some time for us to answer all our probing questions.
Q: So Jeroen, can you tell us, when did you start at NDS and what do you do?
My career at NDS started a long time ago, on the 6th of February 2006 to be exact. I work as a Product Manager, and I specialize in developing our software, PADS4.
Q: Why do you think people should start using PADS4?
Some people might call me biased, but I think that PADS4 is the best product when it comes to easily translating real-time data into a digital message. Also, these digital messages can be displayed on screens from many different manufacturers. I believe that’s what sets us apart.
Q: You told us that you developed the PADS4 Server. Why was the server needed and how was it created?
The original plan was for one of my colleagues to develop the Server, but due to personal circumstances that person was not able to finish the project. One of my first projects was the PADS 3.1 Professional version, and here I already wrote the content synchronization. The PADS4 Server seemed to be a logical next step for me.
At that time, we did not have the number of people we have today. If I remember correct, we only had 3 developers. I choose to be responsible for the Entity Framework and Windows Communication Foundation, since back in those days, that was a completely new technique. Because of my experience, the PADS4 Server could be developed fairly quickly. The very first version of PADS4 was not as good as it could have been, we could even call it a setback compared to PADS 3.1 Professional. Luckily it was a setback we could afford, since the number of viewers in an average installation was much lower than it is nowadays. With the releases after the initial PADS4 release, back in 2014, we were able to make up for the setback, there we were able to introduce our Agent feature and the sub-server feature.
Q: How did the PADS4 Server change these past few years?
In the beginning, the PADS4 Server had one ‘simple’ job; making sure all Viewers played the presentations that were planned, with the right content. As the years went by, the PADS4 Server got more and more tasks. It’s responsible for the communication between server and sub-server, with the PADS4 Agent, Viewers can be managed remotely, user and viewer rights can be set and hosting web applications like the HTML5 Viewer are only some of these tasks. Within the platform, the PADS4 Server definitely gained importance.
Q: If you look at the past 25 years, can you name your five favorite improvements within the PADS4 Server?
- When we released PADS4, we changed the mechanism for our PADS4 Viewer notifications. In our previous PADS installations, we used a pulling mechanism. This meant that you had to take a look at the Server to see if there were any updates available. With the new PADS4 release, we started using a pushing mechanism. This mechanism sends a message to the Viewer when new updates are available, making it much easier and more time-efficient and user-friendly.
- PADS4 made a non-dongle license installation possible. PADS 3.1 needed a dongle, a hardware key, that contained the license for our server. PADS4 made having the server on a virtual machine much easier, which was a big advantage for the user. We as NDS also saved time with this development; sending the dongles from us to the partners was a time-consuming task, but was not necessary anymore.
- Going from PADS3.1 to PADS4 we had some database migrations. PADS 3.1 used a Microsoft Access database, but there were often a lot of issues that could not be fixed. With the Entity Framework integrated into PADS4, we could transfer our database to Microsoft SQL Compact, which was already a better database as a whole, but could also be fixed if needed.
- Web Api and SignalR allowed us to host HTML5 Viewers from our PADS4 Viewer effortless. And SignalR gave even more assets; it created a real-time connection from the HTML5 Viewer to the PADS4 Server, causing changes to automatically by put through to all the Viewers.
- It’s not here yet but it is coming soon; our PADS4 Foundation. It’s our step into the future. For now, the PADS4 Server structure is only partially transferred into microservices. These microservices can eventually be used with an on-premise installation, but also on a cloud. Further into the future we plan to transfer the entire Server to a collection of microservices, which increases scalability and flexibility.
Q: How did all these changes affect your job description within NDS?
In these 25 years, PADS4 gained many functionalities, which created more possibilities for bigger installations. NDS as a company grew quickly and was able to employ more people. The biggest advantage for me was that I could focus on developing PADS4 even further. Spending time on support issues, or other side jobs were not a requirement any longer.
Q: What do you think the Server will be like in the future?
If I could have a look into the future, I think I would see the PADS4 Server as a collection of tiny micro-services. They work together perfectly and offer easy to use digital signage solutions to all users. In the time to come, the Server can be used on-premise and in the cloud, without being dependent on a platform.
Q: What feature that came from the PADS4 Server are you most proud of?
That’s an easy one; we’ve been able to create a stabile two-way communication between the Windows and HTML5 Viewer and our PADS4 Server. This creates an optimal user experience, and that’s what matters the most.