kmarekspartz

A nonary calendar.

Mon, 17 Feb 2025 02:56:54 +0000

Upon observing that nine cubed is off by one from the number of days in two years, a calendar system emerged.

There are 9 nonths in a biennium, with 9 neeks in a nonth, and 9 days in a neek. There is a biennial holiday between bienniums. Every other biennium holiday is two days.

The first day of the biennium corresponds with March 1st on the Gregorian calendar. The biennial holiday occurs on even number years and is equivalent to February 28th (or February 28th and 29th on Gregorian leap years).

The biennium is expressed in base 9 as well, so the current (at time of writing) biennium would be:

\(\lfloor2025 \div 2\rfloor = 1012 = 1344_9\)

I wrote this on 30₉th (27₁₀)th day of the 5th nonth, on the 3rd neekend.

Handy conversions:

3 neeks (27 days) is approximately a lunisolar month.
1 nonth is approximately a quarter, or a season.

Representing a nonary calendar on a page isn't too different from a 9 by 9 Sudoku grid, which can be used to represent the neeks in a biennium, or the days in a nonth. This also means scheduling exclusive recurring tasks maps to a Sudoku puzzle. For example:

We have 9 tasks to do this nonth. We must do each task once per neek, but never on the same neekday as another neek. We also can't do the task during the same third of the neek as the other neeks in our third of the nonth.

The closest existing calendars to this system that I'm aware of are the Mayan and French Revolutionary calendars, if you want comparisons, though neither were taken to the nines.

Decisions and the long term

Sat, 05 Dec 2015 06:00:00 +0000

Marginal maintenance costs are much more important than fixed initial costs when making business decisions

When making business decisions, people often use initial or fixed costs to justify their decision. While being difficult to estimate, they still are much easier to estimate than maintenance and marginal costs. However, in the long term, maintenance and marginal costs will outweigh initial and fixed costs, so careful attention must be paid to marginal maintenance costs.

Let's consider each combination. While a given cost isn't categorically in one quadrant, these dimensions can be used to conceptualize relative costs of alternatives under consideration.

Fixed initial costs

These are one time costs that are always necessary to take a given path, even in an ideal world.

Marginal initial costs

These are inefficiencies in implementing a decision that are included each time you make similar decisions. Bureaucracy, redundant efforts, and technical debt are three examples.

Fixed maintenance costs

These are the base recurring costs that you must incur as a consequence of your decision. Flat membership or licensing fees are a good example.

Marginal maintenance costs

These are recurring costs that grow proportionally to the number of customers are affected the outcome of your decision. Hiring people or paying for more computers are examples of this. Minimizing these costs has more benefit than reducing the other three types because they are recurring and growing.

Themes as Goals

Wed, 25 Nov 2015 00:00:00 +0000

Use themes to clarify your goals

When defining goals, I've found themes to be more effective than particular achievements. Themes give clarity of purpose and direction, even when the day to day tactical priorities change. Does my plan for the day fit into my theme?

On the other hand, measuring progress against a theme is difficult. Instead of measuring directly, we have to use proxies. Choose proxies carefully. Be comfortable changing your proxy measurements even when you maintain the theme.

Moving to monorepos without losing history

Tue, 17 Nov 2015 00:00:00 +0000

Concurrent implementation of the Daytime Protocol in Rust

Mon, 16 Nov 2015 00:00:00 +0000

A concurrent implementation Daytime protocol in Rust

When learning a language, I rewrite small programs I've previously written to jumpstart my learning. Implementing a concurrent Daytime server has proved particularly useful because it uses both sockets and threads. If a language has good socket and threading libraries, it is likely a good language.

Previously, I demonstrated a Haskell implementation. Here's an example in Rust:

extern crate time;

use std::time::Duration;
use std::io::Write;
use std::net::{TcpListener, TcpStream};
use std::thread;

fn handle_client(mut stream: TcpStream) {
    let date = time::strftime("%F %T\n", &time::now_utc()).unwrap().to_string();
    let _ = stream.write(date.as_bytes());
}

fn main() {
    let listener = TcpListener::bind("127.0.0.1:13").unwrap();

    for stream in listener.incoming() {
        match stream {
            Ok(stream) =>  {
                thread::spawn(move || {
                    // connection succeeded
                    thread::sleep(Duration::new(1,0));
                    handle_client(stream)
                });
            }
            Err(_) => { /* connection failed */ },
        }
    }

    drop(listener);
}

Eventual consistency for SQL: Normalization

Wed, 14 Oct 2015 00:00:00 +0000

Eventual consistency for SQL databases

Tue, 08 Sep 2015 00:00:00 +0000

Using a log-structured schema, we can merge SQL databases to achieve eventual consistency.

Eventual consistency is typically thought of as a property of certain NoSQL databases. However, SQL databases can achieve eventual consistency with adequate planning.

Eventual consistency is particularly useful for horizontally scaling web services, as each node does not need the full, up to date picture. Another use case is synchronizing mobile applications with intermittent network connectivity. In both cases, partitioning or sharding allows each user or client to maintain a consistent view.

A data structure is considered eventually consistent if two instances can reach a consistent state given the same unordered set of state changes. Two databases are eventually consistent if all actions taken in one propagate to the other.

Strong eventual consistency can be achieved if state changes are commutative, associative, and idempotent.

State changes are commutative if swapping two operations yields the same state. For example, these two operations can apply in either order to yield a logically equivalent table:

INSERT INTO some_table (some_column) VALUES (1);
INSERT INTO some_table (some_column) VALUES (2);

Similarly, state changes are associative if three operations can be paired either way yielding the same state. For example, three databases each with one of the following operations can be merged as (1 + 2) + 3 or 1 + (2 + 3) to yield a logically equivalent table:

INSERT INTO some_table (some_column) VALUES (1);
INSERT INTO some_table (some_column) VALUES (2);
INSERT INTO some_table (some_column) VALUES (3);

Not all SQL DML can be commutative or associative:

UPDATE some_table SET a = 1;
UPDATE some_table SET a = 2;
UPDATE some_table SET a = 3;

Depending on the order of these operations, the resulting database would be in different states.

DELETEs also cause problems. Given two databases, where one has ran a deletion and one has not, merging them would re-insert the deleted row in the database with the deletion:

DELETE FROM some_table WHERE some_column = 4;

We can limit DML to SELECTs and INSERTs to avoid using other synchronization methods. Avoiding updates and deletes provides immutability, which guarantees a row will not change or disappear from our databases.

By staying INSERT-only, we treat our database as a persistent data structure, or an append-only commit log.

Immutability and persistence helps with eventual consistency, but they are not sufficient. We also need idempotence. State changes are idempotent if repeatedly applying the same state change yields the same state. Our previous example, INSERT INTO some_table (some_column) VALUES (1) is not idempotent, unless we de-duplicate rows at query time:

SELECT DISTINCT some_column
FROM some_table;

Another way to achieve idempotence is to use a unique constraint to prevent duplicates from being inserted and ignore unique constraint violations upon insertion. We can also manually check for duplicates during an insert:

INSERT INTO some_table (some_column)
SELECT 4
WHERE NOT EXISTS (
  SELECT 1
  FROM some_table
  WHERE some_column = 4
);

How can we delete an item from our database without using SQL DELETE? Tombstones provide our answer. Instead of DELETEing the row, we can create a marker in another table that says an object is deleted.

INSERT INTO some_table_deletions (some_table_id)
VALUES (123456);

Queries for undeleted rows then become:

SELECT some_table.*
FROM some_table
WHERE id NOT IN (
  SELECT some_table_id
  FROM some_table_deletions
);

If we want to support deletion and re-adding of the same value, we cannot use a unique constraint for idempotence since the unique constraint would prevent the addition of the new row. Instead, either de-duplicate at query time using DISTINCT or prevent duplicates from getting inserted without using a unique constraint:

INSERT INTO some_table (some_column)
SELECT 4
WHERE NOT EXISTS (
  SELECT 1
  FROM some_table
  WHERE some_column = 4
  AND id NOT IN (
    SELECT some_table_id
    FROM some_table_deletions
  )
);

At this point it looks like we'll need to normalize our database, or structure our data in a particular way in order to satisfy these properties. In my next blog post, I'll demonstrate how to normalize a database to achieve eventual consistency.

cons, car, and cdr need not be primitive

Mon, 16 Mar 2015 00:00:00 +0000

An exercise from SICP

A lisp can be implemented using a small set of primitives from which other lisp features can be derived. The set is not fixed; different lisps use different primitives. cons, car, and cdr are often primitives, but they do not need to be.

Primitive `cons`, `car`, and `cdr`

Typical implementations of cons, car, and cdr use an underlying array representations in their host environment. In a JavaScript host environment, this could look like:

var cons = function (head, tail) {
  return [head, tail];
};

var car = function (pair) {
  return pair[0];
};

var cdr = function (pair) {
  return pair[1];
};

Derived `cons`, `car`, and `cdr`

To implement cons, car, and cdr as derived features, the lisp should only need function definitions and lambdas as features (either derived or primitive).

(define (cons head tail)
  (lambda (f) (f head tail))

(define (car pair)
  (pair (lambda (head tail) head)))

(define (cdr pair)
  (pair (lambda (head tail) tail)))

This could compile down into:

var cons = function (head, tail) {
  return function (f) {
    return f(head, tail);
  };
};

var car = function (pair) {
  return pair(
    function (head, tail) { return head; }
  );
};

var cdr = function (pair) {
  return pair(
    function (head, tail) { return tail; }
  );
};

See also: SICP Exercise 2.4

Review Checklists

Tue, 20 Jan 2015 00:00:00 +0000

Your Turn

Mon, 19 Jan 2015 00:00:00 +0000

Never give in to impostor syndrome

This week I'll be participating in the Your Turn Challenge. Participants have promised each other to make at least one blog post each day this week. The challenge combats impostor syndrome and gets a routine going.

Impostor Syndrome

Impostor syndrome is the fear of claiming you are something you are not. Most often, I see people struggle with it in programming, but personally I have had it when becoming a business owner and with writing.

“I'm terrible at it.”

I've noticed people with impostor syndrome often have high standards. People get to a point where they can recognize the good from the bad. However, their standards cause them to notice issues in their work that others would gloss over.

These standards are often a reflection of the breadth of their experience. They would not have these standards if they were true impostors.

“What if I fail?”

We hear about others' successes, but usually not about the failures that lead to their eventual successes. Even with failure, we learn. Sometimes the best lessons are learned when we fail. Embrace failure and jump in.

“What if I say the wrong thing?”

With many things in life, you have to claim it before growth can happen. This is the “fake it until you make it” strategy. If you are waiting to be qualified, you'll have missed your opportunity. Qualification comes through experience; your qualifications will catch up.

Habit, routine, ritual

We improve when we iterate and reflect. Each program, business opportunity, and blog post is an opportunity to start again. Get in a habit of reflecting on lessons learned in previous iterations. Build a routine of trying something new. Make starting a ritual.