By definition :before and :after are CSS pseudo elements. You can use them to insert something before or after the content of an element. There are some great articles giving the basics, but I wanted to write down a blog post for the real use cases. Or, at least, to show what I'm using them for.
In my company, we have a lot of WordPress sites. Some of them require contact form with captcha field. The short way for solving such task is to use a plugin. However, as you may guess, the add-ons are available for everyone, which means that they could be easily explored and probably hacked. That's why I suggested a simple, custom script, which is developed by us.
The browsers nowadays are smart. They optimize everything and help us to produce better applications. They process our code as fast as possible and even on mobile devices deliver a pleasant experience. However, at the same time, it is possible to write buggy code and make the browser freezing. We are not talking about slowing down the rendering. We are talking about no rendering at all. There are cases where we want so much from the browser that it just can’t handle it.
Before a couple of months my first book Node.js Blueprints was published by Packt. There are a couple of reviews in Amazon about chapter two. It’s about Express. One of the most popular frameworks in the Node.js ecosystem. The book mentions version 3.0 but the truth is that the code samples are for version 4.0. I feel that I still have to point out the differences and mark these parts of the chapter that are not valid for the newest version of the library.
You probably know the famous quote that the code should be written for humans to understand and accidentally for computers to execute. Writing code that compiles is easy. Writing readable code is completely different thing. Working in a team is like sharing the kitchen with your roommates. You all should care for the dishes and keep clean. And it is not only because of the others but because of you. You don’t want your dinner in a mixed place and dirty dishes right.
Well, I kind of lied in the title of this article. Of course that it is the end of the function. Once we call
return everything else after that is simply not executed. Ops … I did it again, I kind of lied again.
I’m writing code for approximately ten years now and at some point the word “writing” became more important then “code”. I found out that it is easy to generate code but it is difficult to write code. Writing means creating something meaningful. Something that other human beings will read. The code is indeed sent to machines and they do understand ugly code. Not the same for humans though. An important part of our job is to make sure that our code is clear for other teammates.
I had some time during the weekend and decided to work on my slides for an event at the end of the month. I reached the part where I have to do a live coding session and I was wondering what tool to use. At the end I created my own called Demoit. This is a short article explaining how it works.
I'm using Git and GitHub in particular a lot. And when I say a lot I really mean all the time. Recently I tracked a week of work and found that 62% of my working time goes into code reviews. Sometimes I'm checking out a branch locally and trying stuff but really most of my time goes into github.com. I spent some time analyzing why the code review process is so time consuming for me. I identified couple of reasons, made a tool and changed some of my habits. In this article I'll show you how I improved my code review speed and lower the time to 38%.
I'm now actively working on a VSCode extension. I started it as a theme but then decided to add some more features. Like for example a tin line on the left side of the editor marking the current function scope. In order to do that I had to analyze the current file's code and find the lines that are included in that scope. The obvious approach will be to translate the code to AST and then traverse the tree finding the information that I need. This however will require the usage of a language server which now I don't want to deal with. So I decided to explore a brute force approach. Looping over the string characters and finding balanced matches. I quickly wrapped it into a library. I called it Pairify. It consumes text and returns an array of pairs. This blog post will show you how it works.
I'm continuing to experiment with React and TypeScript. The weekend-long project this time was a Covid-19 data tracker. In this blog post I will share how I built c19stats.now.sh. I exposed the data as a public API at the same URL. I guess you, as many other people, follow the situation so you may want to glue your fingers on the keyboard and create something useful around the data. I got lots of fun playing with the diagrams.