UnitySteer 3.1 is out on GitHub.
The main update on this version is the addition of 2D support as a separate set of behaviors, thanks to the pull requests sent by @GandaG and extra changes by @PJOHalloran.
This is the final part of the series where I convert Amazon’s Getting Started to Clojure with Faraday. If you’ve just arrived, the previous parts were:
This part will correspond to steps 7 and 8 of the Getting Started guide. Let’s move on to updating and deleting data!
In part 1 we went over the basic table creation operations, as well as writing data, and on part 2 we looked at getting, querying and scanning data.
We’ve only been working with the primary key so far, but often we’ll want to get data using a secondary index. On this part we’ll follow step 6 of Amazon’s Getting Started. We’ll see how to create, query and scan them, as well as how Faraday handles these asynchronous calls.
On Part 1 we went over the basic operations - creating a table, checking its status, getting data in and performing a simple retrieval.
We’ll now look into various ways of retrieving items, including querying, scanning, and using projections to get only a few properties.
This assumes you’ve already completed part 1, since we’ll be using the data we added. As a reminder, I’m following the Javascript examples on basic DynamoDB operations, since they are the ones where the data set-up will more closely match Clojure. You may want to follow along for extra explanations and for comparison purposes.
There are two main options of accessing DynamoDB in Clojure right now - Amazonica, which provides a Clojure client through reflection that’s comprehensive but a direct translation of Amazon’s; and Faraday, which does not take the reflection approach and provides a simpler, more succinct access than one would otherwise get.
Both have a paucity of examples. Amazonica can probably better get away with it since it gets to piggy-back on the AWS examples out there, but Faraday’s tests have been growing and can double as examples.
I started with Faraday, since its more concise API was more appealing and I liked its reasonable defaults. In the process, I’ve added some missing functionality, expanded tests, and noticed that the examples from Amazon’s Getting Started tutorial weren’t fully covered.
Let’s fix that.
At the recent Thingmonk conference in London, I got to chatting about Clojure and ClojureScript. It’s an IoT event, so it was to be expected that the topic of performance on devices like the Tessel or Raspberry Pi would come up.
That got me thinking about the piece I wrote back in January about ClojureScript performance for Processing sketches. How much has ClojureScript performance improved since?
Let’s find out.
If you’re using re-frame as your pattern for single-page applications in ClojureScript (and why wouldn’t you?), then you are defining your events and handlers using keywords.
These are a prime example of when Clojure’s namespaced keywords come in handy.
You’ve written your Chrome extension in ClojureScript, whether using Khroma or any other alternative. You have a background script, maybe some content script that gets run on pages, maybe some code for a management UI. Everything’s fine on development, but when you’re ready to release and want to apply some optimizations, everything gets bundled together into a single file. Not only you end up with a larger JS that gets loaded multiple times, but your initialization code starts tripping over each other.
I started my recent Clojure talk by enumerating the “scary bits” for new users. The two I went into were the fundamentally different semantics, and that the doc strings for the core functions were succinct and exact, but not expansive in use cases.
There was one that I forgot to bring up, though: compiler error messages when there’s a problem with a macro call.
There’s been a lot of chatter on the topic this past week, since Colin Fleming gave a talk at Clojure/Conj on the subject focusing on how to improve them with grammars. The conversation has kept a positive focus on how to fix it, as opposed to piling negativity on the situation (go Clojure community!) but that does not mean we can expect to see a change right away.
I’d like to address how this might affect you if you’re just getting into the language, and what you can do about it.
While we’re on the topic of Clojure being useful…
I use git flow for all my projects. It’s relaxing to know that, even when you’re working solo, you have zero chance of screwing yourself over because - say - you need to make a hotfix but can’t because of a dirty master branch state.
In some projects like khroma I’ll use major/minor version for the release numbers. But in a lot of cases, like this very site, there’s no concept of a major or minor release - you just want to time-stamp each one. I may even need to start several releases a day.
I wrote a small ClojureScript helper to remove the chance of human error.