Ricoh GR III - initial impressions

I’ve got a new camera: Ricoh GR III. I got it when it first became available in early April and since then I’ve shot about 2500 frames with it.

I haven’t explored it enough to offer any kind of conclusive review. Heck, I’ve mostly shot in P mode with JPEG output with default settings! Still, I want to share my initial impressions and some pictures I’ve taken with the camera.

A bit of background: GR III is a fixed lens compact camera with a fast, 28 mm-equivalent lens. It’s a successor to GR II, which has cult following in the street photography circles.

Good. The build quality and the form factor is great. The pictures are very sharp and the colors are nice (but maybe not as nice as Fujifilm’s). It fits well into a pocket. The touch screen is great for choosing a focus point. It can be charged over USB-C. The exposure compensation joystick is quick to use.

Not so good. The battery life is so-so – get an extra battery! I get maybe one day worth of travel photography out of one charge. The P mode skews too much toward wide-open aperture for my taste. Manual focus is cumbersome (but there’s the snap focus mode).

Autofocus is usually fast but it has problems with low-contrast scenes. There’s a firmware update that promises to improve the performance. I’m deferring my judgement until I’ve installed the update.

I’m carrying the camera with Peak Design’s Leash sling strap. To get the anchor cords through the attachment holes in the camera body, you have to place them just right and use enough force and a piece of string (you need to do this only once). Leash is light and easy to adjust and slides well over my clothes, so I’m pretty happy with the setup.

In summary, Ricoh GR III is a great pocketable choice for travel and everyday camera if you’re okay with the battery life – and if the idea of fixed 28 mm-equivalent lens makes sense to you in the first place.

All photos in the post have been shot with Ricoh GR III.

Handbrewing coffee

Shawn Blanc wrote about how he switched to a Moccamaster for brewing his morning coffee. It’s a nice post about productivity, but it made me want to talk about coffee.

We hand-brew all¹ the coffee we drink at the office with a drip cone. We have been doing this for a couple of years already. I like it, but out of courtesy towards my colleagues I’ve floated the idea of buying an electric coffee maker a couple of times. So far they have preferred to continue with hand-brewing. But why bother?

It’s not because of the taste. I don’t think that I could tell apart my hand-brew and well-made batch brew in a blind test.

I like the ritual, and the exercise in patience. First you weigh² and grind the beans while waiting for the way-too-slow kettle to boil the water. Then you pour and wait and pour and wait. Then you wash the cone and finally you get to taste the coffee.

The drip cone maintenance is easy, too. Washing the cone after each use takes only a couple of seconds. The fundamentals of good coffee are freshly-ground beans and clean equipment. Taking care of the latter couldn’t be easier. And hand-brewing makes it easier to not drink too much coffee, because the coffee is not there just waiting for you to overdose.

On the other hand, using an electric coffee maker would free me from pouring the water. I brew coffee maybe once per day, so that would same me about 3.5 minutes a day. There are about 200 working days in a year, so that amounts to almost 12 hours. It takes something like six hours to read a medium-size novel. In a year I could read two more books during my breaks instead of staring at coffee. The choices!

Revisiting Clojure testing

Two years ago I wrote about the Clojure test runner of my dreams. Back then, I asked for a Clojure test runner that would support clojure.test and that would have the following features:

• Output catching to make noisy test suites quiet.
• Test tagging for selectively running tests.
• JUnit output for integration with CI tools such as Circle.
• Test slowness reporting to speed up slow test suites.

Let’s see where we are now.

After my post, Eftest soon got all the features. It’s a great library and while the included Leiningen plugin is quite rudimentary, bat-test offers a feature-rich wrapper for use with Leiningen and Boot.

When Arne Brasseur announced that he is developing Kaocha, I didn’t see much point in a new test runner. However, I was working a new project that used tools.deps as the dependency management tool. Since bat-test does not have a clj -m -compatible version, I decided to give Kaocha a go.

After using Kaocha for a couple of months, I have to admit that Arne has created a something worthwhile. Kaocha offers test running with all the above-mentioned features and more (e.g. watcher, Cloverage integration) in one coherent, well-documented package. Furthermore, Kaocha’s design allows easy extensions. For example, it was super-easy to create a plugin that toggles on Orchestra instrumentation.

If you’re looking for a new test runner, definitely check out Kaocha.

Side-note: Arne’s work on Kaocha has been funded by Clojurists Together. Their funding has paid for a number of improvements in Clojure projects you’re most likely using. The money comes from individual and corporate sponsors. It seems like a great way for Clojure-using companies to fund work on the tools that their developers use. I’m happy that Metosin has been a sponsor since the beginning and I’m hoping to see more companies on the member list.

What’s next?

Test runners are good now. Does this mean that the Clojure testing landscape is perfect now? Well… I see at least two areas of improvement.

ClojureScript unit testing. Doo (which I co-maintain) is tricky to set up, I’ve had a number of problems with boot-cljs-test, and using Karma directly is a lot of work. Getting my list of dream features to work is possible but tedious.

Luckily there are two new developments: Figwheel Main has built-in unit testing support and Kaocha has kaocha-cljs. Both look promising. This is what I’m most excited about Kaocha – I’m hoping that Kaocha manages to bring the same turn-key experience to ClojureScript that it already has for Clojure.

Assertion libraries. In clojure.test the assertion are written with the is macro, which isn’t very expressive. The main selling point of Midje was its powerful syntax for writing assertions. Unfortunately that power came with the cost of a complex implementation.

Apart from writing your own predicates, what are the current options? I’m aware of testit (my go-to choice), iota, and matcher-combinators. Each of them is significant improvement over is macro, but I don’t love any of them. I guess I need to come up with a list of features for the assertion library of my dreams!