DEV Community: Dmitrii Kabardinov

Hey Developer, Don't Forget To Move 🏃‍♂️

Dmitrii Kabardinov — Wed, 10 Feb 2021 21:17:06 +0000

I work as a software developer and like many others, I’ve been working from home for almost a year now. Personally, I like it more than I don’t, but there are a few potential downsides to that. One of which is, since we don’t have to go to work anymore, it’s very easy to forget to move as much as one should to stay healthy.

In this post, I wanted to share a couple of tools that help me stay active. But first, let's make sure everyone is on the same page about the benefits of physical activity.

1. Physical health

Everyone knows that exercises are good for your health. From kindergarten, we are taught that regular physical activity reduces risks of cardiovascular diseases, improves blood pressure, etc. All the good stuff. But you probably already know that.

2. Endorphins

This is also a pretty well-known fact, I think. You can raise endorphins levels just by doing 15-mins workouts several times a week. It decreases the chances of depression and anxiety, which is great.

3. Memory and Intellect

And these reasons alone are good enough, but it's not all that there's to it. There's this other side, and it seems to me it isn't spoken about nearly as much as the previous two. Well, either that or I've been living under a rock for the past couple of decades.
I learned about it kind of randomly not so long ago, when I was taking this Coursera MOOC called Learning How To Learn (I'm a student, and I wanted to know how to study more efficiently). One of the instructors on this course is Dr. Terrence Sejnowski, who is a very prominent neuroscientist. And in one of the course's videos he said that until recently, it was thought that the growth of new neurons did not occur in adult people's brains. Yes, science said, you can learn new things during life, creating new connections between neurons, but they're the same old neurons that you had when you were born. However, Dr. Sejnowski and his colleagues at the Salk Institute discovered that in an important part of your brain, which is responsible for learning and memory, the Hippocampus, new neurons are being born even in your adulthood. And it appears that exercise helps this happen.

If you are interested in details, check out this article about the discovery. And here's a couple of more recent publications on the subject: one, two.

I don't know about you, but I think it's pretty cool. I mean, exercises literally make you more brainy! So next time you are struggling with a bug in your code, try going out for a quick run, and maybe while you are moving, the solution will come to you.

Apps for home workouts

Ok, now when we've established that it's super important to exercise regularly, let me tell you real quick what helps me in my daily training. Of course, there are a number of options to chose from if you decide to start exercising.
Depending on the situation with COVID in your country, going to a gym, or swimming pool might not be such a great idea yet. Many of us still try to minimize our social contacts, and working out at home is the only way to stay active for many people. Jogging is a good option as well, and, personally, I love it; however, I'm not keen on running when it's cold or muddy outside.

So last year I discovered a couple of mobile apps that are absolutely free but nevertheless incredible in terms of their usefulness. What's amazing about them is that neither of them shows any ads, despite being totally free, and taking into account the amount of awesome quality content that they provide. Granted, they ARE kind of ads themselves, that is their sole purpose is clearly to promote big brands behind them, but, honestly, it doesn't bother me.

The two apps that I'm talking about are NTC, which is short for Nike Training Club, and Adidas Training App. They are both great, but I tend to use NTC most of the time because it has yoga, and workouts are not limited to bodyweight only. However, Adidas has nice unique features too. For instance, it allows you to create custom workouts. It's really neat: you select a preferred duration and target muscle group and, voila - it suggests you a set of drills, which you can further fine-tune, replacing the ones that you don't like. Another really nice touch in the Adidas app is the ability to filter out the drills that are not neighbor-friendly. I live in an apartment, so this comes in quite handy for me. Both apps include warmup and cooldown into all their workouts, so you don't have to worry about that. Also, there are modifications to most of the movements, so that people with all levels of the physique could follow along.

Anyway, if you haven't tried these apps, I highly recommend that you download them and try to experiment. See if they work for you.
Thanks for reading, have fun and take care!

10 Things I've Learned While Building A Website For My Blog 📚

Dmitrii Kabardinov — Sat, 07 Nov 2020 16:55:56 +0000

If you are thinking about starting a blog one of the first decisions you have to make is where to host it. If you want to just focus on writing it's perfectly fine to opt for ready-to-use blogging platforms. However, if you have some basic knowledge of HTML and CSS, building a website for your blog from scratch is a good way to grow as a developer. Below is the list of things that I haven't had practical experience with until I've started building my blog.

1. Eleventy and liquid templates

I haven't used static site generators before, and for a long time, I've been curious, what they are about. It was nice to finally try one out. I've written a detailed post about it, all I will say here is that static site generators and namely Eleventy is my favorite tech thing of 2020. Eleventy is so much fun that I have this urge to build more static sites with it.

2. Lighthouse

From the start, I've been focused on performance for my blog, so, naturally, I had to try Lighthouse, which I've heard a lot about but never actually used myself. And after having tried it I've got to say it's great.
It helps you avoid the most common pitfalls by running a set of audits on your site and generating neat reports with links to learning materials on each problem. Tackling all of them and getting to that precious "100" score is no easy feat, but it will most certainly improve your site's user experience and ensure fast loading. From now on I'm going to use Lighthouse on all my projects. By the way, Eleventy has a Performance Leaderboard of the sites built with it. You can submit your site to participate and it will be ranked according to the Lighthouse score.

3. Accessible colors

Accessibility is another thing that I tried to keep tabs on during this blog's development. I've expanded my understanding of accessibility beyond just using ARIA attributes. Trying to tick all the boxes for the Lighthouse accessibility audit I learned about color contrast standards. I relied heavily on Accessible Colors, an awesome tool that can recommend necessary adjustments to your color scheme to make the contrast ratio high enough so that your content is discernable for people with all kinds of vision impairments.

4. Responsive images

My current project at my job is more of a web-application than a traditional web-site and we barely use images there, let alone large images. So I didn't need responsive images. A blog is a different story though.
An image is worth a thousand words as an old saying goes. I like to break a long post with an image illustrating the idea I'm describing, and I know that some part of traffic to my site comes from smartphones. It would be a waste to serve large images to clients with small screens. Enter responsive images. With a <picture> tag I can serve different images depending on the size of the screen like this:

"/>

5. CSS variables

I'm used to working with CSS preprocessors at my job. We use SASS on my current project, and it was Less on the previous one. Until I started working on this blog I can't remember when was the last time I wrote vanilla CSS. Meanwhile, CSS hasn't stopped developing and there's a lot of stuff that CSS supports natively now, which was only possible through preprocessors before. One example would be the variables. Dark/Light mode toggle implementation on this site relies on CSS variables. Who knows, maybe one day we won't need CSS preprocessors at all.

6. Font subsetting and variable fonts

While I was implementing the dark mode I have noticed that the same font-weight seemed too thick when it was white text on a dark background. Apparently it's a thing. I've found an article with a solution for this issue that uses a variable font. The trick is to decrease font-weight via CSS. Unlike regular fonts, which don't support font-weight values smaller than 400, variable fonts allow any number within the font's width range as font-weight value. But there was one problem. For a long time, I was afraid of using web fonts because of their detrimental effect on page loading time. But to be able to adjust font-weight in dark mode I had no choice but to use a web font. So I started researching how to make web fonts load fast, and it led me to learn about font subsetting – a technique of stripping the font file of the unnecessary characters to make it slimmer. Glyphhanger is a great tool for that. After having used it for my blog and seeing an impressive decrease in the font file size, I'm no longer afraid of using web fonts.

7. Systemd

To keep my Node.js HTTP server running I had to learn how to register services with Linux init system - systemd. Eventually, I switched to NGINX from Node.js, making this work obsolete, but hey, it was still an interesting and informative experience. Before that, I only used things like PM2 for managing Node.js processes.

8. CDN

CDN is an important part of JAMstack, so I had to learn how to use CDN if I wanted to get into the cool kids club. Just kidding, haha. On a more serious note, though, until now, my experience with CDNs went only as far as importing popular libraries from CDN servers instead of serving them from your host. For this blog, however, I went further and made it so that all the traffic to my server was managed by Cloudflare CDN. To do that I had to update NS records for my domain with Cloudflare nameservers. These nameservers return Cloudflare IP addresses when DNS lookup for my domain happens. Proxied traffic comes to Cloudflare edge servers and then they forward the request to my server. It helps me to improve my website page's loading time by serving cached versions of the pages. While this is awesome, it brought new challenges, such as a problem of cache purging. I had to implement a mechanism that uses Cloudflare API to purge cache on redeploy. If you are interested in details, I wrote a post describing my approach.

9. Amazon Web Services

I've been somewhat familiar with AWS as I encountered it at my job, but as a frontend engineer, I have never been involved in the cloud infrastructure setup too much. Hosting my blog on AWS EC2 forced me to dig into AWS docs and do everything myself, starting from registering a domain on their Route 53 to learning how to use CodeDeploy and CodePipline services to setup CI/CD so that I could redeploy just by pushing the code into the main branch. I had to figure out how to store secrets with their Systems Manager parameter store (I need to store Cloudflare API token for automatic cache purging on deploy). After having to do all of that, I feel much more comfortable with the AWS console.

10. SEO

At my job, I build web-apps for internal usage that are not exposed to the Internet, and therefore Search Engine Optimization is not something that we think about. Building a web site for a blog is different because, usually, you want your articles to be discovered through search engines. So I had to learn at least basic things about SEO, like adding description in meta tags or generating a sitemap for crawlers, or what a canonical link is.

And this concludes my list. Yours will most certainly look different because we are all unique and each has different background and experience. But one thing is for sure - if you choose to build a site for your blog, you will learn something.

3 Reasons Why You Should Choose NGINX Over Http-server For Your Static Site

Dmitrii Kabardinov — Sat, 26 Sep 2020 21:41:38 +0000

My server went down the other day and since I had to address it anyway, I decided to simplify my setup while I was at it. When I was finished I thought why not write a post describing my initial setup and what I ended up with. If you are choosing a server for your static blog, I hope this article will help you avoid making the same mistakes I made, and save you some time.

Why I went with http-server at first

I host this blog on an instance of AWS EC2, which runs ubuntu. For those who are unfamiliar with AWS EC2, it's a virtual machine that runs in the cloud and that you can do anything you want with. Because of this freedom, when the time came to chose the HTTP server that would serve my static files I had a lot of options. I considered different candidates but there were two clear favorites: NGINX and, perhaps, less known Node.js module called http-server.

Having encountered NGINX on a few work projects, I was somewhat familiar with it, and I knew it could do the job flawlessly. There was just one hurdle associated with it for me - it required some configuring, and I was too impatient for that. I wanted a tool that didn't require any configuration at all. Given a folder, it should start serving files from this folder. In other words, it should JUST WORK. And http-server offered exactly that. I used it a couple of times when I needed a development server for one of my pet projects, and I liked it. Now I wanted to see how it would perform in production. So I picked it over NGINX.

The image on the package's npm page reassured me once more that I had made the right choice.

"Serving up static files like they were turtles strapped to rockets", said the image.

All I needed to setup my server was to run two simple commands:

npm i http-server

and then

http-server .

executed from my website folder.

Reason 1: http-server can't run on default ports

So I installed it and ran it only to discover that it can't listen to the ports 80 or 443 (default ports for HTTP and HTTPS respectively). Apparently, it's a common restriction for Linux systems - the lower port numbers require root privileges. I could bypass this by running http-server with sudo, but I felt icky about it. I mean, I'm no security expert but I suspect that it's probably not safe to run Node.js server with root privileges.

The simplest workaround for this that I could think of was to use NGINX as a reverse proxy that would redirect requests from port 80 or 443 to the one that I run my http-server on. It's possible because unlike http-server, NGINX isn't a subject to this limitation. So it seemed I was going to need NGINX after all. Now, if I was going to install NGINX anyway, the logical thing to do at that point was to abandon http-server and just use NGINX as a server directly. But I felt bad about removing http-server. I wanted to give it a chance, and besides, I wanted to experiment and try this proxying approach too, because it seemed cool, ha-ha.

Note: there are other ways to solve this, but they all seem to require some familiarity with Linux.

Reason 2: http-server can't gzip files

Another, and, perhaps, the biggest disappointment with http-server for me was that, as it turned out, it doesn't provide gziping capability. When I skimmed through the docs I saw a flag --gzip and I thought that it was what I needed. What this flag does, however, is it tells the http-server to serve gzipped version of an asset if it will find it alongside the original, uncompressed file. So it is up to a user to gzip the assets somehow. Of course, I didn't want to do this. I was ready to pull the plug on http-server because of this nuisance, had NGINX not solve this problem too. To my pleasant surprise, NGINX was gzipping everything that was going through it before sending it to the client. In the end, I didn't care who does the gzipping, so I decided to leave the http-server be.

Reason 3: http-server doesn't restart after crash

There was one last thing I had to do to ensure that my setup was robust. in case if my http-server was to crash, there was no mechanism in place to restart it. And since we are comparing the two technologies, it's another point in favor of NGINX - it works as a service by default, so you don't have to do any additional steps to ensure it's always running. It will start after reboot automatically and it will be restarted if it fails. For http-server I had to do some additional work to achieve the same effect.
Following this tutorial I created a systemd service that would take care of keeping the http-server alive.

Now I was covered. Yes the setup was unnecessary complex and it was bugging me a little bit, but it worked.

Fast-forward to this weekend, when suddenly something broke on my server. Fortunately, Cloudflare CDN, which I use for this blog, has this neat "Always Online" feature that masks the original server failure by continuing to serve cached pages. Still, I had to go and see what was wrong on the server. And I thought that it was a good opportunity to start over with a clean slate and do everything right this time. So I removed http-server and simplified my NGINX config using this guide. The whole process of configuring NGINX took about 15 minutes or so. I shouldn't have feared it from the start.

Conclusion

If you are thinking about using http-server or, for that matter, any other Node.js package as a server for your static site, I would recommend using NGINX instead. It has everything a typical static site might need: it can gzip your files on the fly, it supports HTTP 2.0. Moreover, because it's very popular, tools like certbot are aware of it, which makes enabling HTTPS a breeze - certbot takes care of updating NGINX config for your site automatically. Yes, you have to configure it, but I think it's worth spending 15 minutes on it because once you do it, it's not going to need any more of your attention.

As for http-server, I don't want to come across as a hater. I'm not saying that it's a bad package. It's great for its simplicity, and I will continue to use it, but only as a development server. For production purposes, in my opinion, it lacks some key features such as gzipping. Also, it requires a few additional steps to be able to listen to "privileged" ports and to start on boot.