See Spot Code

There’s quite a bit of exten­si­bility in clojure.test. A variety of test runners and report format­ters, such as James Reeves’ Eftest, Metosin’s boot-alt-test, and Paul Stadig’s Humane Test Output hook into the clojure.test reporting framework.

There’s also assert-expr, which allows you to extend the is macro to encap­su­late domain-spe­cific test­ing, as well as add domain-spe­cific report­ing. Many of clojure.test’s own asser­tions, such as instance? and thrown?, are imple­mented as assert-expr meth­ods. Daniel Solano Gómez has written a library with helpers for Clojure spec called tacular which includes a number of custom asser­tions. The test.check library uses a custom asser­tion to improve reporting in its defspec testing macro.

Writing these custom asser­tions in a portable way can be a bit of a trick, so let’s work through an exam­ple: an asser­tion that tests the data returned from a thrown instance of ExceptionInfo.

I’m working on an Om Next app with a Pedestal back­end. Figwheel is a great way to do Clojure­Script devel­op­ment, and the Reloaded workflow is really nice for working on Clojure servers. However, reloading Clojure code in the JVM still has corner cases which are diffi­cult to solve. When you run into one, it’s not always obvious what’s causing the prob­lem. Stuff just starts behaving weirdly. And I ran into just such a bug the other day.

I asked a good friend of mine to review my post on route naming in Pedestal. He’s not familiar with Clojure and said that he wanted to hear about how I chose Om and Pedestal. I had consid­ered including a summary of these choices, but it felt out of place, detracting from the main point of how I worked through a devel­op­ment prob­lem. While I don’t think my reasons for choosing these libraries are novel, I think they’re worth noting, so from the perspec­tive of someone rela­tively new to web appli­ca­tion devel­op­ment in Clojure, I’m noting them here.

Om Next remotes feature a single API endpoint that accepts both GET and POST request meth­ods. The Om Next parser looks at the request para­me­ter­s—not the request method—to deter­mine what action to take; only a single handler calling the parser is needed. How do you define Pedestal routes for the same endpoint with two request methods but only a single handler? Just starting out using Pedestal, the solu­tion wasn’t clear to me.

The web is not known for its fine typog­raphy and layout. There have been improve­ments over the years: wide­spread UTF-8 support makes char­acter set prob­lems less of an issue; post-processing tools make typo­graph­i­cally correct punc­tu­a­tion easier to use; advances in CSS provide alter­na­tives to table-based layout and made respon­sive design possible.

In the print world, tools such as LaTeX and Adobe InDesign give you a great deal of control over features such kern­ing, track­ing, liga­tures, hanging punc­tu­a­tion, orphans and widows, hyphen­ation, and justi­fi­ca­tion. CSS has limited support for some of these features (e.g., letter-spacing, text-align, justify-content, various Open­Type features), but it doesn’t compare to the level of control afforded by these other tools.

I inher­ited a Post­greSQL data­base that suffered from a lack of rigorous schema design. Column types were used and abused, such as Unix time values in varchar columns. Nullable columns for required data. Obscure naming conven­tions and magic integer values mixed with empty spaces and some­times special text values, none of which were docu­mented. Multiple comma-sep­a­rated ints in text columns.

It is not easy to effi­ciently repre­sent and access trees and other graph struc­tures in rela­tional data­bases, and this diffi­culty has moti­vated the popu­larity of graph data­base solu­tions such as Neo4J. That said, it’s not always prac­tical to set up a dedi­cated graph data­base in addi­tion to an existing SQL data­base instance.