- From Imperative to Functional Programming using Arrow
-
Some time ago, I watched the talk FP to the max. While the end of the talk is quite Scala-ish, the beginning can be of interest regardless of the language.
In the talk, the speaker tries to migrate a standard imperative-like application using a functional approach. I wanted to check if it was possible to do the same in Kotlin.
- CSS has 42 units
-
Out of the original nine, I used perhaps 4 or 5, and now, there are 42???
- Banning controversy reveals Bluesky’s decentralized aspiration isn’t reality
-
Bluesky’s protocol is so complicated that not even the biggest alternative network has figured out how to become independent
For a fully decentralized social media, there’s Mastodon. I wonder why so many people forget it.
- Python 3.14.0
-
- PEP 779: Free-threaded Python is officially supported
- PEP 649: The evaluation of annotations is now deferred, improving the semantics of using annotations.
- PEP 750: Template string literals (t-strings) for custom string processing, using the familiar syntax of f-strings.
- PEP 734: Multiple interpreters in the stdlib.
- PEP 784: A new module compression.zstd providing support for the Zstandard compression algorithm.
- PEP 758: except and except* expressions may now omit the brackets.
- Syntax highlighting in PyREPL, and support for color in unittest, argparse, json and calendar CLIs.
- PEP 768: A zero-overhead external debugger interface for CPython.
- UUID versions 6-8 are now supported by the uuid module, and generation of versions 3-5 are up to 40% faster.
- PEP 765: Disallow return/break/continue that exit a finally block.
- PEP 741: An improved C API for configuring Python.
- A new type of interpreter. For certain newer compilers, this interpreter provides significantly better performance. Opt-in for now, requires building from source.
- Improved error messages.
- Builtin implementation of HMAC with formally verified code from the HACL* project.
- A new command-line interface to inspect running Python processes using asynchronous tasks.
- The pdb module now supports remote attaching to a running Python process.
- State of the software engineering jobs market, 2025: what hiring managers see
-
I experienced recently the state of the job market by myself. It’s not great, but perhaps I’m not connected to the right people?
- Demystifying Automatic Instrumentation: How the Magic Actually Works
-
The article describes the many approaches to zero-code instrumentation, depending on the underlying tech stack.
- Monkey Patching: Runtime Function Replacement with Node.js
- Bytecode Instrumentation: Modifying the Virtual Machine with Java
- Compile-Time Instrumentation: Baking Observability into the Binary with Go
- eBPF Instrumentation: Kernel-Level Observability
- Language Runtime APIs: Native Instrumentation Support with PHP
- Gleam
-
Running on the battle-tested Erlang virtual machine that powers planet-scale systems such as WhatsApp and Ericsson, Gleam is ready for workloads of any size.
I’ve gone through the tour. Gleam’s syntax looks very similar’s to Rust, but for the lack of loops, as in Elixir, and it runs on the BEAM. Chances are high that I start learning it next.
- The New Java Best Practices
-
- Creating C4 model diagrams as code
-
I agree that Structurizr (or PlantUML) are far superior to any Visio diagram, but only because of their "as-code" approach.
The post makes bold claims and doesn’t hold on its promises:
That’s when I realized a common truth: most architecture documentation doesn’t age well. We draw diagrams once, and they start drifting out of sync with the system almost immediately.
I wanted a way to keep architecture diagrams in step with the codebase -versioned, reviewable, and continuously updated.
The above is mostly correct. However, it’s not because you store your diagrams with the code that they are continuously updated. If you worked with Javadocs before, you may have come upon completely out-of-sync Javadoc, even though it’s as close to the code as possible.
Mark my words: the only way to keep diagrams in sync with the code is to generate them automatically from it. However, you lose the power of diagrams in this case, which is to focus on things the author deems important by abstracting away things they don’t.
- Leverage Points: Places to Intervene in a System
-
I learned about this post at DevOps Days Kansas City (part of KCDC) in August. It’s amazingly interesting, but quite long. It took me a couple of times to read it entirely.
(in increasing order of effectiveness)
- Constants, parameters, numbers (subsidies, taxes, standards).
- Regulating negative feedback loops.
- Driving positive feedback loops.
- Material flows and nodes of material intersection.
- Information flows.
- The rules of the system (incentives, punishments, constraints).
- The distribution of power over the rules of the system.
- The goals of the system.
- The mindset or paradigm out of which the system — its goals, power structure, rules, its culture — arises.
- Anthropic’s Prompt Engineering Interactive Tutorial
-
This course is intended to provide you with a comprehensive step-by-step understanding of how to engineer optimal prompts within Claude.
After completing this course, you will be able to:
- Master the basic structure of a good prompt
- Recognize common failure modes and learn the '80/20' techniques to address them
- Understand Claude’s strengths and weaknesses
- Build strong prompts from scratch for common use cases