TheCodestReview #5 – bi-weekly software engineering juice

In the last episode I have teased to comment on the article covering the importance of humour in the workplace, but meanwhile I figured out it deserves much more credit so I’m gonna write an entire blog post about it soon(ish).    

Things that kept me busy over last couple of weeks: 

a) Before Christmas I kicked-off with premiere episode of “Bulletproof CTO” webinar series (stay tuned for 2nd episode in February featuring SaaS CTOs, details following soon on my LinkedIn).

b) Tuning our growth plan for 2021 with a goal to go beyond our Ruby and JS core business and grow a Magento and Product Design competence in-house.

Enough of self-promotion, let me invite you to the 5th episode of our #TheCodestReview series. 

Topics my team has prepared for this time: 

1. Scalable and maintainable front-end architecture.
2. Conventional commits.
3. Ruby 3.0.0 release updates.

The comments on frontend application and conventional commits are delivered this week by our React engineers while Ruby 3.0.0 by our Ruby dream team.

Today a lot of developers for time-saving are using already made UI libraries and reusable components. It’s a good practice and it helps us to save a lot of time but when our project becomes larger – you will understand that it’s not enough to handle with code.

There are two good patterns from back-end development – Domain Driven Development (DDD) and Separation of Concerns (SoC). We also can use it in front-end architecture.

In DDD we are trying to group similar features and decouple them as much as possible from other groups (modules).

While with SoC we, for instance, separate logic, views, and data-models (e.g. using the MVC or MVVM design pattern).

There are a lot of good practices and patterns to use but this way is preferred for me.

When we use this pattern we will get this picture:

At the beginning the user is redirected to the correct module by the app routing. Every module is completely contained. But, as a user expects to use one application, not a few small ones, some coupling will exist. This coupling exists on specific features or business logic.

And we have this structure:

app folder – application layer

assets – folder for pictures, fonts, icons etc.

components – here should be components for reusing which don’t have complicated logic

config – here we will store global state

lib – folder for complicated functions and logic calculating

modules – here’s our modules

pubsub – place for storing schemas for describing data structure.

styles – for our css/scss code

This structure will help us to handle our growing application and to have less bugs. Also it will help to make more comfortable working parts with separate modules, to test them and to make refactoring and debugging easier (because of separate modules).

If we will look deeper to module architecture and their connections with API – we will get something like that:

If ‘app’ folder we will create another folder ‘api’ with code for API calls and data we will save to ‘config/store’. Here we are keeping static and immutable data which we are using in the entire application.

Also in the ‘pubsub/schema’ folder we will describe specific data types for JavaScript objects.

All modules contain data inside which we need to use (users, routes, tables, actions etc.). Every module is connected with the application layer and takes all necessary data.

The front-end is the first point of entry for our users. With our front-end projects growing in features, we will also introduce more bugs. But our users expect no bugs, and new features fast. This is impossible. Yet, by using a good architecture we can only try to achieve this as much as possible.

Conventional commits by Sathyabodh Mudhol at DZone

The reason behind the need to commit work in a better way

Imagine you’re at a starting point in a company you just got hired by. All the people are nice to you and everything seems fine up until the point when you’re introduced to a codebase from before JavaScript was a language and Netscape was loading a page for what would seem like an age.

The inheritance of code seems to be a massive issue when introducing new developers to a project. Reading the code is one thing, but understanding how the application was developed is not quite the same. Oftentimes commits prove to be useful and give context to why these console.logs weren’t caught by linter or why that nasty // TODO is there for children of the developer that initially made the annotation.

Let’s start with why conventional commits are better than unstandardized commit rules.

If we hire new developers to a project in which most commits consist of messages along the lines of that should work or Sleepy fix for footer ASAP what pops up in your head?

I’d say that red flags because:

• We don’t know what exactly should work
• Why did someone push something whilst being sleepy and potentially erroneous?
• Was the fix rushed if we can see ASAP annotation?

Because your team can have custom rules applied to when one commits changes there’s less room for error as your commit needs to be solid. It’s no longer a way to just check-out. It’s a signature that tells other people that you knew the contents of the commit. No need to mention that if the work you’ve done is not correctly signed it will most likely result in an error and prompt you with a message

There’s a chance your team would like to set up a rule disallowing for certain keywords so ASAP or any swear words can be on the blacklist.

Tooling

What is really helpful at the start of the project is to introduce everyone to how your dev team would like to see new developers to commit their changes. Then set up a tool that helps them to keep up with what you all agreed on.

One of the tools I’ve had a chance to work with was commitlint and it made conventional commits my go-to practice when coming to new projects that don’t have rules and the team is open to the idea of introducing them.

When dealing with the settings and spreading them across your team you can just simply create an npm package and just mpn i -D it in each project. That will surely help everyone in the project to be on the same page at all times and if need be walk from project to project understanding what were the last changes about (and why were they made).

Friends with multiple benefits

So now after setting it all up and understanding why it might be a good idea to start using CC the best part would be programming around the rules you’ve just applied! We are using a standardized way of how we commit, we pay more attention to what the commit really was about so why not set up hooks that allow you for quick testing on staging when a flag is present? We don’t want to overcumber services and cut the costs when needed and there are some reasons to test on production-like server instead of localhost.

Let’s assume you’re working on PWA and SSL is needed for you to test out the full potential and you have an SSL on your testing platform. All you need now is just a good commit. Something along the lines of feat(PWA): manifest icons workbox setup upload would trigger the whole machinery of testing and moving cogwheels around. We don’t need that when just uploading some static data like manifest.json so we add a flag [TEST_SKIP] as a postfix to our commit. That enables our CI to just upload new assets to the testing environment and skip testing. You can read more on that here

After a while you’ll be able to see other profits, such as ease of generating CHANGELOG and better versioning with semantic versioning. If that’s not enough to convince you to change your ways of writing commit messages, maybe getting your toes dipped into fresh cold water and trying to use them in your private repository for a while would change your mind.

Happy conventional committing!

Ruby 3.0.0 release updates by Ruby Community

A long awaited in the community Ruby 3.0.0 release has seen the daylight at Christmas so that all the Ruby developers out there could find it under the Christmas tree once they wake up in the morning. At The Codest we cultivate the knowledge sharing culture by organizing weekly dev meetings where our engineers discuss technology trends and their new discoveries worth the attention. Below you can find a link to slides from the demo day where our senior Ruby engineer discussed couple of important changes in Ruby 3.0.0 from his subjective point of view:

https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing

Furthermore, our Ruby mentor has contributed to the new version with his pull request that was successfully merged. More on the topic of privacy control methods you can find below in the short article by our Head of Development.

https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods

Thanks a lot for reading and if you’ve come that far, I appreciate your time and every piece of feedback is more than welcome on LinkedIn or to my email.

Coming back to you with the next episode at the end of February with the review of a podcast interviewing Shopify’s CTO, the man behind an engineering team working on the magnificent Ruby monolith app!

See you around.

Read more:

TheCodestReview #4 – weekly software engineering juice

TheCodestReview #3 – weekly software engineering juice

TheCodestReview #2 – weekly software engineering juice