Once again I’m doing a personal project that requires me to do some HTML parsing. If you have had to look at it, the landscape of Clojure HTML parsing libraries seems to be littered with dead projects.
Let’s look at the options.
Now that we have our Clojure application tested every time we push it to Gitlab, let’s configure another stage to deploy it to Heroku.
This assumes that:
- Anything you merge to
master is ready to deploy,
- You have your Heroku API key handy, and
- You already have a Heroku app configured, with all the necessary environment variables.
There’s two ways we can do this.
Gitlab allows you not only to have free private repositories, but also to test them using free runners. These can run automatically, on push, for any branch or tag.
I keep a few private repositories with them, for personal projects and small experiments. I decided to give Gitlab CI a shot for a PostgreSQL-backed Clojure project.
There’s a basic example on the Gitlab CI repository. It gets and installs lein, which isn’t necessary. Instead, we’ll build use the
clojure:lein Docker image.
J. Pablo Fernández has recently posted a piece with the incendiary title of “Emacs is Hurting Clojure“.
I disagree with the idea behind the title, but then again, he seems to do so himself. He promptly clarifies:
Uncaught Invariant Violation: onlyChild must be passed a children with exactly one child.
Are you using Reagent and Bootstrap with ClojureScript, and getting this error?
In my case, the cause was that I had a
when inside an
OverlayTrigger. Seems like a no-no. Further testing showed you can’t have an
if either. Looks like
OverlayTrigger can only wrap data, not something that might change.
In my case the solution was simple enough, once I figured out the cause: I just extracted
when to wrap the
OverlayTrigger, instead of the other way around.
When I started working with Clojure, I wanted everything to be Clojure.
HTML? Vectors through Hiccup.
Configuration? Clojure maps.
SQL queries? Clojure lists.
After all, I might one day need to take advantage of Clojure’s functional abstractions to… um… well… I might need it, right?
There have been several questions floating lately to the effect of “How do I get started fast?” or “What’s the bare minimum I need to know to get hired?”.
In case you’re wondering how to do that… you’re not going to like this answer.
Updated the ClojureScript version, and now you’re getting build errors? Check the Clojure version.
If you do an upgrade through
lein ancient update, it will not upgrade the Clojure version. But if you have a ClojureScript dependency, it will be upgraded, and you may run into a case like this when building:
No such var: string/index-of, compiling:(cljs/source_map.clj:260:54)
I got this error when going from ClojureScript 1.8.34 to 1.9.93. I wasn’t using
index-of directly, which is a Clojure 1.8 function… but ClojureScript was.
Last week I read an article from the MIT Technology Review that looked into what causes people to make mistakes. The approach was one I hadn’t seen before: it used data mining on a set of chess games. Their rationale was that:
- There’s a huge database to feed your model from,
- Chess is a deterministic domain where you can objectively evaluate good and bad moves,
- There are clear criteria for the skill level of the participants, even when disparate, which allows you to balance.
As spoiled by the title, complexity was the main factor whenever a player made a mistake.
The bottom line is that the difficulty of the decision is the most important factor in determining whether a player makes a mistake.
So what’s the big deal?
I’ve released Relevance, my smart tab organizer for Chrome, under the MIT license. You can find the ClojureScript source code on GitLab, and the extension on the Chrome web store.