DEV Community: Ali Kamalizade

My 10 Favorite Software Engineering Blogs

Ali Kamalizade — Tue, 29 Jun 2021 18:54:49 +0000

At this point, there’s hardly any bigger tech company that does not have an engineering blog. In my opinion there are a few characteristics of a good engineering blog:

The content is written by people like software engineers or data scientists
The blog posts are not just glorified product marketing

In this post I want to share blogs I follow to stay up to date regarding software engineering. Of course, there are way more interesting blogs out there.

Instagram

Instagram is a widely used platform. Hence, it faces a lot of tough engineering challenges (e.g. regarding scalability, data protection). The following is one post about making the web version of Instagram faster by reducing the amount of JavaScript and optimize the execution.
Making instagram.com faster: Code size and execution optimizations (Part 4)

BBC

BBC is not only a broadcasting company but they also employ a capable engineering team. Accessibility is a topic that is often neglected in software products. Hence, I am glad to know how accessibility helped to improve their internal design system.
Shifting left: how introducing accessibility earlier helps the BBC’s design system

LeanIX

Disclaimer: naturally, I’m biased about this one. Nevertheless, I want to include LeanIX as the blog is fairly new but the topics range from learnings to open-source work. Here’s a great post which answers a popular question: why software has bugs.
Why software has bugs - explained with kids | LeanIX Engineering

Netflix

Netflix has done a lot of pioneering work in the software engineering world. If you have never heard of GraphQL then I can recommend to take a look at this post. Many companies like Netflix are now creating new APIs entirely with GraphQL instead of REST.
Beyond REST

GitHub

GitHub hardly needs any introduction: at this point, most software engineers should have used GitHub at least once. Web Components is a new standard to write and reuse components regardless of any JavaScript framework. Check out this post to learn more about how GitHub uses Web Components.
How we use Web Components at GitHub | The GitHub Blog

Wix

Wix is a popular website builder to create websites with no code. Their engineering team shares content about microservices, the technical interview process and more. As someone who likes to create something new I can recommend this post for some motivation.
Let’s Not Ditch Another Side Project

Google Developer Experts

You may have heard about the GDE program. There is a lot of knowledge shared as there are various topics covered related to Google technologies. I like this post about best practices regarding pull requests.
How to Pull Request.

PayPal

PayPal is a widely used service to pay people or businesses in an easy way. If you’ve ever been interested into the idea of the JAMstack then this is a good entry into the topic.
What exactly is JAMstack?

Airbnb

Airbnb should be known to most of you. As a fan of TypeScript I like their work on ts-migrate which Airbnb has developed to migrate large code bases from JavaScript to TypeScript.
ts-migrate: A Tool for Migrating to TypeScript at Scale

Capital One

Working in a finance company does not mean to only work with legacy systems. The engineers at Capital One are regularly sharing their lessons learned in areas like machine learning, cloud infrastructure and web performance. I like this post about ways to avoid coupling in microservices design as many companies are struggling with following the microservices mindset.
How to Avoid Coupling in Microservices Design

Conclusion

Thanks for reading this post about my favorite tech blogs. Which engineering blogs are you following? Let me know in the comments.

How to Fix the “Failed to Read the CSSRules Property From CSSStyleSheet” Error

Ali Kamalizade — Mon, 12 Oct 2020 16:08:20 +0000

Originally posted on my Medium blog »

Photo by Graham Ruttan on Unsplash.

Recently, a few customers ran into a problem in an Angular web application where an exception was thrown. Because of this problem, you couldn’t use a major part of the application. As a developer, I want to have clear instructions on how to reproduce an issue to not waste time. Good customer support or customers willing to share more details beyond “It isn’t working for me” can provide meaningful information to make the life of developers easier. Customer support wasn’t able to reproduce the issue on their devices, yet it was consistently happening for a few customers.

When this issue was brought up, I did what I typically do when encountering issues like this. This article is about this particular problem as well as debugging critical issues.

Finding the Root Cause

I used Instana, which is a great SaaS for monitoring microservices and websites. Through our monitoring tool, I was able to confirm that the error occurred for a few customers as well as the user actions that led to the issue. Even with this information, I couldn’t reproduce the issue at first.
I had the error stack trace thanks to our monitoring tool. With this, I found the code that caused the exception to be thrown. As you can see below, this code is querying all stylesheets in the DOM and doing something with the CSS rules of each stylesheet.

Uncaught DOMException: Failed to read the 'cssRules' property from 'CSSStyleSheet': Cannot access rules

Our monitoring tool also provides browser data, so I checked which browsers were affected the most. It turned out it’s mainly recent versions of Chromium-based browsers like Google Chrome. As many of my coworkers use Google Chrome as the main browser for development, I found it strange that no other developer stumbled upon this yet.
There were no tests for this function. I tried to replicate the issue with unit tests with Jest, but the tests ran through successfully.
I searched online for this particular error message and found some helpful posts regarding rather recent changes in Chrome. In the latest version of Chrome, CORS security rules are also applicable for stylesheets (similar to Iframe rules). You can load and render them, but you cannot access the content stylesheets loaded from another domain through JavaScript. While this information was helpful, I still did not understand why this should be a problem.

How to Fix the Error

With all the knowledge mentioned above, a theory formed in my head: What if somehow there were stylesheets loaded into the DOM that were not from us? This was the only thing I could think of that could cause this issue, so I began thinking, “How do stylesheets not from us get loaded into the DOM?”

The answer: browser extensions. You probably know web extensions that remove ads from websites or provide functionality that your browser does not have. Browser extensions are typically built on web technologies like HTML, CSS, and JavaScript. This means it’s totally possible for a web extension to load a stylesheet from another domain — unless you are not using extensions that do that.

The issue can be reproduced easily by injecting a style (e.g. by using the Chrome Developer Tools) that points to a CSS file from another domain (e.g. a CDN). If your CSS Stylesheet is from the same domain as the HTML, you will be able to access the document.styleSheets.get(index).cssRules property. Otherwise, it will throw the following error:

Uncaught DOMException: Failed to read the 'cssRules' property from 'CSSStyleSheet': Cannot access rules

Now that we understand and found the root cause, the fix for the problem is easy: only keep stylesheets that are loaded from the same domain or where href is null (this may be the case if stylesheets are inlined, such as when using Angular):

After the fix was released, we reached out to affected customers and they could confirm the issue was not occurring anymore. Besides, our monitoring tool also did not report any more occurrences of this issue, so we knew we were on the safe side.

Conclusion

Thanks for reading this short article. As you can see, the fix for the issue can be implemented in minutes, but understanding the root cause of issues often takes longer than we expect.

Did this help you? Let me know in the comments.

Why and how to use Static IPs in Frontend & Backend

Ali Kamalizade — Sun, 11 Oct 2020 16:39:57 +0000

Originally published on my Medium blog »

A beta customer once approached us because he was unable to login in to our Angular web application. The page was loading but any HTTP requests to our API failed. After talking to the customer we found that their company is using IP restrictions. Therefore, he wanted to know if we could provide static IPs which they could add on their side to allow using our application in their company.

Unfortunately, our cloud platform of choice (Render) did not directly support this feature yet at that point of time. Hence, we could not provide a definite list of IPs that would never change. That’s why we had to look for a product which could provide static IPs. Changing our cloud platform was off the table as we are quite happy with it even to this day. As this was the first customer requesting this, we also did not want to spend a lot of money for this right now.

Luckily, I stumbled over a solution which seemed to provide everything I’d need for now. QuotaGuard is a service which describes itself as “the world’s leading Static IP solution provider for distributed networks and cloud-based applications”. They support multiple cloud platforms including the one we use and the pricing is fair in my opinion.

In our case we only needed an inbound proxy which allows us to access our application from a static IP. Outbound would be necessary if we want to route traffic from our application to an external service via a static IP.

Keep in mind that aside from the account registration, the following steps are rather general so they should work with alternative solutions as well.

How to create an inbound proxy to use static IPs with QuotaGuard Static

Create an account
Create an inbound proxy. This requires you to provide the URL of your API.
Make sure to allow your application to use the inbound proxy
Make sure to use the domain URL instead of directly calling your API
Provide all the static IPs to your customers
Optional: only use the inbound proxy for certain requests or customers to not exceed your quota 🤓

After creating the inbound proxy we see the static IPs as well as the domain URL. We should provide interested customers the static IPs we can see here.

In our case, our Angular web application uses JWT for authentication. Pay attention to whitelistedDomains which includes the new domain URL of our inbound proxy.

// called on every request to retrieve the token
export function jwtOptionsFactory(tokenService: MyTokenService) {
  return {
    tokenGetter: () => tokenService.getToken(),
    whitelistedDomains: ['some-api.com', 'some-api.gestatica.com']
  };
}
// the actual module imports (simplified)
@NgModule({
  ...,
  imports: [JwtModule.forRoot({
      jwtOptionsProvider: {
        provide: JWT_OPTIONS,
        useFactory: jwtOptionsFactory,
        deps: [MyTokenService]
      }
    }),
  ...
}

The only thing left to do: use the correct URL for HTTP requests. In our case we created a feature flag for this. Hence, only customers which require this feature will use the inbound proxy while the rest will directly use the API as usual. However, we don’t know this information until the user is logged in so we always use the proxy for login requests.

getApiUrl(route: string, useStaticIps: boolean): string {

  if (!environment.production) {

   return 'https://some-api.com';

  } else {

   return useStaticIps || route.includes('authentication/login') ?

    'https://some-api.gestatica.com' :

    'https://some-api.com';

  }

 }

Conclusion

Thanks for reading this short post about using QuotaGuard as a solution for static IPs. As you can see the setup is done in a few minutes and everyone can access our application again. How do use static IPs in your products? Let me know in the comments.

Things to Consider When Choosing a Component Library

Ali Kamalizade — Sun, 11 Oct 2020 11:06:52 +0000

Modern UIs are composed of multiple components. Popular component libraries include components like:

Buttons
Forms: input fields, select elements, checkboxes, radio buttons
Dialogs, modals, and popovers
Cards
Tabs

Some of the most important things to consider when picking a component library:

Maintainability: Who are the people behind the library? Is it a company, a group of passionate open-source contributors, or a one-man army?
Flexibility: To what degree can this library be customized to your needs?
Ease of use: How difficult is it to use and integrate this library into a project?
Popularity: Is this library used by millions of developers or just a few developers in one company?
Dependencies: How much does this library depend on other third-party libraries?
Documentation and resources: Where and how can I get tutorials and other information about this library?

In this post, I want to take a closer look at this with a real-life example. The project will be an Angular web application and I’ll use the following component libraries:

Angular Material: A framework that contains material design components for Angular.
Bootstrap 4: The most popular CSS framework, originally created by Twitter.
ngx-bootstrap: An implementation of the popular Bootstrap framework which is intended for Angular applications.
Nebular: A customizable Angular UI Library with multiple components, themes, and further feature modules like Auth and Security.

While we’re taking a closer look at component libraries many of these aspects apply to libraries and frameworks in general.

Software Maintainability

Software maintainability is defined as the degree to which an application is understood, repaired, or enhanced. If you think about it: most SaaS are never finished. New features are implemented while countless bugs are squashed and new bugs are inadvertently introduced. So maintainability is an important factor for the long-term.

Let’s look at how our candidates fare:

Angular material is mainly driven by developers working in the Angular team which means they keep up with the Angular ecosystem.
Bootstrap has a lot of contributors and a rich ecosystem, so it will be supported for quite some time.
ngx-bootstrap is developed by the software development company Valor Software. While Bootstrap itself is quite mature, ngx-bootstrap is more or less bound to Bootstrap.
Nebular is mainly driven by the software company Akveo, which has experience in open source projects. They offer professional services if you need consulting or further help to develop your application.

Flexibility and Configuration

Different products have different needs, so UX and design can vary a lot. Take news websites — while TechCrunch and Verge both report technology news they differ in their visual representation and features.

Let’s look at how our candidates fare:

Angular Material provides multiple themes and can be customized using SASS. The Angular Component Dev Kit (CDK) is a set of behavior primitives for building UI components in a style-agnostic way.
Bootstrap can be customized using SASS. There is a variety of free and paid themes available.
ngx-bootstrap can be customized the same way as Bootstrap.
Nebular provides decent extensibility. You can use SASS or CSS Custom Properties (aka CSS Variables).

Ease of Use

Often in life, we pick things that are easy to use and require the least amount of effort. The same applies to picking the right library for a job. Some libraries can be installed with one command and you can use them right away.

On the other hand, some libraries depend on other libraries or need more effort to set up. Typically, integrating a library becomes harder if it requires other libraries or tools. Angular CLI has a great feature called schematics — template-based code generators for transforming a software project by generating or modifying code.

Angular Material can be installed with one command by using the Angular schematic.
Bootstrap requires jQuery and Popper.js, so all three of these libraries need to be installed. Since it’s primarily a CSS framework you can import parts of the library to keep your bundle sizes as small as possible. For example, it’s possible to just import its UI components but neglect the grid if you want to use another grid solution.
ngx-bootstrap needs Bootstrap so both libraries need to be installed. You also need to include the Bootstrap style. There’s a handy Angular schematic to automate these steps.
Nebular requires the Angular CDK so both libraries need to be installed. You also need to include the Nebular theme. There’s a handy Angular schematic to automate these steps.

Popularity

The popularity of software as a metric is interesting. On the one hand, popularity can be an indicator of a certain degree of quality — if thousands of developers are using the library, posting good things about it, it seems a good sign for the future of the project. On the other hand, popularity can be faked. Or it’s not applicable —when a joke project has more stars than most GitHub projects we can’t take popularity as a serious metric without taking a closer look.

Let’s take a look at how our candidates fare when it comes to popularity:

Angular Material has ~20k GitHub stars and more than 430 contributors. There are new (beta) releases rather frequently. There are quite a number of open issues but many are being resolved by the team behind Angular Material.
Bootstrap has ~141k GitHub stars and more than 1100 contributors. New releases are not as often as for some more recent projects. However, Bootstrap is quite mature at this point and therefore focuses more on stability and consistency than piling up features. For a project of its popularity, there are quite a few open issues.
ngx-bootstrap has a few thousand GitHub stars and around 100 contributors. New releases are not seen as often as for some more recent projects. As ngx-bootstrap is a wrapper around Bootstrap the project won’t make drastic changes, which helps with stability but hinders innovation.
Nebular has ~6k GitHub stars and more than 80 contributors. There are new releases rather frequently. The project is still rather young but gaining traction.

Dependencies

Most software projects have third-party dependencies. Especially in the beginning of a software project, when you want to build an MVP quickly, you don’t have the time and resources to implement everything yourself. This is one of the most compelling reasons for choosing a component library. Successful companies like Airbnb or Atlassian often create component libraries, which are sometimes even open-sourced. However, it can get increasingly difficult to do.

Let’s look at how our candidates fare:

Angular Material requires no further third-party dependencies.
Bootstrap requires jQuery and Popper.js. Luckily, jQuery probably won’t be required anymore when Bootstrap 5 will be released.
ngx-bootstrap requires Bootstrap and Angular. However, you don’t need to include further scripts like jQuery or Popper.js, which are normally required when using Bootstrap.
Nebular requires no further third-party dependencies except Angular.

Documentation and Resources

When you approach a new topic, tool or language many developers search for information on the internet. There are a few ways to get information: posts on Stack Overflow, official documentation, and how-to tutorials. Raise your hand if you’ve ever copied and pasted an error message into Google and clicked on the first search result!

Angular Material has good documentation with examples. I especially like that you can edit the examples in the documentation directly in your browser using StackBlitz.
Bootstrap has good documentation with examples for all components. Since it’s a widely used framework there are lots of tutorials and external resources available for Bootstrap.
ngx-bootstrap has good documentation with examples for all components.
Nebular has good documentation with examples for all components. However, it does not have as many external resources as some of its older competitors.

Evaluation

Now that we’ve talked about some important decision factors for choosing a component library we can evaluate our choices:

Angular Material is a good choice if you like material design.
Bootstrap is a solid choice if you want a simple and easy to use solution. However, with growing project complexity Bootstrap might feel too barebones.
ngx-bootstrap is a good choice if you want to use Bootstrap in an Angular project. However, you implicitly rely on Bootstrap.
Nebular is a great choice and my personal winner. It’s heavily customizable and there are useful extensions around it.

As you can see there are always tradeoffs to be made. It depends on your needs — often, a perfect solution is not available. In a smaller project, all you need may need is basic components like buttons, while in a larger project you often need things like forms, grid systems, tables, and more.

Creating a Component Library? Evaluate Carefully

As mentioned above, successful companies often create their own component libraries. If you modify 90% of the code to make it work for you, you might be better off creating your own components.

This was the case for Airbnb with the popular react-dates project. They tried out solutions and had to change so much code that, at some point, they decided to build their own. The answer to the question of whether to create a component library is, as always, that it depends.

When I talk creating your own component library I’m not talking about making a fancy button and calling it a day. There are important aspects you need to consider:

Development costs: Someone needs to actually implement the components.
Maintenance costs: R.equirements change and so does software. Be careful — the effort of maintaining code is often underestimated.
Accessibility: Popular component libraries often make sure to incorporate accessibility. Sadly, in many projects accessibility is quite neglected. The Angular CDK includes multiple tools to improve accessibility, like implementing keyboard navigation.
User experience: Popular component libraries like Bootstrap are used on millions of websites in various ways. This means users have experience with them and are accustomed to them.

Conclusion

Thanks for reading this post. As you can see, picking the right component library can be difficult. Choose wisely as it will be more expensive to change it later.

If you’re a startup, a single developer, or if the project is not too complex then I recommend picking an existing component library. However, at some point, you might reevaluate whether it makes sense to create your component library when you find that existing component libraries don’t fit your needs anymore.

What makes you choose one component library over another? Let me know in the comments.

es-check-action - check JavaScript files against a specified version of ECMAScript

Ali Kamalizade — Sat, 05 Sep 2020 10:14:40 +0000

My Workflow

es-check-action checks JavaScript files against a specified version of ECMAScript (ES). If a specified file's ES version doesn't match the ES version argument, this action will throw an error and log the files that didn't match the check.

In modern JavaScript builds, files are bundled up so they can be served in an optimized manner in the browsers. It is assumed by developers that future JavaScript—like ES8 will be transpiled (changed from future JavaScript to current JavaScript) appropriately by a tool like Babel or TypeScript. Sometimes there is an issue where files are not transpiled which would cause issues in browsers who don't support all the latest features (e.g. IE11).

Check out my blog post about this topic (Medium.com)

Main motivation: avoid unexpected issues with unsupported features in web browsers without having to always do manual checking in those browsers.

Submission Category:

I'd say it's Maintainer Must-Haves but it also belongs somewhat to DIY Deployments.

Yaml File or Link to Code

The source code including a example is available on GitHub.

ali-kamalizade / es-check-action

A GitHub action that checks JavaScript files ES version against a specified ES version. If a specified file's ES version doesn't match the ES version argument, this action will throw an error and log the files that didn't match the check.

es-check-action

This GitHub Action checks JavaScript files against a specified version of ECMAScript (ES). If a specified file's ES version doesn't match the ES version argument, this action will throw an error and log the files that didn't match the check.

Check out my blog post about this topic.