Benki โ†’ All Posts

โ‡  previous page next page โ‡ข

Matthew Yglesias on the housing crisis.

I wasnโ€™t aware that zoning rules are as strict as they are. It sounds a bit insane. I wonder what itโ€™s like in Germanyโ€”probably no better if I were to guess.

But I suppose that in addition to a NIMBY vs. YIMBY question it is also an instance of the principle of trying to protect people by taking choices away from them. I wonder how often that works.

A test suite generator for Java. Attempts to automatically generate JUnit test suites that target a given coverage criterion by searching the space of unit tests, encoding in them the current behavior of the code.

Keymaps for keyboards with programmable firmware.

The only one for NEO (my preferred layout) appears to be for the Kyria, but Iโ€™m sure it can serve as good inspiration for other keyboards.

Summary: Only log errors that require intervention, nothing else.

In general thatโ€™s reasonable advice and the article makes some good points, which are:

  • logging is not free; it has a non-negligible performance impact
  • there are better tools for most of the problems that people tend to use logs to solve

I would add:

  • logs are a user interface; it is important to keep them minimal so that they stay usable

But some of the details donโ€™t really make sense.

The article suggests using plain println in order to avoid overhead, but in fact access to stdout/stderr is typically whatโ€™s most expensive about logging, which actual logging frameworks mitigate by offloading it to a worker thread.

The author recommends not to log progress but to use metrics instead. Surely having metrics is a good idea, but in batch processing, logging progress can make sense because it gives more immediate feedback after the rollout of a new version than metrics collection, which tends to be laggy.

There is also the implied assumption that you have a whole host of infrastructure at your fingertips that you can make use of to replace your logging, such as trace collection, metrics collection, and so on. That may be true in a Cloud environment, but in other environments such things may be more expensive to maintain.

Overall I agree with the notion that you should err on the side of logging less rather than more. But if you do have something to log, then (1) do it freely and (2) use a proper logging framework.

My build recipe for a runtime container image based on UBI Micro1 and the latest feature release of OpenJDK.

Small, secure, and tracks OpenJDK upstream. If you like to be on the latest OpenJDK (rather than some vendorโ€™s LTS), this is for you.

I use it for this website and am very happy with it.

Footnotes:

  1. UBI is a trimmed-down version of RHEL that Red Hat distribute free of charge as part of their container image offerings.

A general-purpose physics simulation library with a focus on both speed and accuracy. Suitable for biomechanical, robotic, and other research-related simulations as well as graphics animation (such as in video games).

Has a C API, which makes it easy to bind to from any language.

A Java library for event sourcing. Based on the Cloud Events specification and designed to be a library of utilities rather than a framework.

Matthias # (3)

Comments are now supported

This web site now supports comments.

Comments are simple and anonymous by default. They support a restricted number of HTML tags and their Markdown equivalents:

  • blocks: p, blockquote, pre
  • inline style: em, strong, code, sub, sup, s, ins, del
  • lists: ul, ol, li, dl, dt, dd
  • accessibility hints: abbr, acronym

To comment, click the permalink hash mark (#) at the top of the post in question. Be sure to enable JavaScript in your web browser.

Matthias #

YAML style recommendations

While Iโ€™m not a particularly big fan of YAML overall, it does have some clear benefits over both JSON and XML for human-editable configuration files. And while there are some pretty compelling alternatives, YAML is currently ubiquitous, so it makes sense to make the best of it.

Here are my favorite simple style rules. I apply them aggressively whenever I see some YAML that isnโ€™t bolted to the wall and fixed with superglue.

Rule 1. Indent enumerations.

Rule: Indent enumerated items relative to the key that defines them.

Reason: Adhering to the Rectangle Rule makes it easier to find where blocks begin and end.

Bad:

list1:
- item1
- item2
list2:
- item3
- item4

Good:

list1:
  - item1
  - item2
list2:
  - item3
  - item4

This is by far my favorite rule. Even if you do nothing else, it improves the readability of any YAML file by an order of magnitude.

Rule 2. Separate nested blocks by white space.

Rule: Use empty lines to separate blocks of nested content.

Hint: A good rule of thumb is that any block that has children should be surrounded by white space on both sides.

Reason: Empty lines make it easier to find where blocks begin and end.

Bad:

metadata:
  name: mulkcms2
  namespace: mulk
  labels:
    name: mulkcms2-web
    app: mulkcms2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mulkcms2
      group: mulk
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

Good:

metadata:
  name: mulkcms2
  namespace: mulk

  labels:
    name: mulkcms2-web
    app: mulkcms2

spec:
  replicas: 1

  selector:
    matchLabels:
      app: mulkcms2
      group: mulk

  strategy:
    type: RollingUpdate

    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

This is a rule that I apply not just to YAML, but to any type of code whatsoever. It not just helps with readability, but also with editability (by enabling me to navigate by block).

Official builds of OpenJ9, an alternate implementation of the JVM, from IBM.

While OpenJ9 is not OpenJDK, Semeru does use the OpenJDK class libraries.

โ‡  previous page next page โ‡ข