During this year’s I.T.A.K.E. Unconference, Alexandra Marin started an open space about freelancing and running your own business. I’ve been doing consulting and contracting for years, and I keep seeing the same misconceptions on developers who are just starting, so I jumped in to see if I could contribute.
Here’s what I’ve found, over the years, is the main misconception held by developers who are just starting to look for clients: what contracts are useful for.
In case you’re not familiar with them, AWS Lambdas are a fascinating idea - they are server functions you can create and run without first provisioning servers: you write your code, upload it, and pay only for the time that is executed.
There’s only one (somewhat minor) catch: given that there is no provisioned server capacity at all, the first time that you execute a lambda it has to be warmed up. The code stays live for a period of time after the first execution, but given Clojure’s start up time cost, I was wondering what effect that would have on a Clojure lambda.
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.
Update and friends
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.
The story so far
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.
DynamoDB and Clojure
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.