You are reading content from Scuttlebutt
@Soapy mcSoap %PNJ/YutE26UuFiMo+vDqLf6HSXuoWdbRBad1vahod8Y=.sha256

I had some time to procrastinate couple days ago. I really want to experiment more with #ActivityPub, but my energy to deal with JS is very low these days. I love the language, but I really don't like the ecosystem. If I was building a product, I'd definitely look into doing stuff with JS but since I'm not, I can do Racket instead.

Racket has three features that make creating toys and experimenting much more fun than in most mainstream languages:

  • It has an official IDE with a REPL, DrRacket. This means you can work from a GUI iterating and playing with functions avoiding the write-compile-debug cycle that in most languages requires hopping between multiple tools.
  • Battery included. Racket comes with a ton of stuff from the start. You might still need to install some libraries, but a handy package manager is available for those cases. For most experimentation, the features included in the default distribution are more than ok.
  • Unified documentation. Racket documentation trumps most other languages. It is not automatic generated and soulless. People, including third-party developers, take care to write good documentation using Racket's bundled-in documentation system (Scribble). The documentation is unified, meaning all the Racket's docs and the documentation for every third-party package live in the same site. Not only that, but Racket will materialise a version of that documentation site locally for your installation containing the documentation of all the libraries you have installed (and it is updated every time you install a new library). So you can get documentation from inside Dr Racket without going to the internet.

Enough about Racket, let's circle back to my procrastination. I understand now that these technologies I've been toying with — SSB, ActivityPub, etc — are too complex to be implemented in a single day. Most of my blogging toys can be implemented in a single day, from static generators to API clients. I get annoyed when things can't be implemented quickly and that usually leads me to distract myself and leave them unfinished. I'm working on this.

So, I decided to tackle a small project that I could finish a toy in a day and went ahead to implement a small WebFinger library. I want it to have both the client part and the server part, but in the time I had I could only implement the client part.

The library includes a small command line client (shown working above) that lets you retrieve the webfinger information for a given address.

It also has two functions, one for retrieving all the webfinger information and another to look for specific links.

(webfinger/link-for-rel-and-type "andre@toot.cafe" #:rel "self")

Returns "https://toot.cafe/users/Andre".

I've implemented them using some more advanced Racket stuff that I'm learning about. For example both functions are declared with contracts. They make sure you can only call them passing the correct value types.

I've also implemented test and a main submodules. This means that the test submodule always run before main thus making sure the library works before trying to execute. The main submodule runs if you're not importing the library but running it as the main script.

@Soapy mcSoap %g/wq5bhoo20cZCZTA6F/qb6SR38ftkJQp5g6xq8J/fU=.sha256

That is odd, that message is longer than this, I typed a lot more content.

@Soapy mcSoap %9W4RF20xpv6RKmryY9cJ0i8JZMMEGqEXOx5m0FsndFU=.sha256

It renders correctly on Manyverse but it doesn't on Patchwork.

Let me paste the extra content below:


I've implemented them using some more advanced Racket stuff that I'm learning about.

For example both functions are declared with contracts. They make sure you can only call them passing the correct value types.

I've also implemented test and a main submodules. This means that the test submodule always run before main thus making sure the library works before trying to execute. The main submodule runs if you're not importing the library but running it as the main script.

@Soapy mcSoap %PIYVBphY+rkJst/gz/2Jgb1W/8I35z7P8dN7daRkvXQ=.sha256

The documentation page looks nice. The full page screenshot doesn't do justice to it because the sidebar CSS is screwed by the screenshot mechanics.

image.png

Notice that at the time of the page generation, those inteteraction commands are executed and their output is captured and interpolated into the docs. Those are not hardcoded results, they are real results.

I copied a trick from another repo that allows me to record the network interaction and replay it, so that generating the page again doesn't need to fetch those resources unless a environment variable is set. A useful feature that is friendlier to CI/CD setups. You don't want your docs making arbitrary network requests.

Join Scuttlebutt now