April 13, 2021

Ergonode Release Candidate - a piece of cake or a hard nut to crack?

In the life cycle of every software there comes a moment when you have to say: yeah, we’re ready. This moment has just happened in Ergonode - a few days ago we published the Release Candidate version - yes, there is still some room for the last corrections, but in general - this is it. When the release date is set in stone and there is no way back - you can imagine that the work is going on at top speed and coffee is flowing in the veins instead of blood. 

I asked our colleagues - Piotrek, who is a frontend developer and Wojtek - backend developer - a few questions about what creating such a product looks like from the inside, what challenges they face, and does working remotely help them?

Release Candidate, meaning what? Is it still much room for improvement before the release of the production version? Or maybe there are only cosmetic changes left? 

Piotr Bletek: As we have finished everything we expected to implement in version 1.0, we will no longer be adding any new features to the RC version. Of course after the release of the RC version we expect not only minor fixes, but also some major bug fixing changes. We know that now we will get more and more specific feedback from users, and we will start to test the application more thoroughly. We expect that we will have to refine some mechanisms, but this is the aim of the RC version, which is to prepare us for the stable release of version 1.0. 

Wojciech Fajczyk: In theory, there should be only cosmetic changes. But theory is one thing, and reality is another. Time will tell if we have not missed something bigger that causes errors in the application. We hope that in connection with RC a larger group of interested people will look at the system and we will get more feedback from the outside.

How does the RC differ from the previous version of Ergonode? How much has changed in the product itself?

PB: The biggest difference is full application stability and reducing errors to a minimum. The most important front-end functionalities are for sure:

  • a structured architecture and improved modularity,
  • refinement of all UI elements,
  • variant products,
  • new dashboard view,
  • DOM virtualization,
  • imports, exports,
  • added bulk actions,
  • implementation of system translations,
  • new notification mechanism.

WF: In the RC version we focused mainly on stabilizing the system. We extended our Continuous Integration to check if the suggested versions of external modules are compatible. We cleaned up many things in the application trying to remove unnecessary dependencies between modules. Of course we also extended the mass action functionality.

What do the last hours before RC release look like? Calm morning coffee, a call with the team and pressing the magic button or rather a last minute fierce battle and sleepless night?

PB: I wouldn't say that everything was calm and we drank coffee fully relaxed. It's not often like that and sometimes you need to do a little more than pressing a magic button :). Fortunately it didn't look like we had a lot of overtime and sleepless nights. Everything went fairly according to plan, but of course at the end there were a few unexpected changes, so until the last moment we fought hard to finish on time. I can say that everyone in the team got involved to the maximum in order to finish everything, which resulted in releasing everything on time. Thanks to everyone for a really good job!

WF: Magic button, that’s funny:). Of course there was coffee, but because of the remote work everyone drank it at home. This day was definitely not a quiet one, always at the last moment it turns out that something was still missing, someone forgot about something etc. Fortunately, it was not much and we managed to finish on time.

What is the process of working on a tool like Ergonode? I know that it's hard to describe in a few sentences two years of work on the product, but if you could try to sum it up?

PB: Working on the Ergonode project has been a very cool experience, mainly due to the fact that I've never worked in a project team before. Creating an application from scratch is a great challenge, which is associated with great responsibility, but often also great fun. A very large part of our work is direct contact with clients and carrying difficult conversations to marry business needs and technological requirements.

As developers we’ve had a real impact on the decisions made and we’ve felt that our opinion was strongly taken into account. In developing Ergonode we’ve had a lot of challenges and pitfalls that I think grew us all a lot as developers.

We’ve been discovering dark corners of technology, strange nooks of functionality and newer and newer solutions. Of course, during these over 2 years there were a few ups and downs, but at the end of the day we managed to create something great, of which we are all very proud.

WF: I can also add that because a lot of things had to be written from scratch, we’ve had space to learn and test new technological innovations. This is definitely an interesting work experience. 

What, from your perspective as a developer, is the coolest thing about Ergonode? What are you most proud of? Don’t be humble, go ahead.

PB: Working on Ergonode is both a new challenge and great fun. On every step of the way while planning new features we come across interesting problems and neat mechanics to implement. If I have to choose the coolest thing that I'm proud of, it would definitely be the VueMS library. I was given a task to prepare the application for the business guidelines, which involved changing the front-end application architecture from monolithic to microservices. It was a huge amount of work and a lot of complicated mechanisms that modified the native behavior of Nuxt and Vue frameworks. Thanks to this a universal VueMS library was created, which allows you to modify the architecture in any project based on Vue and Nuxt technology. So I had the opportunity to prepare a library on which we base the entire Ergonode, and which is available to all as Open Source.

WF: It's hard to say, in my case these are usually big issues on which I have to spend a lot of time. One such example was the design and implementation of the core parts of the "Export Channel". I had to design a solution that is universal and fits the majority of use cases even the ones that are still to be discovered. Often it was so, that I designed something and created a small demo, to immediately change it and find the most universal mechanism. Now life will verify and people writing new export modules for different systems will check if I succeeded.

I can't help but ask about your biggest challenges - what's kept you up most nights?

PB: This is a topic I've mentioned before. Definitely building the VueMS library was the biggest challenge and gave me the most sleepless nights. The pressure of responsibility for the fact that we will base our entire application on this library was strongly felt. Additionally, releasing VueMS as an Open Source library, provided a little more stress, because I was not creating it only for Ergonode, but for different applications. Thanks to this challenge I learned a lot of new things, and started to dig deeper into the architecture of frontend applications. It was really challenging.

Does remote work help or hinder the development of software, where communication with the team is so important? I know that you have experience working both from the office and from home. What works better for you?

PB: When comparing working remotely and working from an office, it's very hard to determine which suits me better. Both have their pros and cons. The fact is that working in a team needs good communication and physical meetings. Also, planning functionalities is definitely more optimal in person than via dial-up. On the other hand, when working remotely I experience far fewer distractions and feel more freedom. If I had to choose, I prefer remote, but combine with meeting with a team in the office once a week.

WF: Remote work has its advantages and disadvantages, I used to like to take larger topics to solve at home, where in the silence you could focus and think about many things. Currently, I have the impression that it has become the opposite and that the office is more quiet and calm. When developing software, face-to-face team meetings are much more fruitful and we come to an agreement much faster. When working desk to desk some problems are solved much faster.

Both approaches work, but the most important are contacts with people you work with, which is a little harder when working remotely. So it is difficult to say which is better.

Big thanks for the chat & congrats to the whole team!

Marketing enthusiast & adventurous soul

What's new?

Check out the latest insights from Ergonode - best practices, updates, articles and stories.