DEV Community: Cameron Desautels

Chinese Zodiac Time for Emacs

Cameron Desautels — Tue, 13 Feb 2024 03:22:33 +0000

In the spirit of Chinese New Year, I hacked up a small extension for Emacs to render the current time of day using emoji and Chinese characters:

Various configurations for your mode line.

It’s just a silly project that I’ll consider a success if it puts a smile on someone’s face, but it is loosely based on a system used to measure time in the Ming dynasty which divided the day into 12 equal periods (時¹), named after the 12 earthly branches (地支).

Because the animals of the Chinese zodiac map 1-to-1 with the earthly branches, it is equally possible to indicate the time with the zodiac animals!

Chart of correspondence between the earthly branches, zodiac animals, and times of day from Wikipedia. Apologies on this being in Spanish.

Given that a modern user probably wants to know which of our 24 hours they’re in, rather than which two hour period (時), I decided to differentiate the two halves as either 小 (small) or 大 (large).

Hence, in the image above showing the time as 「大🐲 四十二分」, the current time is 8:42am, by our modern reckoning (7:42am would be the little dragon!).

I won’t go into a ton of detail here because I explain it in some detail on the project’s GitHub page.

The most amusing part of the project was, perhaps, deciding exactly which emoji to use! In the end, I implemented two sets of emoji you can choose from:

Set	Emoji
`'cute`	🐭🐮🐯🐰🐲🐍🐴🐏🐵🐔🐶🐷
`'emoji`	🐀🐄🐅🐇🐉🐍🐎🐑🐒🐓🐕🐖

Rather disappointing that we don’t quite have a complete set of animal faces. At least not in Apple’s emoji.

If you’re wondering why I chose the COW (🐄) emoji in the second set rather than the OX (🐂), it’s because it looked too similar to the neighboring TIGER (🐅), making it easy to confuse the time.

If you don’t like my choices, the library also makes it extremely easy to bring your own set of emoji, so you can make your own decisions between:

RAT (🐀), MOUSE (🐁), and MOUSE FACE (🐭)
SHEEP (🐑), GOAT (🐐), and RAM (🐏)
HORSE (🐎) and HORSE FACE (🐴)
CHICKEN (🐔) and ROOSTER (🐓)
Or maybe even pretend FROG (🐸) is a snake face
Or spice up your horse with UNICORN (🦄)

Clearly the sky’s the limit.

For Chinese learners or traditionalists, it can also display the time with:

Traditional characters: 「大龍四十二分」²
Simplified characters: 「大龙四十二分」
Or earthly branches: 「辰正四十二分」

(n.b. the earthly branches are displayed using the proper, traditional system of 初 and 正 suffixes, not my invented prefixes for animals.)

It’s a lot of fun telling time with cute animals, and might even help you learn a few things if you’re a beginner in Chinese, so check it out on GitHub!

龍年快樂！恭喜發財！ 🐉🧧

Students of the Chinese language may find it interesting to know that these two hour periods are the reason we call (single) hours 小時 in modern Chinese (I know I did!). ↩︎
It’s not 100% clear to me if these characters will render the same regardless of locale, so I apologize if they do not appear as I have described—I’m still trying to get my head around CJK unification in Unicode. ↩︎

Java Allergies and Revisiting java.time

Cameron Desautels — Fri, 09 Feb 2024 18:08:27 +0000

Wherein I argue that Clojurians should be a touch more embracing of Java interop and that java.time is actually good.

Introduction
Fun Times with java.time
But I’m Allergic to Java
To Library Or Not To Library?
Postscript

Introduction

I enjoyed Josh Glover’s post today in which he described how he queried his quickblog data with a dash of Babash…ka (sorry, couldn’t resist) to determine the number of posts he made during a certain date range—“in 50 simple steps”.

I appreciate this narrative, almost lab notebook, style of writing. It’s helpful to see how others work through problems, what tools they use to explore, and what alternatives they consider. It’s also humanizing, reminding us that elegant works we encounter likely didn’t emerge spontaneously, Athena-like, from the heads of their creators, but took time¹ and, perhaps, toil. Ex nihilo nihil fit—the mill demands its grist.

It takes extra work to write as he did, tracking your own twists and turns, so, thank you to Josh for the post. (He has a good sense of humor and makes cool stuff, so check out his blog!)

I enjoyed seeing how simple the quickblog data model was along the way (universal Clojure plot spoiler: it was maps).

Fun Times with `java.time`

I’d like to borrow a few of Josh’s steps² as a jumping off point to address date / time handling in Clojure³:

Realise that :posts is a map of filename to post, but no matter!

Sigh as you come to terms with the fact that you’re going to need to do some date parsing and you never remember how to use java.time and argh!

Smile as you remember about tick, which is a library from our good friends at JUXT that provides a nicer API for this sort of stuff

I’ve had several discussions with peers who felt the exact same way about java.time. Hell, I felt that way for while.

But while I certainly agree that the JUXT folks are great friends to the community (💙), and that they’ve created something nice with tick, I’d also argue that java.time is pretty good , and it deserves another look if you wrote it off early on.

I can’t vouch for everything in java.time—I don’t know_everything in java.time—but it was written (comparatively) recently, after the lessons of java.util.Date (bad) andJoda-Time (much better) had been absorbed, and _they basically got it right.

I suspect most of us have dealt with a date parsing scenario like Josh encountered and found ourselves thinking: “just turn this damn string into a date—how hard could it be?” Maybe we even came from a language where a single function could parse "2022-08-26" and"2022-08-26T10:30" and "2022-08-26T10:30:00.000-05:00", and it all seemed so easy. And now we have this fussy, baroque java.time thing to contend with.

But the thing about those easy interfaces? They’re all bad, broken, or incorrect⁴. And, if you haven’t already, you will eventually get burned by them.

It’s actually trivial to demonstrate: what does "2022-08-26"represent? Is it August 26th, 2022 in your computer’s time zone? In GMT? Is it that date regardless of your timezone (meaning it’s not a single, unified point in time⁵)? These are all foundational concepts in our world; we need all of these concepts to have programs that do practical things, and since the semantics are not differentiated in the content of the string, they cannot possibly be handled correctly by a single (undifferentiated) parser.

Human representation of time is inherently complex (read Falsehoods programmers believe about time if you need convincing), so you really only have two options:

The broken way — “Being small and ~~simple~~ [easy] is more important than being correct.” (perjoratively, “the Unix way”, à laThe Unix Haters Handbook, pg. xx)
The fussy way — “The design must be correct in all observable aspects. Incorrectness is simply not allowed.” (generously, “the Lisp way”, à la rpg).

A correct implementation, by necessity, reflects the inherent complexity of the problem domain⁶. And I think java.timeactually does a good job of that. The core classes injava.time neatly represent the underlying concepts in the domain (and are immutable!)—it’s just that the domain is big, so there’s a lot for us to get our heads around.

But once we do:

A date, irrespective of time or timezone is just: (LocalDate/parse "2022-08-26")
If that includes a time, it’s: (LocalDateTime/parse "2022-08-26T10:30")
And a single point in time is: (Instant/parse "2022-08-26T10:30:00.000-05:00")

There’s really no fluff or inconsistency here—we just need to remember the class names. It wouldn’t be any easier if these were three function names instead.

But I’m Allergic to Java

Many Clojurians seem grumpy about seeing Java stuff in their Clojure code. I get it. I, too, came from the pure Lisp lands of kebabs and unified case (though preferably not *THE-SHOUTY-KIND*). And didn’t we do all of this to get away from that Java stuff?

Calling everything via functions looks nice, and has its benefits for porting (e.g. CLJS), and, hey, wouldn’t it be dreamy if one day we had a non-hosted, portable language with a spec and maybe it even bootstrapped itself, and compiled natively and… [trails off]

But in the meantime…

JVM interop is a freaking superpower. The presence of “Java stuff” in our language means we get to tap into thousands of person-years of engineering effort that our small community couldn’t have come up with on its own. It’s not a bug—it’s a feature! (But really this time.)
You’ll need to learn some Java stuff if you want to get good at Clojure. You need to be able to read stacktraces effectively, use records and protocols, and wield core Java libraries.
We shouldn’t shun interop in the same way that non-Lispers shouldn’t shun s-expressions. Think what that bias has cost them. If minor syntax details are your biggest concern, you need to work on harder problems!
Clojure 1.12 is around the corner and you’re going to be able to do this: (map LocalDate/parse ["2022-08-26" ,,,]) Instead of this: (map (fn [v] (LocalDate/parse v)) ["2022-08-26" ,,,]) Rejoice!

To Library Or Not To Library?

So we want to filter a sequence of maps based on their :datevalues—should we pull in a library? (You know what I’m going to say if you read all of the above, so I won’t belabor it…)

JUXT actually provides a nice guide to when you might want to use tick that makes thoughtful points you should read.

But for the basic cases, my fellow Clojurians, I really encourage you to just learn java.time. Because of the inherent complexity of time, it’s basically this set of classes or that set of functions—and the former is standard, built-in, battle-tested, and known.

Give it another chance.

It may not look like much, but it’s got it where it counts.

Postscript

Bonus tip : for super basic cases, you can just useread-instant-date (which pairs great with #inst’s convenient capabilities!):

(.before (clojure.instant/read-instant-date "2022-08-26") #inst "2022-09-01")
;; =>
true

It’s naive, without a proper understanding of timezones and such, but it handles the basics fine.

Thank you for reading, and thanks again to Josh for the great post.

Hopefully of the hammock variety. ↩︎
Slightly reformatted because computers. ↩︎
It is my sincere hope that the author won’t mind my use of his post as a foundation to discuss this topic with the community; it’s certainly not intended as a critique of his post and / or code. ↩︎
Just to be clear (and fair), I’m not including tick in my “bad” list—it’s actually a thin, sane layer over java.time (on the JVM). ↩︎
If you want to have a bad time (ugh, sorry), try explaining to a_user_ that a date basically isn’t a thing and that their globally-distributed team possibly should see two different dates on the same invoice depending on their location. ↩︎
So many pigeons, so few holes. ↩︎

Launching Dev Dependencies with tmux

Cameron Desautels — Sun, 29 Mar 2020 16:35:06 +0000

When working on CollBox, we have a handful of external services the app depends on which we need to have running at development time. I used to run these via Foreman, but somewhere along the way my Ruby installation seems to have gotten borked (thanks, Catalina?) and since then I've been running the services by hand. I always work in a tmux session anyway, so I decided it was time to see what it would look like to launch my window full of dependencies in tmux from a script.

As it turns out, tmux is fantastically scriptable. If you simply run tmux <command> from a shell inside of a tmux session, that command will be run by the encapsulating tmux instance, and these are the same set of commands that can be bound to your tmux keyboard shortcuts. You can also simply send a stream of keystrokes to panes inside of tmux. All of this means running my four dependencies in a single window (named "deps") under their own panes is as simple as:

#!/bin/sh
# deps.sh

tmux new-window -n "deps"

tmux send-keys "redis-server redis.conf" Enter
tmux split-window
tmux send-keys "datomic/bin/transactor transactor.properties" Enter
tmux split-window
tmux send-keys "lein shadow-watch" Enter
tmux split-window
tmux send-keys "npx gulp" Enter

tmux select-layout tiled

When I'm ready to work on the project I simply run ./deps.sh at my shell and I end up with something like this:

+---------------------------------+---------------------------------+
| $ redis-server redis.conf       | $ datomic/bin/transactor transa |
| ...                             | ...                             |
|                                 |                                 |
|                                 |                                 |
|                                 |                                 |
|                                 |                                 |
|                                 |                                 |
|---------------------------------+---------------------------------|
| $ lein shadow-watch             | $ npx gulp                      |
| ...                             | ...                             |
|                                 |                                 |
|                                 |                                 |
|                                 |                                 |
|                                 |                                 |
|                                 |                                 |
+---------------------------------+---------------------------------+
| 1:deps* | 2:zsh |                                                 |
+-------------------------------------------------------------------+

fin.

A few thoughts on other tools that can be used to address this same problem:

Foreman: Great project; I've used it happy for years. I love the aggregated, colorized logs, which keep things compact yet comprehensible. The one downside is that it's not convenient to restart a single service, should you need to. But my main reason for switching was just to see if I could avoid the additional dependencies to my development stack given that I already use tmux.
tmuxinator: Looks like a nice project to encapsulate essentially what I did above into a simple data-driven format, but I don't see that the gains are big enough (at least for my simple case) to bother adding the additional dependencies.
Docker: As much as I like the idea of cleanly locking down development dependencies in the Docker style, in practice I've found it exceptionally costly, both in terms of the performance overhead (I literally had to buy a new laptop at my last job once we switched to Docker), and the increased complexity of accessing application state / debugging.