ANNOUNCEMENT: ME.PMATIELLO/OPENAI-API

me.pmatiello/openai-api is a pure-Clojure wrapper around the OpenAI API, offering various functions for interacting with the API’s capabilities. These include text generation, image generation and editing, embeddings, audio transcription and translation, file management, fine-tuning, and content moderation.

(require '[me.pmatiello.openai-api.api :as openai])

(def credentials
  (openai/credentials api-key))

(openai/chat {:model    "gpt-3.5-turbo"
              :messages [{:role    "user"
                          :content "Fix: (println \"hello"}]}
             credentials)

Notice: This is not an official OpenAI project nor is it affiliated with OpenAI in any way.

Refer to the project page and documentation for more.

ANNOUNCING MOCKFN

me.pmatiello/mockfn is a library supporting mockist test-driven-development in Clojure. It is meant to be used alongside a regular testing framework such as clojure.test.

It provides two macros to be used in tests. The first, providing, replaces a function with a configured mock.

(testing "providing"
  (providing [(one-fn) :result]
    (is (= :result (one-fn)))))

The second macro, verifying, works similarly, but also defines an expectation for the number of times a call should be performed during the test.

INJECTING AKKA ROUTERS AS DEPENDENCIES IN A PLAY APPLICATION

Sometimes, an actor can’t keep up with the amount of messages it receives. When work is produced at a faster rate than it can be consumed, the system is in trouble. A bounded mailbox will drop messages that were intended to the actor while an unbounded one will grow until it consumes all the available memory and crashes the application.

If the task being performed isn’t CPU-bound or if there are enough cores available in the machine, a simple solution might be just have enough instances of this stressed actor working in parallel. Akka helps us to implement this by providing routers: actors that proxy, supervise and delegate messages to the child actors it manages. That is, when a mensage is sent the the router, it will be forwarded to one of the managed actors so that it can be properly handled. For the producer originating the messages, nothing changes: it just needs an ActorRef to the router and it can be completely ignorant about the size of the pool of consumers and whether it is pushing work directly to the consumer or through an intermediate.

REQUEST-SCOPED DEPENDENCY-INJECTION IN PLAY FRAMEWORK WITH MACWIRE

Update (09 Jul 2015): This post was written for Play 2.3.x. Since version 2.4.0, dependency injection is supported out of the box in Play through Guice. Also, changes in routing at this version of the framework break the approach described here.

Controllers in Play Framework are usually defined as singleton objects. In fact, Play’s documentation defines a controller as a singleton object that generates Action values and provides an example like the one below:

object Application extends Controller {
  def index = Action {
    Ok("It works!")
  }
}

This kind of design is not without problems. Any dependencies of these controllers must be constructed inside the controller, tightening the coupling between them as the controller must now concern itself with one more aspect of its dependencies, namely, their construction.

DATABASE ISOLATION FOR TESTS IN PLAY FRAMEWORK

Play Framework provides decent support for unit and functional tests. Tests using the WithApplication, WithServer or the WithBrowser abstract classes will bootstrap your application so that configurations are loaded and databases connections are available. Yet, nothing is provided out of the box to ensure that database changes made during the execution of a test will not leak into other tests or into the development environment.

About Play, Slick and specs2

Here, we’ll be using Slick for persistence and specs2 as testing framework, but the general idea should apply to different libraries without any major changes. The use of these libraries with Play is outside the scope of this post, but these links should do a good job at introducing the subject:

USING A DIFFERENT CONFIGURATION FILE WHEN RUNNING TESTS IN A PLAY PROJECT

Play Framework, as of version 2.3.x, typically loads the configuration for your application from conf/application.conf. Although it works as expected, it doesn’t allow for different configurations to be used in different environments unless the file is replaced. This is specially inconvenient when running tests directly from Activator since these tests will be executed against the same database used for running the application in development mode.

Luckily, Typesafe Config and SBT provide all that is necessary to work around this issue cleanly.

FUTURES IN SCALA

Scala 2.10 introduced futures as a convenient abstraction for concurrent programming. Using futures, one can perform a number of computations in parallel for which the result is expected to be available, at some point, in these Future objects.

A result in a Future can be easily retrieved without blocking the execution flow by setting a callback to be invoked once it’s ready:

val fut = future { slowComputation }

fut.onSuccess {
	case result => useSuccess(result)
}

This callback is guaranteed to be executed after the future completes successfully. It’s also possible request a callback to be executed if the future fails with an exception:

A FEW TRICKS FOR WRITING FASTER RUBY CODE

Recently, I was busy at work trying to make some Ruby code we’ve had written run faster. This is somewhat outside my zone of confort: I’m mostly concerned about design, correctness, testability, etc, and most of the time, my concerns about performance are restricted to proper choice of algorithms, data structures and caching strategies. Although I’ve done my share of profiling and performance improvements on Java applications, this was my first time doing something like that in Ruby. And as I haven’t found much on this subject on Google, I decided to share here some of the stuff that proved themselves helpful to my problem.

A KIND OF INFORMAL INTRODUCTION TO Π-CALCULUS

The π-Calculus is one of many approaches to concurrent computation by the means of formal modeling. Its purpose is to enable us to reason about concurrent processes in a disciplined fashion by manipulating expressions through formally defined algebraic rules.

Any exposition of the calculus will eventually introduce you to the primitive notions:

• Agents, which can be understood and even referred as processes.
• Actions, which are anything that can be done by an agent.
• Channels, which are links connecting agents, alowing them to communicate.
• Names, which are exchanged through channels.

The general idea is that we have a set of agents connected to each other through channels in some sort of network. These agents then use these channels communicate to each other by exchanging names.

IMPLEMENTING INTERFACE CONTRACTS IN PYTHON WITH CLASS DECORATORS

Python decorators are quite useful and interesting. I’ve already written about function decorators in a previous post and class decorators are a worthy followup.

I order to illustrate this feature, we’ll implement support for interface contracts for Python classes. In a language like Java, for instance, a contract can be declared this way: