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
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.
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 all1 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 weigh2 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!
We do have an espresso machine, but we use it maybe once a month. Also we buy beans that work great for filter coffee and turns out that not all of them are great for espresso.
My standard recipe is 15 grams of coffee to 250 grams of water.
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.
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),
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