Deploying new features is a nerve-racking task, but it must be done.

Here’s an issue we’ve all faced or will inevitably face in our careers. Allow me to set the scene…

You’ve finished your work on some features, fixed some bugs, etc. You’re feeling good because some features were a bit more complicated. You decide it’s high time to let your users experience these changes. You bundle up all your teams’ changes and deploy them to the production server. A couple of hours later, disaster strikes! There’s a critical bug on a feature you’ve worked on. Now, you have to revert to the old version of the application or deploy a new one, but without your changes.

As these situations can have a huge impact, reacting quickly is key. Unfortunately, developers usually learn how to handle this situation once it happens, so it only prolongs the agony.

Deploying and releasing at the same time isn’t such an uncommon practice because, at the beginning of a project, you want your users to see the changes immediately. Many projects continue using this process, but as the project grows, it makes sense to decouple the deployment of the code and the release process (activating changes to users).

Even if this hasn’t happened to you yet, we can all agree that it’s a very stressful situation, and establishing a process for handling this is something you want to do ahead of time. 

But how much ahead of time are we talking about here?

There are many ways to handle these types of outages, and it’s important to establish a rollback procedure. In addition to that, we also use something called feature toggles. It’s not something unique to us, but it’s a pretty sweet thing to have in your toolbox. For those unfamiliar with feature toggles, it’s a mechanism that allows you to turn a feature on or off for a user without needing to deploy the whole application. It’s really simple, but it’s huge!

Although it’s called a “feature toggle”, it doesn’t necessarily mean that you have to use them for features only. You can use them basically for anything. Whether it’s A/B testing, refactoring a part of the screen, or navigating a user to a different page entirely! I’m sure you can think of a couple of more examples that would be useful to you.

This also allows us to oversee which users can access a certain change. This is helpful when trying to collect feedback or just observing how users interact with something you’ve developed. Once you’ve established your feature toggle system, you don’t need to put in continuous work to keep it going. It’s also a great way to manage the lifecycle of the change by progressively rolling it out to your canary, beta, and all users! 

You gain a lot more control over who sees what, and the best part is that turning toggles on or off can be done by anyone! Someone like a product manager or customer support person could decide to turn a toggle on because it’s just something that the customer needs. After a feature has been fully developed, the toggle can be globally released to all customers, and everyone can enjoy the stable version.

The number of annoyed users will decrease, and valuable feedback on changes will increase. 

It’s also worth mentioning that you can base your whole QA process on the toggles. We can test a change by turning a toggle on, gathering feedback, and then turning the toggle off. When you have such fine-grained control, testing on production isn’t a big deal! We also use these toggles in other environments, so you can isolate a change to a specific set of users on any server.

It’s a win-win for everyone!

The main question that’s probably going around in your head is how the feature toggles affect the development of a feature.

Feature toggles do complicate things a bit when writing code, but if you spend some time on planning, it can be done elegantly in most cases. You must be careful to add every change behind the toggle so nothing leaks when the toggle isn’t turned on. Other people working on the feature must also be aware of using the toggle since it probably will span through multiple files and can sometimes be forgotten.

Sometimes, it’s not that complicated, but you gain a lot. As I’ve already mentioned, it can be used for basically anything, and complexity may increase, but it really is worth it:

The added complexity isn’t such a big drawback. You’re getting a lot more out of feature toggles, and if that means that developers have to be a bit more careful when writing and reviewing code, so be it. It’s much less stressful for a developer when they know a feature can be turned off if it’s causing problems. This doesn’t mean we approve of sloppy code, but sometimes, these things happen.

To conclude, feature toggles (once established) don’t affect the development process as much, but they offer a lot in return.

The first one does introduce technical debt, but if we create a task for deleting a toggle after it’s been globally released, we can be sure that it will be deleted as soon as possible. The person who created the toggle is responsible for deleting it, which is a great way to handle this efficiently. In any case, deleting a toggle usually takes significantly less time than developing it!

As for the other issue, there are two ways to handle this. We can do either of these two:

It’s not an ideal situation, but it can happen. The solution mostly depends on the state of the features, so it’s impossible to determine the best way without knowing all the facts. Either way, both solutions can simplify things for development.

For us, implementing feature toggles was a no-brainer. Considering all of the benefits like the control, progressive rollouts, and others, it seriously outweighs the downsides it introduces. Even the downsides can be managed to an extent.

It’s important that everyone in the company understands the whole process and embraces why we’re doing it in such a way. It’s an essential part of a company like ours since every department is involved in the release process of product updates. Once people are aware of this, building an admin system to control this is up to you and your company’s needs. 

Here’s an example of our own. We call it the “Backoffice”:

As a developer, I’m grateful we can release features quickly and stress-free, knowing we have some wiggle room.

As for you, I hope I’ve shown you why it’s a good idea to think about something like this if you don’t use a similar mechanism. If you need a bit more convincing, you can read more about it in an article by Martin Fowler! Even if you’re not in a position to make your feature toggle system, there are a lot of external tools and libraries that might help you implement the same!

The more you put things off, the harder it gets to actually do them. That goes for dependencies too. Sure, dependencies need to be updated, but that doesn’t make the task any less miserable.

Before I start explaining what a dependency manager is, let me explain what a dependency is. 

Dependencies are third-party libraries that developers add to their projects so their lives would be easier. What that means is that someone wrote a piece of code that other people can use. It also means that it needs to be frequently updated. In most web projects the list of those libraries is located in the package.json file. 

Now that you know what dependency means, I want to introduce you to the idea of dependency management. 

Did you ever get caught up with a lot of non-updated dependencies and when you began updating them, you realized you missed a lot of things? Some of those updates can be helpful, but some of them can make your life miserable. 

At Productive, as developers we encountered the same issue. Some of our dependencies were out-of-date by several major versions which can lead to real issues, such as deprecations. So we started to think of a way to keep everything up-to-date. 

Manually handling them was not an option anymore. We have several repositories just for front-end projects and it takes a lot of time to track all those dependencies with their release updates. So, we decided to implement a dependency management bot. 

A bot like that not only notifies you about new versions, but it notifies you if a certain package has vulnerabilities. It suggests changes by creating Pull Requests. You’re probably wondering how can dependencies have vulnerabilities now. Well, some of them are depending on other dependencies, or it may be that the developers just wrote some shady code.

One of the problems we confront as developers is “notification noise”. 
Nobody likes to see a swamp of notifications and nobody has time to read them one by one. Therefore, we were trying to pick a configurable manager to control the level of noise. A few of them came up in my search—such as Dependabot, Renovate, Snyk, Dependencies.io, Depfu, etc. 

Dependabot is popular, mostly because it’s a GitHub manager, but it’s not quite as configurable as our final choice (wait for it!). One of the great things about Dependabot is that it can be used in combination with other managers (like Renovate). After comparing them, Renovate won. 

Renovate is more configurable and what I mean by that is that we can choose the dependencies that will be checked by it. We can set up a schedule for when the notifications will arrive, we can divide packages into all sorts of different groups we need. If you don’t like the way your PR looks, as you probably guessed—you can edit it. With this manager, you can also set an assignee who will get notified, and much more.

Since we didn’t configure the manager to auto-merge new updates, we need to handle them ourselves. So, when it does its job, usually I handle most of the updates for the Productive app. If there are some dependencies which I’m not so familiar with, I create a task and assign the PR to my colleagues.

Because I read most of the Release notes, sometimes I stumble upon some useful information about how a new update will be helpful for someone and then I inform them because new updates may solve their current workarounds (read: hacky solutions).

When we start updating dependencies we approach them differently. For every major package, one PR is created. For non-major dependencies, there is one PR where all dependencies are handled because they are less likely to cause bigger problems. 

Of course, the person in charge sets his PR link in a task so if some errors are made because of it, it can be easily traceable. When the whole list of packages is up-to-date, the developer merges that PR. After merging, the Renovate bot will auto-update the created PRs and if there aren’t any other updates the bot will auto-close it.

The issues we wanted to solve:

The first problem I wanted to solve was reducing the noise to a minimum. Since the notifications are not wanted every day, I set a schedule for when we get those notifications. The schedule is set by the “schedule” property. The value of “schedule“ will represent the fixed times when the pull requests get generated.

Because there are different time zones, don’t forget to implement a timezone for your or your company zone (ours is Europe/Zagreb) using the “timezone” property with this list: IANA Time Zone.

Since I’m not the only one who should be warned about updates, I found the “assignees” property which will set assignees who will be notified. For this property, you can use GitHub’s username or email.

Although I am the main assignee for dependency updates on all of our front-end projects, I didn’t want to read each PR independently. I started to look at how dependencies can be grouped, sorted, or something like that. 

So I found “One array to rule them all” which saved me from a lot of buzzing noises on Friday , and it was the packageRules array. Each object in that array specifies which updates I want in each PR. In one PR it was necessary to receive updates only for major versions, the other was for patch and minor versions and it looks like this:

or

Each group can be named whatever you want and prioritized by prPriority. I wanted to assign some groups to other colleagues so I don’t have to deal with everything. Because I am lazy. Just kidding. 

Other colleagues had different assignments because they were more familiar with some specific libraries, so I used matchPackageNames and matchPackagePatterns. 

The matchPackagePatterns came very useful because you can use RegEx. I almost forgot to mention that for some of the dependencies, it wasn’t necessary for them to be on the list of updates. 

Why? Well, because there’s a Core team that deals with them every day at Productive, so I can set enabled: false to stop Renovate from notifying me or them. 

For example: 

Also, one of the useful commands is baseBranches. With that command, you set which branch will be checked by the bot. That can be useful because most software products are not updated daily and the companies have specific procedures until some feature goes out to the public.

Here’s an example of the renovate.json file with the basic configuration previously mentioned: 

For every other option you want to add or explore, feel free to read Renovate’s documentation.

Below, an example of one PR with a table (photo 1) and Release notes (photo 2).

The table is pretty self-explanatory. You can see which package or whatever you want to call it can be updated to which version with some other data. The table itself is configurable, so you can tailor it to your preferences.

Then there’s a section with the release notes in which you can inspect each update individually with their specific commits and proper descriptions.

Lastly, not everything is perfect. There were some issues we encountered in the implementation process. 

For instance, there are two types of PRs, normal and immortal ones. A normal PR is a PR with only one dependency. When you close a normal PR, the main problem is that the manager will “think” that you maybe do not want to use that version of dependency and it will not notify you again. Immortal PRs can be closed because the manager will reopen them again, in our case those are grouped PRs. So, how do we deal with that feature/issue? We don’t close PRs until each package is up-to-date.

Another issue I encountered is that PRs will be created inside a schedule, but the manager will notify you outside of a schedule when updates are made. For example, the PR schedule for creating PRs is on Friday, but in the meantime, a new version of a certain dependency would be published and I would receive a notification. That could be useful, but since I update versions on a weekly basis I added the :noUnscheduledUpdates property, which limits notifications only inside the schedule.

One issue that still bothers me is that I receive vulnerability warnings for dependencies in one PR for every warning. I wanted to group them, but it seems nobody figured out a solution for that, yet. Depending on when you read this article and if this problem is solved, please contact me. Our method is to update only the dependencies to stable versions and use that as a workaround.

The last issue we encountered was with the range strategy. Renovate will not update packages if there’s a range indicator such as ^. That was weird to me, but they have a solution for that—you can set a rangeStrategy and Renovate has various options so that you can adjust to your app as you wish. We solved it by adding a “bump” rangeStrategy. We started with “replace” but when the manager reopened an immortal PR, dependencies that were on the closed PR’s list wouldn’t show up.

In conclusion, if you ever get assigned to manage dependencies, for the love of God, use a dependency manager. If you have to ask why, please read this blog post again, or contact me to remove this post. 

But, for real, it just makes your life easier. Renovate is a solution that was best suitable for us. Because of it, I do not need to go to the NPM’s website to track every package if it has a new version available.

One of the annoying issues it also solved for me was that it keeps the noise to a minimum because of the “schedule” property. The noise was also reduced with the creation of groups for different types of versions.

Also, PRs are very easy to read and last, but not least, one of the best features of it is—it’s FREE.

A couple of months ago, there was a huge shift in my work-life. Or so I thought.

Instead of working in Vue or React, I had to learn Ember for my new frontend position at Productive. I was sure I would have needed quite some time to get used to it. Up until a few months back, I didn’t know what was going on in the Ember ecosystem. Although this didn’t scare me, I felt like it would be a hefty challenge because I wasn’t sure what I was getting myself into.

Turns out, it’s really not that different from the frameworks I already know. All of the usual things you’d expect are there. Things like store management, component slots, dependency injection and much more. And they were a bit easier to use since it all came out of the box! 

You don’t have to spend a lot of time deciding between libraries, patterns or technologies because a number of them are already there when you just install Ember. It does have some nuances, pitfalls and you still have to choose between some libraries (UI libraries, I’m looking at you), but I haven’t worked with a framework where you didn’t have to worry about anything. After I took all this in, the hefty challenge didn’t seem so bad anymore. Now, this was just a matter of getting used to the framework.

As I’ve started to learn about Ember on a deeper level, a lot of the concepts were familiar to me. Some were described exactly as you’d expected them, some were named differently and some used a different terminology.

But since Ember has such a long history (for a Javascript framework, at least), there are some terms I wasn’t aware of. That’s why I started to write down anything that I wanted to learn more about. This included libraries, phrases, patterns and technologies. I was sure this would help me in the long run, so I’m sharing it with anyone who’s just starting out with Ember.

This is especially helpful if the codebase you’re working on has a couple of years under its belt. It pays off knowing how and why things were done so you don’t accidentally break a functionality when refactoring.

I’ve talked long enough, so here’s the list!

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

I’m sure some things might be missing, but this is what was the most puzzling to me. Hopefully, you’ll find some use of all these terms!

Also, I feel like it would be kind of rude not to mention the resources I used while learning Ember: (yay, more lists)!

Last week I attended .debug, a developers conference, where my company held a booth.

The idea was to have a “change my mind” kind of setup, where we represent a radical idea, invite people to debate with us, and show them that we’re building some interesting stuff at Productive.

We decided to go with this one:

Jokes aside, React is a fine library. It’s important in web development because it introduced declarative and reactive templates, a paradigm shift that everyone needed at the time. There was a problem with rendering engines and reactivity back then (6 or 7 years ago) and React solved it pretty well.

As a side note, Ember solved the same problem earlier. It wasn’t as performant, though, and the framework was too opinionated to catch up with the way React had done it.

What happened after React gained popularity was a mess. It started a new trend in the community where everything revolves around hype, novelty, and creating new paradigm shifts. Every few months there were new libraries emerging, setting new standards of how we should write React web apps, yet solving problems that were, for the most part — already solved.

Let’s take “state management” as an example. Since React is missing a traditional dependency injection system (DI is achieved through component composition), the community had to solve this problem on its own. And it did. Over and over and again. Each new year brought a new set of standards.

React is just a rendering engine, and in a typical web app, you need many libraries to build a framework for a project — e.g. data layers, state management, routing, asset bundlers, and more.

The ecosystem behind React gave you too many choices of this sort, which fragmented the tech stack and caused the infamous “Javascript fatigue”.

One of the trends that also emerged was “framework comparison obsession”. JS frameworks were constantly compared with properties like rendering speed and memory footprint. This is irrelevant most of the time because a slow app is not caused by a slow JS framework, it’s caused by bad code.

As with every trend that is taking over the world — this one went too far, damaging new generations of web developers. I’m wondering how it’s possible for a library to be the most relevant skill on an average web developer’s CV? Even worse, it’s not even a library but a module inside that library. React hooks are more often mentioned as a “skill” as opposed to some actual skills like code refactoring or code review.

Seriously?! When did we stop bragging about the important stuff?

Why don’t you tell me, for example, that you know:

… not by mentioning the most starred library on Github, but by showing me one or two of your finest snippets.

… not by mentioning a popular state management library (preferably ending with “X”), but by telling me why “data should go down and actions should go up”. Or why state should be modified where it was created and not deeper in the component hierarchy.

… not by telling me that you know Jest or QUnit, but by explaining why it’s hard to automate end-to-end tests and why minimal meaningful rendering tests are 10% the effort and 90% the benefit.

… not by mentioning that you use CI/CD (as every other project today that has more than one person working on it), but by explaining that deployment and release should be separate so you should code new stuff in a way that doesn’t mess with the old stuff and can be turned on remotely.

… not by mentioning that you’re a “team player”, but by telling me that code review is just as hard on the reviewer’s side and that you know how to optimize your PRs for readability and clarity.

… because unless you’re a one-man band, you’ll hate your life if you don’t follow strict standards and conventions in a project. You should tell me that naming is hard and the broader the scope of the variable, the more time you should invest in coming up with a good name for it.

… because code review ensures product quality, reduces bugs and technical debt, builds common team knowledge, and more — but only if done thoroughly. Code review shouldn’t only be done top-down. It’s a great learning mechanism for less experienced team members.

… because it’s not about the GitHub stars, it’s about common principles that most of today’s JS frameworks share. Finding out about the pros and cons of other frameworks makes you understand your framework of choice better.

… because technology is only a tool for making products, not the process. Spending time on optimizing the process is always better than spending time on arguing about technology.

… because most of the time, optimization isn’t necessary at all.

… because pair-programming is, like code review, the most important practice for knowledge sharing and building team cohesion. It’s also fun!

… because every project has technical debt and you should stop whining about it and start refactoring. Every new feature should be preceded by minor code refactoring. Big refactoring or rewrites never turn out well.

So yeah, that’s why I think React ruined web development. People at the conference were intrigued by the claim and joined the debate eagerly. I had a great conversation with a few experienced React developers. Nobody agrees with the title of this article, saying “ruined” is too strong of a word. But most of them agree with the problems discussed in this article.

You can try to convince me that React isn’t that bad, and I will absolutely agree with you!

But instead, let’s debate about the more important topics — the work that we actually do as software engineers.