I’m working on an Om Next app with a Pedestal backend. Figwheel is a great way to do ClojureScript development, 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 difficult to solve. When you run into one, it’s not always obvious what’s causing the problem. 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 considered including a summary of these choices, but it felt out of place, detracting from the main point of how I worked through a development problem. While I don’t think my reasons for choosing these libraries are novel, I think they’re worth noting, so from the perspective of someone relatively new to web application development in Clojure, I’m noting them here.
Om Next remotes feature a single API endpoint that accepts both
POST request methods. The Om Next parser looks at the request
parameters—not the request method—to determine 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 solution wasn’t clear to me.
The web is not known for its fine typography and layout. There have been improvements over the years: widespread UTF-8 support makes character set problems less of an issue; post-processing tools make typographically correct punctuation easier to use; advances in CSS provide alternatives to table-based layout and made responsive design possible.
In the print world, tools such as LaTeX and
Adobe InDesign give you a great deal of control over features such
kerning, tracking, ligatures, hanging punctuation, orphans and widows,
hyphenation, and justification. CSS has limited support for some of these
OpenType features), but it doesn’t compare to the level of control afforded by
these other tools.
I inherited a PostgreSQL database 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 conventions and magic integer values mixed with empty spaces and sometimes special text values, none of which were documented. Multiple comma-separated ints in text columns.
It is not easy to efficiently represent and access trees and other graph structures in relational databases, and this difficulty has motivated the popularity of graph database solutions such as Neo4J. That said, it’s not always practical to set up a dedicated graph database in addition to an existing SQL database instance.