50 episodes

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 seconds is 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.

By Tomasz Nurkiewicz. Java Champion, CTO, trainer, O'Reilly author, blogger

Around IT in 256 seconds Tomasz Nurkiewicz

    • Technology
    • 5.0 • 11 Ratings

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 seconds is 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.

By Tomasz Nurkiewicz. Java Champion, CTO, trainer, O'Reilly author, blogger

    #49: Functional programming: academic research or new hope for the industry?

    #49: Functional programming: academic research or new hope for the industry?

    Functional programming means programming using functions. See, I need much less than 256 seconds for that! Unfortunately, this definition is as useful as saying that object-oriented programming means programming with objects. So let’s dive deeper. First of all, I mean pure functions as defined by mathematicians. In math, a function always returns the same output for a given input. A length of a string is a function. A form validator is typically a function as well. For the same form inputs it always returns the same result: valid or invalid. On the other hand, returning the current date for a given location is not a function. Or reading a file.

    Read more: https://nurkiewicz.com/49

    Get the new episode straight to your mailbox: https://nurkiewicz.com/newsletter

    • 4 min
    #48: Distributed tracing: find bottlenecks in complex systems

    #48: Distributed tracing: find bottlenecks in complex systems

    Life used to be simple. In a traditional monolithic application, when a failure occurred, you could easily find the
    problem. When an exception bubbles up, it appears throughout all stack frames. You can easily examine which methods
    or functions were invoked from each other. You can see application layers involved. Moreover, it’s fairly easy
    to profile performance bottlenecks. Answering these questions becomes much harder when there are multiple systems
    involved.

    Read more: https://nurkiewicz.com/48

    Get the new episode straight to your mailbox: https://nurkiewicz.com/newsletter

    • 4 min
    #47: Terraform: managing infrastructure as code

    #47: Terraform: managing infrastructure as code

    Terraform is fairly low-level software for managing your infrastructure. For instance, it’s used to create and provision cloud instances, networks and software. Unlike traditional tools in this area, Terraform is declarative. It means you don’t define step-by-step, imperative guides. Essentially, scripting your infrastructure with Bash or Python. Instead, you define desired, final infrastructure state. For example, how many hosts, how they should be connected, what kind of software and packages they should contain. Once you apply this configuration, Terraform takes all the necessary steps to fulfill your needs. Here’s how it works in more detail.

    Read more: https://256.nurkiewicz.com/47

    Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter

    • 4 min
    #46: Kubernetes: Orchestrating large-scale deployments

    #46: Kubernetes: Orchestrating large-scale deployments

    Kubernetes is a platform for managing various workloads inside containers. Before I jump into a definition, let’s describe the problems it tries to solve. Imagine your application consists of several components. It can be microservices, multi-layer application, etc. Each type of component needs to be deployed on multiple servers. First of all, to support fault tolerance, but also to achieve horizontal scaling. Doing this by hand is quite problematic. Manually tracking which servers should host which components is tedious and error-prone. You need to take into account: * CPU and memory requirements of each component * discoverability (where each component is located) * provisioning (different components need different libraries and packages) * scaling out and migrating from broken servers * and so on, and so forth

    Read more: https://256.nurkiewicz.com/46

    Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter

    • 4 min
    #45: Node.js: running JavaScript on the server (!)

    #45: Node.js: running JavaScript on the server (!)

    Node.js: running JavaScript on the server (!)", "episode_description": "JavaScript language is primarily used inside
    your web browser. Your computer downloads a JavaScript file and executes it on your machine. But if you want to
    build a dynamic website, you need a server-side language. Like PHP, Java, Python, etc. Programs written in these
    languages handle incoming requests and produce dynamic HTML. HTML that varies, depending on the request, who is
    asking and what data is available in the underlying database. But for more than a decade we can also use JavaScript
    on the server. The same language can be used for a very different purpose. Namely, listening and handling web
    requests. But also implementing command-line utilities and one-off scripts. This became possible after extracting
    the JavaScript engine from Chrome browser.


    Read more: https://256.nurkiewicz.com/45


    Get the new
    episode straight to your mailbox: https://256.nurkiewicz.com/newsletter

    • 4 min
    #44: RESTful APIs: much more than JSON over HTTP

    #44: RESTful APIs: much more than JSON over HTTP

    REST is an architectural style of communication, based on HTTP. It was proposed in the year 2000 by Roy Fielding. In his dissertation he describes the way systems should communicate, embracing fundamental features of HTTP. He puts emphasis on: statelessness, support for caching, uniform representation and self-discoverability. APIs that adhere to these priniciples are called RESTful. This academic paper is quite abstract so I’ll focus on what it means in the enterprise. Also, it’s much easier to understand what RESTful API is when contrasted to SOAP. And GraphQL released recently.

    Read more: https://256.nurkiewicz.com/44

    Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter

    • 4 min

Customer Reviews

5.0 out of 5
11 Ratings

11 Ratings

Top Podcasts In Technology

Listeners Also Subscribed To