Around IT in 256 seconds

#18: JIT: bytecode, interpreters and compilers

Source code can then be executed in two ways. Language implementations in general either interpret or compile it. In order to run an interpreted program you need one extra binary: an interpreter. Interpretation is simple: you read source code line by line and execute it. The compilation is much harder. A special program called a _compiler_ reads your source code ahead of time (AOT) and translates it into machine code. After this translation your program is standalone. You don't need a compiler to run it. Only you and your CPU.

#16: Akka: distributed actor-based toolkit for the JVM

Akka is a toolkit for building highly scalable, concurrent applications. It's written in Scala and based on the ideas from Erlang. Its approach to achieve concurrency is quite radical. Rather than mutexes, semaphores and shared memory, Akka uses so-called _actor model_. An actor is a small, stateful object that doesn't expose traditional methods. Instead, actors send and receive asynchronous messages with each other. There is no other way to interact with an actor. If you want an actor to do something or give you some information, message passing is the only way. Send a message, actor will receive it at some point in time, consume it and optionally send a response back.

#15: Mutation testing: who tests your tests?

Imagine I wrote a script that takes your codebase and removes a random line. Fairly simple. Or maybe some more subtle change, like replacing plus with minus operator? Or switching `x` and `y` parameters with each other? OK, so now my script builds your project. Most of the time it will fail the compilation or test phase. But what if the build succeeds? Well, apparently your test suite is not covering some lines? OK, but what if my script only removes or alters lines covered by tests? How is it possible that the build still succeeds? Turns out your tests aren't as good as you think. And I just described mutation testing that discovers that.

#14: Static, Dynamic, Strong and Weak Type Systems: understand how your language treats data types

When choosing or learning a new programming language, type system should be your first question. How strict is that language when types don't really match? Will there be a conservative, slow and annoying compiler? Or maybe a fast feedback loop, often resulting in crashes at runtime? And also, is the language runtime trusting you know what you are doing, even if you don't? Or maybe it's babysitting you, making it hard to write fast, low-level code? Believe it or not, I just described static, dynamic, weak and strong typing.

#8: Kafka's design: append-only file that turns out to be a scalable message broker

Kafka is not a message broker. However, it can be used as such very effectively. Instead, I'd like to think about as a very peculiar database. A database where inserts are insanely fast and sequential reads are preferred and very fast as well. Also, there is very little support for deleting and updating data. In this episode I am focusing on the architecture and internals of Kafka. The best way to understand Kafka is by examining how it works.