Skip to main content
Around IT in 256 seconds

Around IT in 256 seconds

By Tomasz Nurkiewicz
Podcast for developers, testers, SREs... and their managers.
I explain complex and convoluted technologies in a clear way, avoiding buzzwords and hype.
Never longer than 4 minutes and 16 seconds.
Because software development does not require hours of lectures, dev advocates' slide decks and hand waving.
For those of you, who want to combat FOMO, while brushing your teeth.
256 secondsis plenty of time.
If I can't explain something within this time frame, it's either too complex, or I don't understand it myself.

Hosted by Tomasz Nurkiewicz. Java Champion, CTO, trainer, O'Reilly author, blogger.
Listen on
Where to listen
Apple Podcasts Logo

Apple Podcasts

Breaker Logo

Breaker

Google Podcasts Logo

Google Podcasts

Overcast Logo

Overcast

RadioPublic Logo

RadioPublic

Spotify Logo

Spotify

Currently playing episode

#19: GraalVM

Around IT in 256 seconds

1x
#23: Garbage collection
Creating new objects, arrays or strings is so straightforward that we often forget what happens underneath. And I don’t mean trying to figure out what this refers to in JavaScript objects. I mean: memory management. On each request we create a ton of objects. A server can easily allocate hundreds of megabytes of memory. Per second. Memory is cheap and there’s a lot of it. But it’s not infinite. How come we can simply call new Object() over and over again, taking more and more memory from our computer? Many objects are no longer needed a few milliseconds after they’re created. What happens to the memory they occupy? We take for granted what was thought to be almost impossible: automatic memory management. Read more: https://256.nurkiewicz.com/23 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:15
November 30, 2020
#22: Moore's Law
It's a common misconception that Moore's law is dead. That's because many believe it's about the speed of a CPU. But in reality Gordon Moore meant the number of transistors, not the clock frequency. And also, it's now even a law. Just an observation that holds true after half a century. OK, so what does this "law" state? Gordon Moore, before co-founding Intel, noticed that the number of transistors in a CPU doubles every two years. This means exponential growth. Which is a lot. So why are these transistors important? Read more: https://256.nurkiewicz.com/22 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:11
November 23, 2020
#21: SSE and WebSockets
HTTP is historically request-response-driven. This means a server is idle as long as no-one asks it to do something. Typically fetching data or accepting some form. In reality, we’d often like to receive data from the server without any request. Typically to subscribe for some server-side updates. For example, displaying a current price on the stock exchange that changes many times per second. Or when waiting for some asynchronous process to complete. Traditionally this could be achieved with a few hacks. The most obvious and the worst one is busy-waiting. You simply keep asking the server over and over again periodically. More frequent requests result in a lot of excessive network traffic. Less frequent requests increase latency, so it’s no longer real-time communication. A slightly smarter approach is long-polling. In this implementation, you periodically ask the server whether there is some new data. To avoid excessive round-trips, the server doesn’t respond until some update is available. Or, after a timeout, it sends back an empty response and the loop continues. Read more: https://256.nurkiewicz.com/21 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:14
November 3, 2020
#20: Chaos engineering
We tend to focus on testing happy paths and expected edge cases. But how do you make sure that your system can survive minor infrastructure and network failures, as well as application bugs? Especially in microservice or serverless environment, where there are tons of moving parts. I've seen too many times systems that fail miserably because some minor dependency was malfunctioning. For example, you have a tiny service that displays a small social widget on your website. When that service is down, the rest of the website should work. But without proper care and testing, you may end up with global HTTP 503 failure. Code reviews and unit tests are fine, but the ultimate test is... turning off that service on production. And making sure the rest actually works. This is called chaos engineering. Believe it or not, many organizations do practice deliberately injecting faults into production. Now, turning off a service's instance on production is probably the easiest test you can conduct. The client must catch an exception and handle the failure gracefully. Sometimes by retrying, hoping to reach another healthy instance. Sometimes by returning a fallback value that's less relevant or up-to-date. Ideally, the end-user should not realize one of the services is down. Of course, that would mean that a failed service is not needed at all and can be shut down forever. So in practice, we expect visible, but insignificant degrade in service quality. Read more: https://256.nurkiewicz.com/20 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:14
October 26, 2020
#19: GraalVM
GraalVM is a set of tools that aim to improve the performance and interoperability of Java Virtual Machine. Taking advantage of GraalVM not only makes your apps run faster. It also allows running different languages like JavaScript or Python with superb speed. GraalVM consists of quite a few projects, so let's dive in. The most groundbreaking technology is the JIT compiler. To recap, JIT is responsible for translating abstract bytecode into low-level machine code. JIT is the reason why Java is actually quite fast these days. Your code is compiled behind the scenes into heavily optimized CPU instructions. Unfortunately, this wonderful piece of software was buried deeply in Java VM.  The JIT codebase in C++ turned out to be too complex to maintain anymore. So someone thought: what if we rewrite JIT compiler in Java? Sounds crazy. But as a matter of fact, JIT is essentially a pure function that takes bytecode as input and returning machine code as output. Byte array in, byte array out. That's how GraalVM was born. Now you can plug-in a JIT compiler written in Java to a JVM. Suddenly the codebase became much more maintainable and developer friendly. GraalVM's JIT compiler quickly outperformed legacy JIT compiler. Essentially it is now much easier to write optimized machine code generation. But it turned out this was just the beginning. Read more: https://256.nurkiewicz.com/19 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:14
October 19, 2020
#18: JIT - Just-in-time compilation
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. Turns out this distinction is not that clear at all these days. Almost every language implementation performs compilation behind the scenes. And many languages that have a compiler produce code that needs an interpreter anyway. What? Read more: https://256.nurkiewicz.com/18 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:15
October 12, 2020
#17: BPM: Business process modeling
[...] All of this complexity is somewhat hidden with BPM framework. First of all the process is first drawn. Using a special notation known as BPMN. This is actually quite natural. You use arrows to show how insurance claim changes state over time - and why. Then the diagram is translated into fairly standard XML. Now those pesky developers need to fill in the gaps. I mean, writing code that does some logic. For example sending an SMS when a claim enters a certain state. Or transferring money when a transition happens from one state to another. [...] Read more: https://256.nurkiewicz.com/17 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:16
October 6, 2020
#16: Akka
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_. 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.  Read more: https://256.nurkiewicz.com/16 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:16
September 22, 2020
#15: Mutation testing
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. Read more: https://256.nurkiewicz.com/15 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
03:55
September 14, 2020
#14: Static, Dynamic, Strong and Weak Type Systems
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. Read more: https://256.nurkiewicz.com/14 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:13
August 31, 2020
#13: Cassandra
Cassandra is an open-source NoSQL database. It's heavily optimized for writes, but also has intriguing read capabilities. Cassandra has near-linear scalability. In terms of CAP theorem it favours availability over consistency. Interestingly, despite NoSQL label, Cassandra tables have strict schema. Also, Cassandra Query Language is similar to SQL. Read more: https://256.nurkiewicz.com/13 Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:15
August 18, 2020
#12: Continuous integration, delivery and deployment
Typically, more than one developer is working on the same codebase. How do they share their work? The simplest approach is a common Dropbox folder. This has several drawbacks, mainly we risk breaking other's work with our half-done features. So we come up with version control systems. Read more: https://256.nurkiewicz.com/12 Get new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:14
August 11, 2020
#11: MapReduce
MapReduce is a programming model for processing large amounts of data. It works best when you have a relatively simple program, but data is spread across thousands of servers. MapReduce was invented and popularized by Google. I'll talk about MapReduce in general and Hadoop in particular. Read more: https://256.nurkiewicz.com/11 Get new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:15
August 4, 2020
#10: HTTP protocol
HTTP protocol is fundamental to the Internet. It's a simple request-response protocol where the request is initiated by the client, typically a web browser. Read more: https://256.nurkiewicz.com/10 Get new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:15
July 27, 2020
#9: Retrying failures
I find it quite fascinating how many failures in complex systems could be avoided if we simply... tried again. So how so you retry effectively, so that your systems are much more fault-tolerant and less brittle? Read more: https://256.nurkiewicz.com/9 Get new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:15
July 21, 2020
#8: Kafka's design
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. 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. Read more: https://256.nurkiewicz.com/8 Get new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:15
July 14, 2020
#7: Speed of light
Speed of light is not as abstract to us, software engineers, as you might think. If you are deploying to the cloud or if you want to squeeze every bit of performance in your app, speed of light holds you back. Light travels at an unbelievable speed of three hundred thousand kilometers per second. That's more than 7 times around the globe in one second. Is this relevant in our industry?  Read more: https://256.nurkiewicz.com/7 Get new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
04:11
July 6, 2020
#6: Little's law
Little's law is an astounding equation that's dead simple, yet it can bring an amazing insight into what your distributed system is capable of. Read more: https://256.nurkiewicz.com/6 Newsletter: https://256.nurkiewicz.com/newsletter More resources: * Little's law: https://en.wikipedia.org/wiki/Little%27s_law * John Little: https://en.wikipedia.org/wiki/John_Little_(academic) * Node.js and CPU intensive requests: https://stackoverflow.com/questions/3491811/node-js-and-cpu-intensive-requests * My talk where I mention Little's law (from 23:03: https://www.youtube.com/watch?v=5TJiTSWktLU&t=23m03s)
04:10
June 30, 2020
#5: asm.js and WebAssembly
Read more: https://256.nurkiewicz.com/5 Newsletter: https://256.nurkiewicz.com/newsletter More resources: * asm.js: https://en.wikipedia.org/wiki/Asm.js * WebAssembly: https://en.wikipedia.org/wiki/WebAssembly * Compiling C/C++/Rust/... to asm.js via LLVM backend: https://emscripten.org/ * Quake in the browser (asm.js): http://www.quakejs.com/ * Unity Engine in the browser (WebAssembly): https://blogs.unity3d.com/2018/08/15/webassembly-is-here/
04:13
June 16, 2020
#4: Serverless
Read more: https://256.nurkiewicz.com/4 Newsletter: https://256.nurkiewicz.com/newsletter 4th edition of the newsletter, apart from transcript, contains GraphQL scalability tricks, enjoy! More resources: * AWS Lambda: https://aws.amazon.com/lambda/ * Google Cloud Functions: https://cloud.google.com/functions/ * Azure Functions: https://azure.microsoft.com/en-us/services/functions/ * Spring Cloud Function: https://spring.io/projects/spring-cloud-function
04:15
June 8, 2020
#3: GraphQL
Read more: https://256.nurkiewicz.com/3 Newsletter: https://256.nurkiewicz.com/newsletter More resources: Official GraphQL website: https://graphql.org/ Curated collection of resources: https://github.com/chentsulin/awesome-graphql GitHub's API explorer using GraphQL: https://developer.github.com/v4/explorer/ Facebook's API explorer using GraphQL: https://developers.facebook.com/tools/explorer/ Visual GraphQL explorer for any API: https://github.com/graphql/graphiql A series of my blog posts about GraphQL in Java: https://www.nurkiewicz.com/2019/10/graphql-server-in-java-part-i-basics.html, https://www.nurkiewicz.com/2019/10/graphql-server-in-java-part-ii.html, https://www.nurkiewicz.com/2020/03/graphql-server-in-java-part-iii.html
04:15
June 2, 2020
#2: Service Mesh
Notable implementations of service mesh: * https://istio.io/ * https://linkerd.io/ More details: * What's a service mesh? And why do I need one? (https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/) * What's a service mesh? (https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh) * InfoQ (https://www.infoq.com/servicemesh/) * Service Mesh Landscape (https://layer5.io/landscape) * Service Mesh Comparison (https://servicemesh.es/) Read more at: https://256.nurkiewicz.com/2 Most episodes are originally much longer. If you wish to hear full, director's cut version, check out my mailing list: https://256.nurkiewicz.com/newsletter. I will also notify you about new episodes and add some extra content like transcripts. Suggest your topics: https://github.com/nurkiewicz/256/issues/new/choose
04:15
May 26, 2020
#1: Circuit Breaker
Circuit breaker is a design pattern that prevents cascading failures in distributed systems. More details: https://microservices.io/patterns/reliability/circuit-breaker.html and https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker. Circuit breaker implementations: * https://github.com/resilience4j/resilience4j (Java) * http://www.thepollyproject.org/ (.NET) * https://github.com/rubyist/circuitbreaker (Go) * https://doc.akka.io/docs/akka/current/common/circuitbreaker.html (Scala/Akka) * https://github.com/yammer/circuit-breaker-js (JavaScript) This episode was originally twice as long. If you wish to hear full, director's cut version, check out my mailing list: https://256.nurkiewicz.com/newsletter. I will also notify you about new episodes and add some extra content. Suggest your topics: https://github.com/nurkiewicz/256/issues/new/choose
04:14
May 12, 2020
#0: Meta
I explain software development in no more than 4 minutes and 16 seconds. Notifications of new episodes: https://256.nurkiewicz.com/newsletter User voice: suggest topics: https://github.com/nurkiewicz/256/issues/new/choose Which programming languages count from 1: https://www.quora.com/Which-programming-languages-count-from-1 Background music from freesound.org: https://freesound.org/people/danlucaz/sounds/513957/
03:31
April 27, 2020