Originally I wanted to write about Unicode, but I have realized that it is better to start out with the basics, and you can’t get more basic than the ASCII table.

As computers can only represent two kind of values — true or false — some clever folks back in the middle of the twentieth century constructed a table where they gave meaning to some combination of zeros and ones. That’s how we got this nice table of characters that we actively use even today.

The original ASCII table was 7-bit based. That means that it used only 7 zeros/ones to represent a character. For example to write the character “A” you would send the following down the wire

100 0001

Notice the way I formatted the above code — yes, the little space between the first three characters and the last four. There is a reason behind it, namely you can decide the kind of character you are dealing with using only the first...

In the last post – Pipes in the shell – I wrote about regular, unnamed pipes in the shell. Now I want to continue that story with a little introductory to a related topic — named pipes in unix. They are not as useful or versatile as their unnamed friends, but sometimes they can help you a lot.

A named pipe is very similar to an unnamed pipe. It also connects the output of one command to the input of the second command. But, a named pipe is also very similar to a file, as it is saved in the file system. To create such a pipe we need to use the mkfifo command, where the fifo part signifies that it is a – first in, first out – kind of buffer.

cd /tmp

mkfifo testpipe1

Filtering files by their title

With an unnamed pipe I could list all the files in a directory that had the string “cat” in their title

ls -l | grep "cat"

With a named pipe I can do the same using the previously...

Here is a story of my typical work session in the shell. It starts by a wish to make the computer execute some of my commands. For example, I want to list all the files in the current directory. From prior knowledge I know that the ls command does exactly that, so I use it, and get the desired output. But I am out of luck, the current directory contains too many entries and I just can’t scroll so much up in the history.

I also know that there is this nifty little command called more that paginates any text that it receives on the input. If only I could just somehow connect the two.

Pipes to the rescue! With them I can connect any two programs together and make them do things they couldn’t on their own. So I get the following

ls | more

The strange little vertical line between ls and more is called the pipe operator. It connects the output of the first program with the input of the...

I spend a lot of time in shell. Like really a huge amount of time. I use my editor through a shell. I test my code locally in the shell. I could safely assume that 70 procent of my productive time is spent on various shell activities and rest is probably spent in the browser.

Yet, I known very little about writing a shell script. I didn’t really even known the difference between sh, bash, dash, zsh and csh. I always planned to learn it, but I have postponed it endlessly. There was always something cooler to learn, something more interesting to read about.

But one day I have stumbled upon a Github repository that implemented a breakout like game in pure shell script. It was a strange idea. Shell is probably not the best language for game development. It is not even a worthy candidate. Yet, the process of writing a game could teach me a lot about loops, conditions, functions and the rest...

Just several months ago I was a big time Sublime Text user. I was proud of the fact that my editor is lightweight, fast, and easy to use. The plugin architecture is awesome, especially combined with the search functionality where I could look up new plugins just by typing a remotely similar word to it’s title or description.

I thought I was as productive as I could ever be. And probably I actually was much more productive than in any IDE or editor I have tried and used during the previous years. But, as I have started to work at a new company I was proven wrong. Really wrong.

On my first work day, right after I have showed my handcrafting skills in putting together my new desk, the college I share the office room with set up my work environment, and he set up vim as my primary editor and basically forced me to use it.

Now, it wasn’t my first time using Vim. I have used it already to...

Learning what an unfamiliar API action does is often hard. I have tried various things to speed up my learning process, but the only thing that I have found to be working for me is to test each interaction with the API by hand. I like to mess around with an API before I actually write any code or implement a feature. One good way to get a quick and easy glimpse of what I can expect from an API is to send some curl request and experience the action’s response in the most straightforward way possible.

There are lot of things I can learn from exploring an API this way. I can get a solid feeling about the complexity of the API, to know is it hard to explore new actions, and if the whole API uses a consistent structure or if every interaction with it has a unique way to communicate it’s response. Needless to say, I prefer consistency over uniqueness, and an API that leads me to explore it...