DEV Community: Francesco

Trying out Zola static site generator

Francesco — Tue, 25 Jul 2023 12:25:17 +0000

Original post here

Overview

Recently I switched from Haunt to Zola as the static site generator for
this blog. Main reason was a bit of frustration with Haunt's documentation
and the CommonMark implementation it was using which was holding me back.

Why the switch

When starting this blog I wanted something simple and potentially hackable,
in terms of being able to play with the generator like any other Lisp program,
modifying it a runtime and seeing the result of the change right after it happened.

While Haunt is totally capable of doing so the first roadblock (at least for me)
is that it is written in Guile which I don't know at all; given that it is a
Lisp I hoped to get into it quickly, but I've never studied it or played with it
too much, and there is only so much time in a day so I cannot play with all the
fun things that there are around and at the same time hope to get some work done!

So I started looking for alternatives, maybe leaving aside the hackability of the
underlying system in favor of focusing on writing content.

Don't get me wrong, Haunt is very nice and customizable, it is not just a toy and
for example it is used to build the Guix website (and others); it is possible to
look at that site sources to get an idea on how to write a great website!
The problem is that I did'n manage to learn few fundamental things, Guile and
Haunt internals, quickly enough to be confident with this system and be productive
with it. Better luck next time, maybe.

Candidates

Cryogen

Language: Clojure
Documentation: While complete the feeling is that it does not flow too well

Pros:

You have the engine at your hand and you can hack on it easily while running
Easy to start

Cons:

Custom front matter format (EDN)
Takes some time to get into it, not ideal if you just want a quick blog with your style
Documentation could be better

Nikola/Pelican

Language: Python
Documentation: Complete

Pros:

Battle tested
Extensible (with lots of extensions)
Lots of themes

Cons:

Custom front matter
Too big for my needs

Hugo

Language: Go
Documentation: Complete

Pros:

Battle tested
Extensible (with lots of extensions)
Lots of themes (I mean LOTS!)
Comes packaged in a single binary

Cons:

I could not find a clear path to get to my first post quickly
Having a lot of features I felt lost in the docs, which caused friction/churn
Too big for my needs, the home page says "The world’s fastest framework for building websites"

Zola

Language: Rust
Documentation: Complete

Pros:

Documentation was feeling just right for my needs
The home pages says "Your one-stop static site engine", just what I need
Quick time to first post and custom layout
Lots of themes (and more are coming to it)
Comes packaged in a single binary

Cons:

Maybe not as feature rich as others (not a problem for me)

Final decision

Admittedly I did not run a very scientific comparison process, what I did was
to try to run a generator with its defaults, hack it a bit and measure:

time to get to the same layout and a first post
level of frustration while doing so
documentation
…gut feeling

What I did not care about:

speed of generation of content
programming language
availability of themes

Following the principle of "least resistance path" I went with Zola because
the process to get to that first post was really painless! Some engines were
not properly documented, with other I felt overwhelmed by options or in the
end it did not feel just right.

It took me 10 minutes to get Zola's approach and file structure, another 30
minutes of grunt work to port the front matter of posts from Haunt (I could
have automated it but it was too hot that day and I was not able to think too
much, but it would have been a nice exercise with Babashka!).

While others may be more complete solution to build complex websites, what I
really want is a tiny container for my posts, potentially some other pages
like contact section, bio etc. and Zola was able to deliver in just no time.

Your requirements may be totally different and other engines may work better
for you, all I can suggest is to try (some of) them and see which one sticks
to you!

Clojure Bites - Ring basic auth

Francesco — Thu, 06 Jul 2023 08:21:54 +0000

Overview

I am on vacation so I have decided to take it easy and work on small
things on Unrefined; one item in the backlog seemed quite approachable:
adding an admin panel to the project, which requires, among other things,
a way to authenticate users to access those restricted sections.

Here is a quick intro to how to add Basic Auth support to a Ring web
application, using ring-basic-authentication middleware, and, as a bonus,
an intro to clojure.core.cache library.

Project setup

To show how the middleware works we can create a simple web application with
just one endpoint which later we can protect with basic auth. Start a new
project or use your favorite playground and add the following dependencies:

ring/ring-core 1.10.0
ring/ring-jetty-adapter 1.10.0
ring-basic-authentication/ring-basic-authentication 1.2.0

Feel free to use your preferred project and dependency management tool, here I
show how to do that with tools-deps, it is easy to translate it to lein or boot:

{:paths ["src" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.11.1"}
        ring/ring-core {:mvn/version "1.10.0"}
        ring/ring-jetty-adapter {:mvn/version "1.10.0"}
        ring-basic-authentication/ring-basic-authentication {:mvn/version "1.2.0"}}
 :aliases
 {:dev/repl {:main-opts ["-m" "nrepl.cmdline" "&#x2013;middleware" "[cider.nrepl/cider-middleware]"]
             :extra-paths ["dev"]
             :extra-deps {cider/cider-nrepl {:mvn/version "0.31.0"}
                          djblue/portal {:mvn/version "0.35.1"}
                          com.github.jpmonettas/clojure {:mvn/version "1.11.1"}
                          com.github.jpmonettas/flow-storm-dbg {:mvn/version "3.3.315"}}
             :jvm-opts ["-Dclojure.storm.instrumentEnable=true"]}
  }}

The extra alias :dev/repl is my usual goto setup for development, it is not required
to run the examples but it can be generally handy; feel free to ignore it if you
have your own way.

Now we can create a new src/app.clj (or whatever ns you prefer) with the following
content:

(ns app
  "A namespace used to show how the basic-authentication middleware works"
  (:require [ring.adapter.jetty :as jetty]))

(defn handler
  "Our basic ring handler function, it takes a request map (unused) and
   return a response map"
  [_request]
  {:status 200
   :headers {"Content-Type" "text/html"}
   :body "Hello World"})

;; We want to hold the server instance in order to close it once done.
;; There are better ways to do it, using life cycle/state management libraries
;; like mount, integrant, component just to name few, but lets keep it simple
(def server-instance (atom nil))

(defn start-server
  "Starts a web server holding its instance in the server-instance atom"
  []
  (reset! server-instance
          (jetty/run-jetty handler {:port 3000
                                    :join? false})))

(defn stop-server
  "If there is a server running, stop it and reset the server-instance atom"
  []
  (swap! server-instance
         (fn [inst]
           (when inst
             (.stop inst)))))

(comment
  (start-server)
  (stop-server)
  ,)

If we start a REPL and evaluate the buffer (file) we can start the server by
evaluating the fist form in the comment form, and pointing a browser to
http://localhost:3000 we should be able to see something like this:

Protecting the route

The library ring-basic-authentication offers the ring middleware
wrap-basic-authentication that will call a function accepting a username
and a password and returns a truty value on success (authenticated)
or a falsy value otherwise. On success the next middleware (or handler) will be
called, otherwise it will return a 401 response.

The first thing we can do is to write a function that will authenticate (or not) a
request based on provided username and password, here is the simplest implementation
we can write:

(defn authenticated?
  [username password]
  (and (= "secret-username" username)
       (= "secret-password" password)))

Now it is time setup ring to use the middleware to autheticate requests. Lets
re-write the start-server function to do that:

(defn gen-app
  []
  (wrap-basic-authentication handler authenticated?))

(defn start-server
  "Starts a web server holding its instance in the server-instance atom"
  []
  (reset! server-instance
          (jetty/run-jetty (gen-app) {:port 3000
                                      :join? false})))

The utility function gen-app returns a new handler using the wrap-basic-authentication
middleware to wrap our request handler; start server calls the gen-app function
when starting the server, to get the application handler function.

We can see it in action in the following screenshot

Now for each request this is the flow:

ring calls the app handler
the basic auth middleware is called and
if successful it will return the result of calling the wrapped handler
if not it will return a 401 without even calling the wrapper handler

In ring world this is the usual flow; in general we can expect to have chain of
middlewares before the call to the request can even start, common middlewares can
be used for:

request routing: given a path call a specific handler
request parameter parsing: parsed parameters, coming from query string, body etc are injected for later use
response transformation: for example to serialize to JSON, XML or other formats
session, authentication and authorization handling
request logging and metrics

There are quite a lot of already existing and useful middlewares that can be
used off the shelf.

Even if this approach can be good enough for some small and private services it
can become unusable or hard to maintain pretty easily if the service grows or must
be exposed to the public internet; few issues that can come to mind:

Hardcoded credentials: even if the project sources can be private it is easy to leak them, better to load them from another source
If we want to change credentials a new build is required; not the end of the world but not really convenient
There is no way to have different handlers and URL with or without the basic auth

Lets make it flexible

First thing we can do to improve this example is to get rid of those ugly hardcoded
credentials.

One way could be to load the username and password from environment variables; as one
extra step would be to on the safe side we can avoid having defaults so that if
we forget to set the environment variables no one can access the restricted
resources. Here is one possible way to authenticated? for our new requirements:

(let [secret-username (:basic-auth-username env "")
      secret-password (:basic-auth-password env "")]
  (defn authenticated?
    [username password]
    (and (seq secret-username) ;; making sure this two are set to something
         (seq secret-password) ;; TIL that (seq "") is equivalent to (not (empty? "")), thanks clj-kondo!
         (= secret-username username)
         (= secret-password password))))

Wait wait wait, where is this env coming from?

Even if is possible to get the value of environment variables using Java
interop via System/getenv I have decided to introduce the library environ
because it offers a Clojure only interface and provides more goodies like
reading environment variables from env files or JVM properties and has a
nicer interface (IMHO).

To be able to use this library all we need to do is
to add it to our deps.edn (or…you know) and refer the env symbol in our
namespace. For more details please refer to the library docs, all we need to
know now is that it behaves like a normal map, at least for reading.

Oh, one more thing, keywords are translated to "UPPERSNAKECASE" when looking
them up, in our case :basic-auth-username will lookup BASIC_AUTH_USERNAME
environmental variable.

Even more flexible

Now we want to give access to the protected resource to more people and usually
sharing the same credentials is not a good practice; what happens if we want
to invalidate the access for one of the users? We should create new credentials
and share it only with the ones whom should have access to the resource. It is
not really practical, is it? So at this point we may want to have user specific
credentials but handling them with env vars can be too complicated or unpractical.

An option is to store credentials in a file that we can read at the start of the
application, in case someone leaves our organization we can update our credentials
file and restart the app. For convenience we can read the credentials file path
from an environment variable, we already know how to do it right? Right.

(defn get-credentials
  "Return a username -&gt; password map reading it form the specified file, or an
   empty map it reading fails"
  [credentials-path]
  (try
    (with-open [r (io/reader credentials-path)]
      (edn/read (java.io.PushbackReader. r)))
    (catch Throwable  _ {})))

(defn authenticated?
  [username password]
  (let [credentials (get-credentials (:basic-auth-credentials env "credentials.edn"))]
    (= (get credentials username) password)))

Now authenticated? will read the credentials from an edn file whose path is taken
from the BASIC_AUTH_CREDENTIALS environment variable (defaulting to some well
known path). If the credentials will ever change we must restart the application
to see the new values, not the end of the world but we can do a bit better.

The idea is to cache the credentials with a TTL, so when it expires we can read
the file again with possibly new values. Implementing a cache with TTL is a nice
exercise but we can leverage the clojure.core.cache library that implements
this functionality for us. I am not going to write about this library in detail,
the documentation does a great job anyway, so I'll focus on the bare minimum
to get things done.

Assuming that we have added the library to our dependencies and required it in
our namespace, we can change autheticated? to make use of it:

;; create a TTL cache with an empty map and a ttl of 60 seconds
(def credentials-cache (cache/ttl-cache-factory {} :ttl 60000))

(defn authenticated?
  [username password]
  (let [credentials (cache/lookup-or-miss
                      credentials-cache
                      :credentials ;; we try to lookup the key :credentials in the cache
                      (fn [_]      ;; if the key is missing or expired we load the credentials file
                        (get-credentials (:basic-auth-credentials env "credentials.edn"))))]
    (= (get credentials username) password)))

This is a sorts of an hack of the TTL cache; usually you want to cache with TTL different keys,
and load the value of those keys (from DB, external APIs, whatever) when the TTL expires. In our
case we just want to load the whole file so we are using the key :credentials to hold its
content. The clojure.core.cache implements quite a lot of caching strategies, I encourage everyone
to give it a try!

Conclusions

If dealing with a simple application, using basic auth can be good enough
and we have explored different ways to achieve that; clearly, as the application
grows, other authentication mechanisms like a full suited identity/role management
solution may be a better fit. Currently I am exploring Keycloak, hoping to come
up with a library for Clojure.

Sources for this little project can be found in my shiny new playground repo,
specifically in the ring_basic_auth.clj file

Alternatives

Every web server provides a way to protect one (or more) endpoint at the
server configuration level, sometimes it can be even convenient to
leverage that functionality; the only downside I see in this approach is
that it couples the application to the web server serving it.
If the endpoint structure is sufficiently complex it is easy to forget
something in case of a migration to a different web server.

Another alternative is to use the same authentication/authorization mechanism
used for normal users and play with roles and permissions to enable/disable
access to specific resources. In the longer term this is the approach I
would take given that it reduces special cases and makes role management
more consistent.

Clojure Digressions - Setting up a playground

Francesco — Fri, 23 Jun 2023 12:49:06 +0000

Original post

Disclaimer

Why a new series named Clojure Digressions?

Clojure Bites is more suited for short introductions to Clojure
related libraries and tools, instead with digressions I'd like to
talk about more general topics, like development environment setup,
good/bad habits and personal development as a Clojure developer.

Like a conversation ice breaker, I start by talking about my personal
take on some specific argument, looking forward to get input from
other, possibly more experienced, developers on some specific topic.

Overview

A playground is a safe place aimed at experimentation, without any
legacy background limiting your fantasy and willingness to explore
solutions outside your usual comfort zone i.e. all the code you have
already written for your company/product.

It is no secret that as professional developers we are expected to reuse
as much as possible of what we have at hand in our code base, being careful
when adding new dependencies, limit experimentation to when it is really
really needed to avoid introducing unforeseen costs but at the same time we
love to try out new things! What if we had a safe place to experiment,
just taking out a small bit of our business domain and test it against
a different approach?

Starting from scratch

You want to quickly sketch out something, no REPL is running, the first
thing you can do is to fire up an interactive REPL by running $ clojure
or, if you want readline support, $ clj; now you have a prompt where you
con evaluate forms using the rich clojure.core library. Nothing too advanced,
the same is available with the default Python, Ruby and many other prompts.
But it is still something.

Lets spice up our REPL by replacing the standard readline lib with
rebel that will give us autocompletion,
hints and much more. To try it out quickly:

clojure -Sdeps "{:deps {com.bhauman/rebel-readline {:mvn/version \"0.1.4\"}}}" -m rebel-readline.main

The -Sdeps\ is used to pull in more dependencies, the -m\ parameter is used to
specify an entry point to be called; this will initialize a REPL session using
rebel readline interface. Learn more here.

If you'll like it you can create an alias in your ~/.clojure/deps.edn\ file in
order to be able to start a rebel REPL without being forced to remember all the
required parameters, here is an example:

{
 :aliases {:rebel {:extra-deps {com.bhauman/rebel-readline {:mvn/version "0.1.4"}}
                   :main-opts  ["-m" "rebel-readline.main"]}}
}

And invoke it simply with:

clojure -M:rebel

The asciinema of the official docs is worth one
billion words ;)

Beyond throw away sessions

Working directly in the REPL prompt is not really ergonomic in some cases and you may
prefer the comfort of your favorite IDE or editor to hack on some code; the first
step is to start a REPL to which you can attach to. As with rebel readline it not
required to to have an alias in your $HOME/.clojure/deps.edn or project's deps.edn:

clojure -Sdeps "{:deps {nrepl/nrepl {:mvn/version \"1.0.0\"}}}" -m nrepl.cmdline

nREPL server started on port 39435 on host localhost - nrepl://localhost:39435

Now you can connect your IDE to the REPL and start hacking! Please notice that the
port may change at each invocation. Deciding what to work on is left as an exercise
to the reader :)

Like we did for rebel readline, we can add an alias to our $HOME/.clojure/deps.edn
file to make it easier in future to start a REPL we can attach to:

{
  :aliases {:rebel {:extra-deps {com.bhauman/rebel-readline {:mvn/version "0.1.4"}}
                    :main-opts  ["-m" "rebel-readline.main"]}
            :nrep  {:extra-deps {nrepl/nrepl {:mvn/version "1.0.0"}}
                    :main-opts  ["-m" "nrepl.cmdline"]}}
}

Starting it with:

clojure -M:nrepl

At this point I encourage you to test this setup with your own IDE to get a real feel
of it.

Some more spices

Being able to run a REPL on demand is already something useful but we can get more
out of it, for example being able to pull in new dependencies on demand in the
currently running process using the upcoming add-lib in the repl.deps
module.

Add a new alias to our clojure deps file:

{
  :aliases {:rebel {:extra-deps {com.bhauman/rebel-readline {:mvn/version "0.1.4"}}
                    :main-opts  ["-m" "rebel-readline.main"]}
            :add-libs {:extra-deps {clojure.org/clojure {:mvn/version "1.12.0-alpha3"}}}
            :nrep  {:extra-deps {nrepl/nrepl {:mvn/version "1.0.0"}}
                    :main-opts  ["-m" "nrepl.cmdline"]}}
}

Now we can add this capability to either rebel or nrepl alias, for example, running:

clojure -M:add-libs:rebel

will start a new REPL pulling in both the new Clojure version with support to dynamically
load libraries and a rebel readline prompt; the same would apply if replacing rebel with
nrepl, i.e. we would have a nrepl session with the add-libs support.

It is useful to be able to combine more functionalities coming from different aliases when
starting a new REPL process. Again I encourage everyone to play with it and come with a setup
the covers your requirements.

Other useful tools worth considering for your personal toolbox:

Portal: A clojure tool to navigate through your data.
FlowStorm: A tracing debugger for Clojure and ClojureScript.
ClojureStorm: Companion FlowStorm Clojure implementation that automatically instruments your code to be used with FlowStorm.

It can be seen as a safe place to play with unknown possible solutions,
in an isolated environment, collect useful information and then decide
if we can introduce them to our daily stack.

How can it be useful?

Which tools should I include in mine?

Is there something obvious that I am missing?

Are we playground yet?

We have learned how to setup an interactive or a nREPL to connect to from an
IDE and we have added some useful tools to improve our developer experience
but where do we put the results of our experiments? I usually start a new
project each time I want try out something and honestly it is a straight
forward process especially if using tools like clj-new, taking from the project
README:

# one-off to install clj-new as a tool:
clojure -Ttools install com.github.seancorfield/clj-new '{:git/tag "v1.2.399"}' :as clj-new

# commands to create new projects:

# create a new app:
clojure -Tclj-new app :name myname/myapp
# create a new library:
clojure -Tclj-new lib :name myname/mylib
# create a new template:
clojure -Tclj-new template :name myname/mytemplate
# create a new project from a public template:
clojure -Tclj-new create :template electron-app :name myname/myelectron-app#+END_SRC

Recently maybe I have created too many throw away projects and creating a full
fledged project structure each time feels like a waste of time; ideally I'd like
to open a new file, connect to a fully capable REPL (or start a new one) and
start hacking. When finished commit the new file or changes to existing ones and
move one.

One advantage I see with this approach is that I can keep all these small projects
in one place, accumulating knowledge that can be easily reused later. An added
benefit is that it is easy to add another powerful tool like Clerk to generate
playbooks to interact with and document the code; two months from now you may
want to get back to your experiment and easily get back to it and its conclusions
without spending too much time.

Conclusion

We started from a simple REPL, added some tasty juice to it and ended up creating
a safe place to play and experiment. I want to point out that this is just my personal
take and not a default in the Clojure community (or if that is, it is just a coincidence).

I am curious to learn how others are addressing the same problem, if it is a problem anyway.

Clojure Bites - Render HTML, introducing selmer templating library

Francesco — Thu, 08 Jun 2023 19:33:58 +0000

Sometimes all we need is a way to render HTML out of a template, selmer is a great library for that, lets have a look at it! https://fpsd.codes/clojure-bites---rendering-html.html

Coding live session starting 3PM CEST, come and join me for a chat!

Francesco — Sun, 28 May 2023 09:17:08 +0000

For the first time in my life, today I am going to stream while I work on one of my side projects.

I want to invite you all to join me, today May 28 at 15:00 CEST, on Twitch https://www.twitch.tv/fpsd_codes !

Why I am doing this? Because I think that having a potential audience would help me to stay focuses on the code without (too many) distractions and because building a side project it is easy to feel alone :)

I will keep notes on Dynalist, if you want to have edit access to the document to contribute, please ping me!

See you later!

Clojure Bites - Structured logging with mulog

Francesco — Wed, 24 May 2023 20:01:33 +0000

Full post here

Looking forward your comments!

Overview

Logging is a fundamental tool to monitor and debug a running system.
Even if we can use logs to gather metrics about our system, these are
often written with the assumption that humans are going to consume them,
which make it hard to extract meaning information from log messages.

Log messages are rarely consistent or even meaningful if read few days
after writing them during your emergency debug session. Writing good log
messages is hard! Almost as hard as naming things and cache invalidation.

Another overlooked problem is that often logs are are context less, what
can we infer by a message like "Failed to process user payment" if we don't
know what triggered the payment process, the affected user or product?

Structured logging

Structured logging aims to provide query-able, consistent, information rich
logs that can be used for:

Business intelligence: derive business relevant data from logged events
Monitoring: understand the current state of a system
Debugging: understand the context in which an error has been reported

Clojure bites - dynamically add depencencies at runtime!

Francesco — Fri, 12 May 2023 17:34:51 +0000

Full article

Overview

One pain point of REPL driven development is that even if it is possible to
change an application while it is running, if you want to experiment with a
new library it is need to add a new dependency to your project and restart the
REPL to use it, possibly breaking your flow.

Fortunately a new set of functions to alleviate this pain are in the works
and ready to be tested since Clojure 1.12.0-alpha2:

add-lib: Given a lib that is not yet on the repl classpath, make it available by downloading the library if necessary and adding it to the classloader.
add-libs: Given lib-coords, a map of lib to coord, will resolve all transitive deps for the libs together and add them to the repl classpath, unlike separate calls to add-lib.
sync-deps: Calls add-libs with any libs present in deps.edn but not yet present on the classpath.

Get the full content

This time the content of the post is be available on my site, especially to avoid editing it in too many places. Please let me know it is a deal breaker! If that is the case, I'll replicate it here.

Looking forward your feedback!

Data driven unit tests with Clojure

Francesco — Tue, 02 May 2023 06:10:54 +0000

original article + updates

Overview

Clojure's clojure.test/are provides a data driven approach to unit testing.
Lets start with a practical example, implementing the most important function
in the history of computer science, FizzBuzz! (But only because all of my
binary search trees are already balanced).

FizzBuzz

It is (was?) common that, during an interview, to be asked to implement the
logic of the FizzBuzz game, Wikipedia has a nice article about it.

It can be summarized as follows:

Write a function that takes a numerical argument and returns:

The string Fizz if the number is divisible by 3
The string Buzz if the number is divisible by 5
The string FizzBuzz if the number is divisible by both 3 and 5
The argument if none of the previous conditions are met

The implementation

Lets start by defining the test suite using the usual clojure.test/is macro.

    (ns fizzbuzz.core-test
      (:require [clojure.test :refer [deftest is testing]]
                [fizzbuzz.core :as sut]))

    (deftest OMG-FizzBuzz
      (testing "Should return the numerical argument"
        (is (= 1 (sut/fizz-buzz 1))))

      (testing "Should return Fizz"
        (is (= "Fizz" (sut/fizz-buzz 3))))
      (testing "Should return Buzz"
        (is (= "Buzz" (sut/fizz-buzz 5))))
      (testing "Should return FizzBuzz"
        (is (= "FizzBuzz" (sut/fizz-buzz 15))))
      )

Please note that sut stands for system under test; I've seen it being used
here and there but I am not sure it is a best practice or not.

The test will clearly fail because there is no fizz-buzz function or even a
fizzbuzz.core namespace. Lets start with a trivial implementation.

    (ns fizzbuzz.core)

    (defn fizz-buzz [n]
      (cond
        (= 0 (mod n 15)) "FizzBuzz"
        (= 0 (mod n 3)) "Fizz"
        (= 0 (mod n 5)) "Buzz"
        :else n))

Now all tests are passing, the interviewer is more than happy but you
want to show off your skills and ask to improve both code and tests

Improvements

First thing to notice is that if a number is not a multiple of 3 or 5 then
we run 4 divisions and return n. A slightly improvement can be the following:

    (ns fizzbuzz.core)

    (defn fizz-buzz
      [n]
      (cond
        (= 0 (mod n 3)) (if (= 0 (mod n 5)) "FizzBuzz" "Fizz")
        (= 0 (mod n 5)) "Buzz"
        :else n))

Test are passing so we are confident that the function is working as expected,
and it is a bit more performing! Yes, we are not solving the world's energy
crisis but it is something.

Data driven tests

Looking at the tests we can notice that we are calling the same function with
different input values and expecting a specific result. User of other testing
libraries, for example Pytest may be familiar with the parametrize decorator
that takes tuples of data and calls the test case with that data as parameters.
In Clojure we can achieve that with clojure.test/are macro, here is the docstring:

"Checks multiple assertions with a template expression.
See clojure.template/do-template for an explanation of
templates."

A bit cryptic but an example can help us understand better.

    (ns fizzbuzz.core-test
      (:require [clojure.test :refer [deftest are]]
                [fizzbuzz.core :as sut]))

    (deftest OMG-FizzBuzz
      (are [argument expected] (= expected (sut/fizz-buzz argument))
        1 1
        2 2
        3 "Fizz"
        6 "Fizz"
        5 "Buzz"
        10 "Buzz"
        15 "FizzBuzz"))

And voila, we have a data driven test suite for our implementation!

Closing words

I hope this will encourage exploring Clojure's core library, to spot little
gems like this one, and to have added a new tool to your toolbox!

Code for this post can be found here.

Segmenting my audience

Francesco — Thu, 27 Apr 2023 16:21:50 +0000

Hi everyone!

After a long time reading DevTo contents I've started posting about my projects but soon after that I've realized that my writings were not a good fit for the community, which looks more interested in tech other than products (but if I am wrong, happy the learn that!).

From now on I'll try sharing only tech related topic here, which is a perfect fit, because you know, we have soooo much to learn from each other!

That said, here is my latest post, hoping to find Lisp/Scheme/Guile enthusiasts around the corner :) https://fpsd.codes/random-bits.html

My project got a shiny new Chrome Extension!

Francesco — Mon, 24 Apr 2023 12:13:29 +0000

I have few days off at work, so a good opportunity to work on my projects!

Today's post is about the new Unrefined's Chrome Extension, which should streamline the job of EMs.

Get it here https://fpsd.codes/announcing-unrefineds-chrome-extension.html

p.s. It is exciting to build in public, I feel more encouraged to make progress and I am procrastinating way less than usual!

Updates on my #buildinpublic effort

Francesco — Fri, 21 Apr 2023 17:59:05 +0000

Hi Everyone!

I have a new update on my projects' roadmap, why I haven't published much content this week and next steps.
https://fpsd.codes/updates-on-projects.html

Question: anyone interested attending a live coding session? It would be fun to get realtime feedback and getting in touch with other devs!

All my projects are build in public (sources included, of course), but this happens post-facto, I think it would be an interesting experience to share the design/development process, while it is happening! (plus, I've never streamed before so it can become quite ridiculous...)

Let me know what do you think.

p.s. I have tagged the post with #clojure and #javascript because these are the main languages for my current project ;)

Introduce yourself, take 2

Francesco — Mon, 17 Apr 2023 19:27:05 +0000

And hello again dev.to community!

I have no followers so I will be talking to myself most probably but anyway I think it is important for me, as a new member, to share as much as possible since the beginning of my presence here.

Recently I have started a new website, to keep track of the progress of my projects:

tools or products
learning new things, like programming languages, tools, recipes, whatever
communication

There is no clear path yet, but I'll be happy to share everything in the process, hoping to be useful for others as well as for myself.

It is all for now, if curious point your browser to https://fpsd.codes

It be great to get any kind of feedback, see you soon!