a tumblelog
week 39, 2020

In defense of XML

When I started my career, XML was ubiquitous. The meta-information in a Java JAR file - the manifest - follows a proprietary format. But Java EE designers built it from the ground up on XML: meta-information of all artifacts is in XML format e.g. web.xml, ejb-jar.xml, application.xml, etc.

Java EE is one example I experienced personally. But XML was everywhere in the enterprise world at the time. Its prevalence manifested itself in two areas: configuration and data transfer.

Ever since then, it would be an euphemism to say XML has been losing in popularity. Other formats, such as JSON and YAML, have replaced it in the hearts of developers. In this post, I’d like to:

  • Explore some of the reasons why the mighty XML has fallen
  • Raise some downsides of the popular alternatives
  • And describe how XML already solved those problems

Source: In defense of XML, an article by Nicolas Fränkel.

Crafting Functions

We write so many functions in our programs that they become second nature before we know it. Like ants in a colony, they are numerous beyond imagination and they come together to form some surprisingly complex systems.

It begs the question: how do we write good functions? It can seem trivial: they’re just like ants after-all. But there is leverage in the answer: the right decisions multiply throughout your codebase and bubble up into great design.

I think there are about three key ideas you can employ to craft good functions. I wanted to share them with you.

Source: Crafting Functions, an article by Stepan Parunashvili.

Learn Haskell Fast and Hard

A very short and dense tutorial for learning Haskell.

Source: Learn Haskell Fast and Hard an article by Yann Esposito.

9 Python 3 Features You Might Not Use Yet

Here are a few illustrations of uncommon traits that can only be found in Python 3, with the intention of fixing your Python issues quickly.

Source: 9 Python 3 Hacks Programmers Probably Don’t Utilize, an article by Vivek Coder.

An Introduction to LVM Concepts, Terminology, and Operations

LVM, or Logical Volume Management, is a storage device management technology that gives users the power to pool and abstract the physical layout of component storage devices for easier and flexible administration. Utilizing the device mapper Linux kernel framework, the current iteration, LVM2, can be used to gather existing storage devices into groups and allocate logical units from the combined space as needed.

The main advantages of LVM are increased abstraction, flexibility, and control. Logical volumes can have meaningful names like “databases” or “root-backup”. Volumes can be resized dynamically as space requirements change and migrated between physical devices within the pool on a running system or exported easily. LVM also offers advanced features like snapshotting, striping, and mirroring.

In this guide, we will briefly discuss how LVM works and then demonstrate the basic commands needed to get up and running quickly.

Source: An Introduction to LVM Concepts, Terminology, and Operations, an article by Justin Ellingwood.

Rootless containers with Podman: The basics

As a developer, you have probably heard a lot about containers. A container is a unit of software that provides a packaging mechanism that abstracts the code and all of its dependencies to make application builds fast and reliable. An easy way to experiment with containers is with the Pod Manager tool (Podman), which is a daemonless, open source, Linux-native tool that provides a command-line interface (CLI) similar to the docker container engine.

Source: Rootless containers with Podman: The basics, an article by Prakhar Sethi.

Swift System is Now Open Source

In June, Apple introduced Swift System, a new library for Apple platforms that provides idiomatic interfaces to system calls and low-level currency types. Today, I’m excited to announce that we’re open-sourcing System and adding Linux support! Our vision is for System to eventually act as the single home for low-level system interfaces for all supported Swift platforms.

Source: Swift System is Now Open Source, an article by Michael Ilseman.

New in calibre 5.0

Welcome back, calibre users. It has been a year since calibre 4.0. The two headline features are Highlighting support in the calibre E-book viewer and that calibre has now moved to Python 3.

There has been a lot of work on the calibre E-book viewer. It now supports Highlighting. The highlights can be colors, underlines, strikethrough, etc. and have added notes. All highlights can be both stored in EPUB files for easy sharing and centrally in the calibre library for easy browsing. Additionally, the E-book viewer now supports both vertical and right-to-left text.

Source: New in calibre 5.0, an article by Kovid Goyal.

I use Calibre to convert EPUB files to MOBI so I can read them on my Kindle Paperwhite. Highly recommended.

Pixies - Hear Me Out

Early in the evening I watched the Pixies' official video of "Hear me Out". I am not so sure about the song, but I do like the video a lot. Let's hope a new album is in the making!

How the CPython compiler works

In the first post of the series we've looked at the CPython VM. We've learned that it works by executing a series of instructions called bytecode. We've also seen that Python bytecode is not sufficient to fully describe what a piece of code does. That's why there exists a notion of a code object. To execute a code block such as a module or a function means to execute a corresponding code object. A code object contains block's bytecode, constants and names of variables used in the block and block's various properties.

Typically, a Python programmer doesn't write bytecode and doesn't create the code objects but writes a normal Python code. So CPython must be able to create a code object from a source code. This job is done by the CPython compiler. In this part we'll explore how it works.

Source: Python behind the scenes #2: how the CPython compiler works, an article by Victor Skvortsov.

Higher Order Functions in Python

Also known as first-class functions, functions can take other functions as parameters and also return other functions.

Since everything in Python is an object, we can treat functions as such.

Source: Higher Order Functions in Python, an article by Renan Moura.

Image Super-Resolution: A Comprehensive Review

Image Super Resolution refers to the task of enhancing the resolution of an image from low-resolution (LR) to high (HR). It is popularly used in the following applications:

  1. Surveillance: to detect, identify, and perform facial recognition on low-resolution images obtained from security cameras.
  2. Medical: capturing high-resolution MRI images can be tricky when it comes to scan time, spatial coverage, and signal-to-noise ratio (SNR). Super resolution helps resolve this by generating high-resolution MRI from otherwise low-resolution MRI images.
  3. Media: super resolution can be used to reduce server costs, as media can be sent at a lower resolution and upscaled on the fly.

Deep learning techniques have been fairly successful in solving the problem of image and video super-resolution. In this article we will discuss the theory involved, various techniques used, loss functions, metrics, and relevant datasets. You can also run the code for one of the models we'll cover, ESPCN, for free on the ML Showcase.

Source: A Review of Image Super-Resolution, an article by Anil Chandra Naidu Matcha.

Haskell's Children

If I were to travel back in time 4 years ago, and tell my old self that Haskell was starting to lose its shine, I wouldn’t believe it. I grew up on Haskell, my appetite for category theory was whetted by Haskell, my biggest programming projects have been in Haskell, and my dream job was to work at a company that used Haskell.

But now, I find myself simply not as excited about Haskell as I used to be. What changed?

Source: Haskell's Children, an article by Owen Lynch.

Visualizing gzip compression with Python!

Not that long ago, I found myself wanting to understand gzip. I didn’t necessarily want to learn to implement the algorithm, but rather I just wanted to understand how it was performing on a particular file. Even more specifically, I wanted to understand which parts of a file compressed well, and which ones did not.

There may be readily available tools for visualizing this, but I didn’t find anything. Since I know gzip is implemented in the Python standard libraries, and I’m familiar with Python plotting libraries, I thought I would try to make my own visualization. This blog post (which is in fact just a Jupyter notebook) is the result.

Source: Visualizing gzip compression with Python!, an article by Stephen Brennan.

Former Intel Engineer Explains Why Apple Switched to ARM

François Piednoël spent 20 years working at Intel as both a Principal Engineer and Performance Architect. Now, he’s decided to answer the question everyone is asking: Why did Apple decide to switch from Intel to ARM processors for the Mac?

Source: Former Intel Engineer Explains Why Apple Switched to ARM, an article by Matthew Humphries.

The Organization

Today I got an email from Jos Yule, thanking me for tumblelog:

Just a quick note to say "Thanks!" for tumblelog. Single script, good install docs, simple template -- love it.

Feel free to check out my 1 day old blog --

I checked out the blog and it looks very good; I like the syntax highlighting of code blocks using Prism.

Thanks Jos for letting me know. Keep on blogging!

The case for comments in code

When I first started programming, especially when asked for code samples, my comments lacked purpose and would often duplicate in English what the code clearly indicated. I knew that "commenting is good" but as a beginner I had no further insight.

Over time with the help of books like Clean Code, I grew disdainful of comments. Good code should be self-documenting. Whenever I needed to write a comment to explain something, I'd realize I could easily rename some key variable or function. I grew more comfortable with variables and functions with a few words in the title. Better to spend time on good code structure and naming.

Source: The case for comments in code, an article by Phil Eaton.

Improving Python exception chaining with raise-from

Back in the yee-haw days of 2003, Raymond Hettinger wrote an email to the python-dev mailing list, sharing an idea for improving the way that Python handles exceptions that are caught and replaced with other exceptions. The goal was to avoid losing information about the first exception while reporting the second one. Showing the full information to the user would make debugging easier, and if you’ve followed my work before, you know there’s nothing I love better than that.

Source: Improving Python exception chaining with raise-from, an article by Ram Rachum.

Lessons Learned from Running Postgres 13

Postgres 13 is almost here. It's been in beta since May, and the general availability release is coming any day. We've been following Postgres 13 closely here at pganalyze, and have been running the beta in one of our staging environments for several months now.

There are no big new features in Postgres 13, but there are a lot of small but important incremental improvements. Let's take a look.

Source: Lessons Learned from Running Postgres 13: Better Performance, Monitoring & More, an article by Maciek Sakrejda.

Revisiting Apple Notes (6): The Protobuf

This post explains portions of two protobufs used by Apple, one for the Note format itself and another for embedded objects. More importantly, it explains how you can figure out the structure of protobufs.

Source: Revisiting Apple Notes (6): The Protobuf.

When should you stop refactoring Legacy Code?

When you work with Legacy Code, things can quickly get out-of-hand.

Sometimes you dive into the code with a clear goal in mind… 3 hours later you’re still trying to break a problematic dependency and have completely lost track of why you were here in the first place!

Source: When should you stop refactoring Legacy Code?, an article by Nicolas Carlo.