DEV Community: webbureaucrat

Finding a Successful Build of NodeJS in Nixpkgs

webbureaucrat — Thu, 31 Jul 2025 00:00:00 +0000

My latest irritation has been using NodeJS with Nix. Unfortunately, I've had a few unfortunate draws pulling versions of nixpkgs that build the entire NodeJS V8 runtime from source. It's been a pain and I would like to not go through that any more, so I am documenting the steps to avoid it.

It's not you; it's Node.

If you find yourself building NodeJS from source on nix, you can console yourself that at least you didn't really do anything wrong--this is an issue with the NodeJS packages being very flaky on Hydra these days. The builds are often failing when nixpkgs gets built, and that failure gets passed onto you.

So the goal is to find a version of nixpkgs that has the version of NodeJS you want and successfully built that version in Hydra.

Let's begin.

Steps to finding a successfully pre-built NodeJS version from Nix's Hydra

Identify the NodeJS version you want to use using the nixpkgs search site. For this example, I will be using nodejs_24 because it is the most recent version of NodeJS available at the time of this article.
Identify your system platform by running

nix-instantiate --eval --expr 'builtins.currentSystem'

For this example, I will be using my own system, "x86_64-linux".

Search for your NodeJS package on Hydra. For example, these are my search results when I search for "nodejs_24".
Locate the proper job in the search results to see the builds for that job.

And now we can see the problem. At the time of this article, I can see that the nodejs_24 package is failing to build with alarming regularity.

Now we can click on one of these succeeding builds and then along the top bar click on "Inputs". Now we can see the revision we need to select for our nixpkgs property in our Nix expression.

And we're done. I hope this article saves someone some searching, and I hope NodeJS gets a little more reliable. Thank you for reading.

Building a Directory with `buildNpmPackage` in a Nix Derivation

webbureaucrat — Sun, 09 Mar 2025 00:00:00 +0000

Candidly, I'm very surprised it seems like no one has written this article yet, but I looked and it seems like no one has. The question I set out to answer is how to use a Nix derivation to build an npm package where the build product is not a single "bin" executable file but rather a directory.

Surely, this is a wildly common use cases in JavaScript, right? People compile TypeScript projects into directories all the time. (I prefer ReScript, but it's much the same.) Surely, not everyone uses a script bundler, right? (Please don't disillusion me!)

But I had more trouble with this than I expected. Fortunately, the Nix community is excellent, and @BryanBennett@tilde.zone on Mastodon gave me the answer.

For my setup, I'm building a public/ directory using an npm "build" script set to npx eleventy. This builds the static website.

This is my derivative:

mysite.nix

{ buildNpmPackage, lib }:
let
  fs = lib.fileset;
  sourceFiles = fs.gitTracked ./.;
in
buildNpmPackage rec {
  npmDepsHash = "sha256-+4lLBQ+UQ2XT0wwE6jADxG1UNZjLkQCLvvN1SdiUwZY=";
  pname = "mysite";
  src = fs.toSource {
    root = ./.;
    fileset = sourceFiles;
  };
  postInstall = ''
cp -rv public/ $out
'';
  version = "0.0.1";
}

The key here of course is the postInstall script. The folder is there for us and we just have to go get it.

(For completeness, if you're a beginner wondering how I got the npmDepsHash, a good trick is just to leave the string empty so that the error message you get tells you what the string should be. The rest of this should look at least somewhat intuitive even if the Nix syntax terrifies you as much as it does me.)

There's no magic in the default.nix, here. Just pass in some packages and reference mysite.nix.

default.nix

let
  # nixpkgs-24.11-darwin
  # 2025-03-01
  nixpkgs = fetchTarball "https://github.com/NixOS/nixpkgs/archive/26a98b6560fe0526b324d76619ffc55e61b4625e.tar.gz";
  pkgs = import nixpkgs { config = {}; overlays = []; };
in
{
  mysite = pkgs.callPackage ./mysite.nix { };
}

And that's really all there is to it! Nix is often criticized for not having good documentation, so I figure every example of someone doing something in Nix is bound to help the community a little.

The Ten Commandments of Writing Programming Tutorials

webbureaucrat — Fri, 21 Feb 2025 00:00:00 +0000

Writing programming tutorials has made me better appreciate the pitfalls of writing. It's also made me that much more aware of badly written tutorials. Whereas before I might have just called myself stupid for not understanding something, I can now clearly see what the writer did wrong and how the information could have been presented better. Anyway, I'm tired of reading badly written tutorials and hope to start better conversations about tutorials, so, without further ado and in no particular order: the Decalogue:

Name things descriptively.

It shouldn't come as a shock that the things that are good practices in writing production code are good practices in writing tutorial code, but too often I see foo and bar used as placeholders.

Here's the thing: the whole reason people read tutorials is because they don't know how to do something themselves. If they had a pretty good idea what you were going to say, they wouldn't have bothered. This is what separates tutorial code from production code. This is why readability is so important.

Now, it also doesn't come as a shock that naming things is hard, and it's especially hard in generalized articles that can be applied to a lot of different contexts. My advice is to pick an example context, so rather than calling your classes SuperClass and SubClass, for example, useAnimal and Dog. Or even better, make a generalized and specific implementation so your readers can grok the concept as well as how it is applied in the real world.

Annotate types always.

Example code is not the place to show off how smart your type inferencing system is. You should assume the person reading your writing isn't familiar with the libraries you're using, and that means they're going to have to look up all the types, so it's going to be a lot easier for your reader to grok your code if you go ahead and put your types inline. Most importantly, your reader isn't reading your code in an IDE; they're reading it on a webpage, so they can't just mouse over your object to see the type definition.

Now, I hear you: it's true that not all languages support type annotations, but that doesn't make them unimportant. You can still annotate types in comments. That may not be an idiomatic way to use comments in a given language, and that's okay! Tutorial code doesn't have to be strictly idiomatic. It's more important to be skimmable to a beginner than idiomatic.

Keep code in a working state.

This rule can be bent a little if done thoughtfully. If there's some specific common pitfall you want the reader to see, it's okay to briefly show what's going to cause an error (although the case could be made that that should usually be broken out into its own article).

What you should avoid, though, is something like "Start with a main function that calls these three functions, and then let's spend the next several pages implementing those three functions." If you're not yet ready to write the main function, don't confuse readers by having them write it.

Instead, whenever possible, keep code in a state that compiles and, if possible, runs. That way, the reader always knows when they're on the right track and when they've gone astray.

Avoid summarizing code.

Writing code snippets can be tempting, but, whenever possible, include entire code files instead of snippets unless what you're showing is completely trivial.

I do understand the temptation. It's easy to think, for example, that the reader will be annoyed if they have to scroll past all the imports and boilerplate to see what you're trying to show, but think how much worse the reverse is: if there's something in the imports or boilerplate that they feel like they'd like to see, it's not just a matter of a little extra scrolling--they're stuck. There's no way around.

If you do like to summarize code or show just one snippet at a time, there's a good solution: summarize code in the article, but include a link to a fully-functioning repository. That way, the user can see how all the parts fully fit together.

Highlight syntax.

Did you know implementations of markdown usually support highlighting syntax? You do now. Simply enclose your code in three backticks and include the language annotation next to the first set like so:

```typescript 
function thisHas(syntax: Highlighting) { } 
```

Please don't make anyone read code without sytax highlighting!

Write descriptive headings.

Descriptive headings contribute greatly to search engine optimization. You owe it to yourself, your readers, and those hard-working web crawlers to put some thought into how you want your headings to read.

It's not a bad idea to use your headings to reiterate some contextualizing information like the language or tech stack your using or the problem you're trying to solve. For example, instead of, "Recursive queries," try "Recursive T-SQL queries with Common Table Expressions (CTEs) in SQL Server." The latter is a mouthful and maybe a little redundant, but the extra search keywords will help your readers find you.

Use images where appropriate.

Rule of thumb: if you're talking about menus, go ahead and include a screencap of the menu. In particular, I am thinking of .NET development in Visual Studio, which is famously menu-driven development.

The reverse is just as important: never use images to display code. To do so is inaccessible to screenreader users and just plain obnoxious to everyone else.

Distinguish between compiler and runtime errors.

"Compile and run" feels so natural in a lot of languages. Lots of editors have a "Build & Run" button and lots of CLI tools have some equivalent, and this is great for day-to-day editing, but I recommend avoiding using it to demonstrate compiler errors. For example, don't advise the user to cargo run a codebase where they're expected to get a compilation error. Tell them to cargo checkthe code instead.

I say this because lots of beginners struggle with the difference between compile-time and runtime errors. Getting in the habit of using a separate compilation step will help them get over the hurdle faster.

Include the full message when describing errors.

A lot of writers will just say, "X will produce a runtime error" or "Y will generate a compiler error." I highly encourage you to specify the exact wording of the error generated--maybe even a partial stack trace. Doing so will help the reader understand the error without having to reproduce it themselves, and it has the added benefit of helping your readers find your article through search engines because users are likely to be searching for specific errors.

Import everything explicitly.

Every language I'm aware of has some form of

Python

from my_module import *

Rust

use crate::my_module::*;

and depending on your preferences and the conventions of your language, you may do something like that all the time. (I do not.)

But remember, in your day to day you have access to an IDE where you can mouse over things to tell where they came from and flip to a construct's definition with a couple of keystrokes. Your readers don't have that, unless you really expect them to have to follow along with every line in order to be able to use your tutorial.

So even though it makes for a few extra lines and a little extra scrolling, make all your imports explicit.

Epilogue

I know I'm bloviating, but I do hope you've found this useful as a checklist for your own writing, or maybe just knowing how to spot a difficult-to-follow tutorial will inspire you to keep going and find better resources when you get frustrated.

And of course I am not perfect. Be sure to open issues on my own blog when you've found one that's really bad!

When I was a junior dev I'd look at some problems and think "This is hard because I'm not very good at this and need to get better" and now I look at a lot of those same problems and think, "This is hard because this is badly-designed garbage."

webbureaucrat — Tue, 14 Jan 2025 21:46:45 +0000

Emacs for Python and Poetry Using `basedpyright-langserver`

webbureaucrat — Sun, 06 Oct 2024 00:00:00 +0000

I am very pleased with my current emacs setup for Python, but I found setup to be a little tricky. I will document my setup here for my future self and for any other Pythonistas looking for a solid emacs config.

Why basedpyright?

Up to this point, I've been using mypy --strict on the command line for all my typechecking needs, but mypy is quite slow even for very small codebases, and even in --strict mode it is just not as strict as it could be. It's also not a language server, which I want for my emacs setup.

basedpyright is a fork of pyright with some excellent improvements in both checking and in reliability. It is a fast and wonderfully strict typechecker with some good linting capabilities additionally.

The only drawbacks I am experiencing are that it doesn't play quite as nicely as mypy with the boto3-stubs clients for AWS and that it uses nonstandard # pyright: ignore comments instead of the standard # type: ignore comments, but I can live with those issues in favor of a rigorously strict type-checking experience.

Configuring your Poetry projects to work with basedpyright or pyright

If you have existing projects that use Poetry, you're going to want to fiddle a little with your virtual environment.

Go to the root of each of your projects and run the following command:

poetry config --local virtualenvs.in-project true

This will create a poetry.toml file if one does not already exist and add a corresponding setting.

This, however, will not actually move your existing virtual environment. In order for this change to take effect, you have to remove your existing virtual environment, which you can find by running

poetry env info --path

Don't forget to add the .venv path to your .gitignore and the configuration for any other tools you might use, like pycodestyle, or you'll end up with quite a mess.

Next, you should add a configuration section to your pyproject.toml to tell basedpyright where to look for your virtual environment.

[tool.pyright]
venv=".venv"
venvPath="."

You can also do this in pyrightconfig.json file if, unlike me, you do not already feel completely overrun with config files for different Python development tools.

Installing basedpyright as a language server

One very nice thing about basedpyright over pyright is that it builds the nodejs dependency as a wheel, so you can be assured that basedpyright should work on your machine regardless of whether you have nodejs installed.

For isolation, it is usually a good idea to install executable Python packages using pipx instead of pip. Let's go ahead and do that .

pipx install basedpyright

For a sanity check, consider running

basedpyright --version

Installing basedpyright also gives you access to thebasedpyright-langserver command, but that's not really written for users to interact with, so if you runbasedpyright-langserver orbasedpyright-langserver --version or something, you'll get a nodejs stack trace.

Configuring emacs to use `basedpyright-langserver`

I'll assume you as the reader know how to install packages from MELPA and have a preferred way to do it. Here are all the packages you need:

company
lsp-mode
lsp-pyright
lsp-ui
python-mode

Get those installed and then open your ~/.emacs or your ~/.emacs.d/init.el and add the following:

;; lsp global settings
(add-hook 'after-init-hook 'global-company-mode)
(setq lsp-auto-guess-root t)

;; python
(require 'lsp-mode)
(setq lsp-pyright-langserver-command "basedpyright")
(add-hook 'python-mode-hook (lambda () (require 'lsp-pyright) (lsp)))

That should be all you need.

A general tip for debugging lsp-mode

If you feel like you've set everything up correctly and you're still having trouble getting lsp-mode to find packages that should be available in Poetry, one thing you might try is to go in and delete your ~/.emacs.d/.lsp-session-v1. This will have the effect of causing lsp-mode to forget about the project root and force it to look for it again.

Happy coding!

I hope this has given you a good head start on your Python development environment. If you have any questions, well, I'm a beginner with all this, and I probably can't help you, but I will consider merge requests if you have any extra tips or tricks for using basedpyright with emacs.

A Font Family Choice for Pragmatism and Disability Allyship

webbureaucrat — Mon, 30 Sep 2024 00:00:00 +0000

A side note for Dev.to readers: if you want to see this font in action, read this article instead in my blog

There's no need for this to be a full length article, but I've had a couple occasions recently to evangelize my favorite non-monospace font, and it occurs to me this might be a good time to collect and share my thoughts about the font choice I've made for my blog.

Atkinson Hyperlegible is font choice for disability allyship

All of the text in my blog (except for the code blocks) is Atkinson Hyperlegible. The linked page has an excellent and brief rundown of what makes this font special. Rather than reiterate all those points here, I would encourage you to take just about sixty seconds to scroll the linked page and return to this article if you'd like.

The long and the short of it is that Atkinson Hyperlegible is a very thoughtfully designed font from the standpoint of readability and low-vision accessibility.

Atkinson Hyperlegible is a font choice for any pragmatist

Look, occasionally in technology you come across a good decision with no tradeoffs, only benefits, and nowhere is that more clear than in the world of disability access on the web. Sometimes sighted people connect from a crumby internet connection and the images don't load, and in those moments, sighted people really appreciate your alt text on images, for example. Proper headings and other best practices for semantic markup help enable navigation for screen reader users, but they also improve your search ranking!

This is another example of that. Every user who is at all sighted benefits from a more legible font choice, myself very much included.

I am not a designer, as anyone looking at my website will tell you. I'm technically competent on the frontend, but I am a backend woman, and that's where I belong.

But I'm also a user, and, in that sense, my preferences are as valid as anyone else's, and as a sighted user I have to say I am extremely bleeding tired of not being able to tell the difference between l, 1, and I. This year especially, I'm sure I'm not the only person who is tired of accidentally parsing "AI" as "Al" and vice versa. May as well add some A1 sauce because I am cooked switching back and forth between news stories about generative AI and the Al Smith Dinner.

Atkinson Hyperlegible may be a font choice for you

I hope to see Atkinson Hyperlegible used more widely, both because I want my low-vision neighbors to be able to enjoy the same content I can and because I benefit from Atkinson Hyperlegible, too.

So I hope you'll consider using Atkinson Hyperlegible or even consider opening issues on your favorite projects recommending Atkinson Hyperlegible as an option. If not--if it's just not your cup of tea--I hope you've at least enjoyed learning a bit of trivia about a unique font that makes interesting choices.

Iced for Desktop Development in Rust

webbureaucrat — Mon, 25 Sep 2023 00:00:00 +0000

As someone who loves Elm and has recently fallen in love with Rust, I was delighted to learn there are not just one but two Rust frameworks modeled on the Elm Architecture. If you're not familiar, the Elm Architecture is a pain-free way of developing fast, responsive, asynchronous-by-default front-ends. Let's see it in action by developing a simple "Hello, world" app.

Note: I'm using iced version 0.10.0. Iced is currently under rapid development with frequent breaking changes. It's possible these directions won't work as expected in a future release. As always, if something breaks, open an issue or submit a pull request.

Setup

Let's start with a fresh application:

cargo init hello-iced
cd hello-iced
cargo add iced
cargo build

If the build succeeds, we're off to a good start.

Writing a State Model for Iced in Rust

The easiest part of the Elm Architecture to understand is the model state, so let's start there. The model state represents the whole state of the application--everything you would need to know in order to draw any given application screen. As you can imagine, state models are often quite large, but our application will need only one piece of information: whom to greet (by default: the world). That's easy.

struct Hello{ 
    addressee: String
}

Writing a Message Enum for Iced in Rust

Next, we need our Message. A message is an enum that represents all the ways that our model can update according to the logic of our application. For example, you might have a counter that can increment or a counter that can either increment and decrement, or a counter that can increment, decrement, or reset, all depending on the logic of your application.

In our case, we only have one field in our model struct, and it can only be updated through a text input, so let's write an enum to that effect:

#[derive(Clone, Debug)]
enum HelloMessage { 
    TextBoxChange(String)
}

We can see that our enum takes a String. This represents the new string to which we will update our model. Also note that it derives Clone and Debug. This is required by the framework.

Implementing `iced::Application`

Now the real work begins: turning our model into an Iced Application. Let's begin:

struct Hello { 
    addressee: String,
} 

#[derive(Clone, Debug)]
enum HelloMessage { 
    TextBoxChange(String)
}

impl iced::Application for Hello {}

We need four types for our application.

Executor - The only type provided by the framework is Default, which will suffice for our purposes.
Flags - represents any data we want to initialize our application. We have no flags to pass, so the unit type will suffice.
Message - this is the HelloMessage we defined earlier.
Theme - the theme of the application.

struct Hello {
    addressee: String,
}

#[derive(Clone, Debug)]
enum HelloMessage {
    TextBoxChange(String)
}

impl iced::Application for Hello {
    type Executor = iced::executor::Default;
    type Flags = ();
    type Message = HelloMessage;
    type Theme = iced::Theme;

}

Next we need a function that initializes our model. Our model will default to greeting, well, the world.

Start by adding use iced::Command; at the top. A command is an asynchronous action that the framework will take on next. We don't need to start any commands on startup, so we'll initialize with Command::none().

impl iced::Application for Hello {
    type Executor = iced::executor::Default;
    type Flags = ();
    type Message = HelloMessage;
    type Theme = iced::Theme;

    fn new(_flags: ()) -> (Hello, Command<Self::Message>) {
        ( Hello { addressee: String::from("world"), }, Command::none() )
    }

We also need a function which takes the &self state model and returns a title for the title bar at the top of the application.

impl iced::Application for Hello {
    type Executor = iced::executor::Default;
    type Flags = ();
    type Message = HelloMessage;
    type Theme = iced::Theme;

    fn new(_flags: ()) -> (Hello, Command<Self::Message>) {
        ( Hello { addressee: String::from("world"), }, Command::none() )
    }

    fn title(&self) -> String {
        String::from("Greet the World")
    }
}

Now we're getting to the real meat of the application: the update and viewfunctions.

The update function takes our state model and mutates it based on the given message. It also gives us the opportunity to start another Command after mutating our state. For example, a common use case for a submit action message is to change part of the state to represent that the state is "Loading..." and then to start a command to fetch some data based on the submission. We only have one kind of message, so our update function will be very simple.

fn update(&mut self, message: Self::Message) -> Command<Self::Message> {
    match message {
        HelloMessage::TextBoxChange(string) => {
        self.addressee = string;
        Command::none()
        }
    }
}

Finally, we can write our view. Let's start by useing some relevant parts.

use iced::{Command, Element, Length, Renderer, Settings};
use iced::widget::{Column, Row, Text};

We build out our view programmatically using thepush method, and then convert the final result to an Element usinginto().

fn view(&self) -> Element<Self::Message> {
    let text = Text::new(format!("Hello, {0}.", self.addressee))
            .width(Length::Fill)
            .horizontal_alignment(iced::alignment::Horizontal::Center);
    let row1 = Row::new().push(text);
    let text_input: iced::widget::TextInput<'_, HelloMessage, Renderer> =
        iced::widget::text_input("world", self.addressee.as_str())
        .on_input(HelloMessage::TextBoxChange);
    let row2 = Row::new().push(text_input);
    Column::new().push(row1).push(row2).into()
    }

Writing a `main` function to `run` an Iced `Application`

Finally, we need to run our application from the main function. Make sure to use iced::Application to bring the run function into scope.

use iced::{Application, Command, Element, Length, Renderer, Settings};
use iced::widget::{Column, Row, Text};

pub fn main() -> iced::Result { 
    Hello::run(Settings::default())
}

Wrapping up

In conclusion, I hope this has been a helpful introduction to the Iced framework and the Elm Architecture. The architecture has a learning curve, so I figure the more learning resources out there, the better.

For reference, this is the full source code:

src/main.rs

use iced::{Application, Command, Element, Length, Renderer, Settings};
use iced::widget::{Column, Row, Text};

pub fn main() -> iced::Result {
    Hello::run(Settings::default())
}

struct Hello {
    addressee: String,
}

#[derive(Clone, Debug)]
enum HelloMessage {
    TextBoxChange(String)
}

impl iced::Application for Hello {
    type Executor = iced::executor::Default;
    type Flags = ();
    type Message = HelloMessage;
    type Theme = iced::Theme;

    fn new(_flags: ()) -> (Hello, Command<Self::Message>) {
        ( Hello { addressee: String::from("world"), }, Command::none() )
    }

    fn title(&self) -> String {
        String::from("Greet the World")
    }

    fn update(&mut self, message: Self::Message) -> Command<Self::Message> {
    match message {
        HelloMessage::TextBoxChange(string) => {
        self.addressee = string;
        Command::none()
        }
    }
    }

    fn view(&self) -> Element<Self::Message> {
    let text = Text::new(format!("Hello, {0}.", self.addressee))
            .width(Length::Fill)
            .horizontal_alignment(iced::alignment::Horizontal::Center);
    let row1 = Row::new().push(text);
    let text_input: iced::widget::TextInput<'_, HelloMessage, Renderer> =
        iced::widget::text_input("world", self.addressee.as_str())
        .on_input(HelloMessage::TextBoxChange);
    let row2 = Row::new().push(text_input);
    Column::new().push(row1).push(row2).into()
    }
}

Setting and Reading Session Cookies in Rust with Actix Web

webbureaucrat — Mon, 17 Jul 2023 00:00:00 +0000

In case it's not readily apparent, I've been having some trouble picking a backend stack recently, but, at the risk of jinxing it, I really think Rust is the backend for me, and Actix Web is a blindingly fast MVC framework for Rust with an elegant and functional middleware system. As with all web apps, my first challenge is persisting and managing state between requests, so let's get into user session management in Actix Web.

Starting with Hello World in Rust with Actix Web

For completeness, I'm going to start with cargo new. Feel free to skip ahead.

You can start with cargo new actix-kata.

If you enter your directory, you should find a "Hello, world" program. If youcargo run it, you should get "Hello, world" printed to the screen.

To add Actix Web to your project, run cargo add actix-web. If you cargo build or cargo run again, it should install Actix Web and all its dependencies.

Then replace src/main.rs with the following:

use actix_web;

#[actix_web::get("/")]
async fn index() -> impl actix_web::Responder {
    actix_web::HttpResponse::Ok().body("Hello, world")
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    actix_web::HttpServer::new( || {
    actix_web::App::new()
        .service(index)
    })
    .bind(("127.0.0.1", 3000))?
    .run()
    .await
}

Getting started with `actix-session`

actix-session is it's own Rust crate, separate from actix-web. It has a feature flag for cookie sessions. To use it, install it with cargo add actix-session --features cookie-session.

Our goal will be to build out a SessionMiddleware<CookieSessionStore>. We can do that with aSessionMiddlewareBuilder. To put a fine point on it, let's break it out into its own function.

use actix_session::{ SessionMiddleware };
use actix_session::storage::{ CookieSessionStore };
use actix_web;
use actix_web::cookie::{ Key };

#[actix_web::get("/")]
async fn index() -> impl actix_web::Responder {
    actix_web::HttpResponse::Ok().body("Hello, world")
}

fn session_middleware() -> SessionMiddleware<CookieSessionStore> {
    SessionMiddleware::builder(
        CookieSessionStore::default(), Key::from(&[0; 64])
    )
    .build()
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    actix_web::HttpServer::new( || {
    actix_web::App::new()
        .wrap(session_middleware()) //register session middleware
        .service(index)
    })
    .bind(("127.0.0.1", 3000))?
    .run()
    .await
}

This accepts all defaults and registers the session middleware in the application.

Building out a cookie session in Actix Web

Now let's fill in some details using the provided builder methods. (Some of these are set by default, but in the interest of a good demonstration, let's make as much explicit as we can.)

Importantly, many possible configuration items are matters of security both for the application and for the user, so it is a very good idea to familiarize oneself with each item in the documentation.

use actix_session::{ SessionMiddleware, Session };
use actix_session::config::{ BrowserSession, CookieContentSecurity };
use actix_session::storage::{ CookieSessionStore };
use actix_web;
use actix_web::cookie::{ Key, SameSite };

#[actix_web::get("/")]
async fn index() -> impl actix_web::Responder {
    actix_web::HttpResponse::Ok().body("Hello, world")
}

fn session_middleware() -> SessionMiddleware<CookieSessionStore> {
    SessionMiddleware::builder(
        CookieSessionStore::default(), Key::from(&[0; 64])
    )
    .cookie_name(String::from("my-kata-cookie")) // arbitrary name
    .cookie_secure(true) // https only
    .session_lifecycle(BrowserSession::default()) // expire at end of session
    .cookie_same_site(SameSite::Strict) 
    .cookie_content_security(CookieContentSecurity::Private) // encrypt
    .cookie_http_only(true) // disallow scripts from reading
    .build()
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    actix_web::HttpServer::new( || {
    actix_web::App::new()
        .wrap(session_middleware())
        .service(index)
    })
    .bind(("127.0.0.1", 3000))?
    .run()
    .await
}

Reading from a cookie in Actix Web

Reading from and writing to cookies is very simple with the Sessionextractor. Just include a parameter typed as Session, and the framework will take care of the rest.

use actix_session::{ SessionMiddleware, Session };
use actix_session::config::{ BrowserSession, CookieContentSecurity };
use actix_session::storage::{ CookieSessionStore };
use actix_web::{ HttpResponse };
use actix_web::cookie::{ Key, SameSite };
use actix_web::web::{ Json };

#[actix_web::get("get_session")]
async fn get_session(session: Session) -> impl actix_web::Responder {
    match session.get::<String>("message") {
    Ok(message_option) => {
        match message_option {
        Some(message) => HttpResponse::Ok().body(message),
        None => HttpResponse::NotFound().body("Not set.")
        }
    }
    Err(_) => HttpResponse::InternalServerError().body("Session error.")
    }
}

#[actix_web::get("/")]
async fn index() -> impl actix_web::Responder {
    HttpResponse::Ok().body("Hello, world")
}

fn session_middleware() -> SessionMiddleware<CookieSessionStore> {
    SessionMiddleware::builder(
        CookieSessionStore::default(), Key::from(&[0; 64])
    )
    .cookie_name(String::from("my-kata-cookie"))
    .cookie_secure(true)
    .session_lifecycle(BrowserSession::default())
    .cookie_same_site(SameSite::Strict)
    .cookie_content_security(CookieContentSecurity::Private)
    .cookie_http_only(true)
    .build()
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    actix_web::HttpServer::new( || {
    actix_web::App::new()
        .wrap(session_middleware())
        .service(index)
        .service(get_session)
    })
    .bind(("127.0.0.1", 3000))?
    .run()
    .await
}

Setting the session cookie in Actix Web

We can use serde to create an endpoint to set the session. We'll also need the derive feature.

cargo add serde --features derive

At this point, your Cargo.toml should look like this:

[package]
name = "actix-kata"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
actix-session = { version = "0.7.2", features = ["cookie-session"] }
actix-web = "4.3.1"
serde = { version = "1.0.164", features = ["derive"] }

With serde, we can make a deserializable struct to model our input and then extract it simply by putting it in the signature of our method. The framework will handle the rest.

Then we can insert the message using session.insert.

main.rs

use actix_session::{ SessionMiddleware, Session };
use actix_session::config::{ BrowserSession, CookieContentSecurity };
use actix_session::storage::{ CookieSessionStore };
use actix_web::{ HttpResponse };
use actix_web::cookie::{ Key, SameSite };
use actix_web::web::{ Json };
use serde;

#[derive(serde::Deserialize)]
struct CookieModel {
    message: String
}

#[actix_web::get("get_session")]
async fn get_session(session: Session) -> impl actix_web::Responder {
    match session.get::<String>("message") {
    Ok(message_option) => {
        match message_option {
        Some(message) => HttpResponse::Ok().body(message),
        None => HttpResponse::NotFound().body("Not set.")
        }
    }
    Err(_) => HttpResponse::InternalServerError().body("Error.")
    }
}

#[actix_web::get("/")]
async fn index() -> impl actix_web::Responder {
    HttpResponse::Ok().body("Hello, world")
}

async fn set_session(session: Session, model: Json<CookieModel>)
                     -> impl actix_web::Responder
{
    match session.insert("message", model.message.clone()) {
        Ok(_) => HttpResponse::Created().body("Created."),
        Err(_) => HttpResponse::InternalServerError().body("Error.")
    }
}

fn session_middleware() -> SessionMiddleware<CookieSessionStore> {
    SessionMiddleware::builder(
        CookieSessionStore::default(), Key::from(&[0; 64])
    )
    .cookie_name(String::from("my-kata-cookie"))
    .cookie_secure(true)
    .session_lifecycle(BrowserSession::default())
    .cookie_same_site(SameSite::Strict)
    .cookie_content_security(CookieContentSecurity::Private)
    .cookie_http_only(true)
    .build()
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    actix_web::HttpServer::new( || {
    actix_web::App::new()
        .wrap(session_middleware())
        .service(index)
        .service(get_session)
        .route("set_session", actix_web::web::post().to(set_session))
    })
    .bind(("127.0.0.1", 3000))?
    .run()
    .await
}

Wrapping up

And that's really it. Make sure you set your mime type for the /set_session request to application/json if you're testing. This has been helpful to me as I get into Actix Web middleware for the first time, so I hope it has been helpful to you.

Writing a (Nix-Friendly) Hello World Web App in Haskell with Scotty

webbureaucrat — Mon, 10 Jul 2023 00:00:00 +0000

Okay, so this article has been written before, and I don't have a lot new to add, but some of these tutorials are getting pretty old, and the ones that aren't use stack, which I personally am avoiding as it doesn't play well with NixOS, so at least for me, for future reference, this tutorial will be useful.

Prerequisites for Haskell and Scotty

The first thing we need is a working development environment. I recommend Nix for this because I've fallen in love with the reproducibility of Nix scripts. Using Nix, we can download and run packages on the fly without messing with the rest of our system. Whether we're using nix or not, we needcabal-install, ghc, git, and zlib.

(A couple of those are not strictly intuitive, which is one reason why I'm writing this tutorial. git is required for cabal-install to work properly, and zlib is a dependency of Scotty.)

In Nix, we can simply start a new environment with

nix-shell --packages bash cabal-install ghc git zlib

Initializing a Hello World App in Haskell with `cabal`

We can initialize a new web app in Haskell with cabal init. I won't go through all the steps because the defaults are generally very sensible.

mkdir webcd webcabal init

For completeness, here's my sample .cabal file:

cabal-version:      3.0
-- The cabal-version field refers to the version of the .cabal specification,
-- and can be different from the cabal-install (the tool) version and the
-- Cabal (the library) version you are using. As such, the Cabal (the library)
-- version used must be equal or greater than the version stated in this field.
-- Starting from the specification version 2.2, the cabal-version field must be
-- the first thing in the cabal file.

-- Initial package description 'web' generated by
-- 'cabal init'. For further documentation, see:
--   http://haskell.org/cabal/users-guide/
--
-- The name of the package.
name:               web

-- The package version.
-- See the Haskell package versioning policy (PVP) for standards
-- guiding when and how versions should be incremented.
-- https://pvp.haskell.org
-- PVP summary:     +-+------- breaking API changes
--                  | | +----- non-breaking API additions
--                  | | | +--- code changes with no API change
version:            0.1.0.0

-- A short (one-line) description of the package.
-- synopsis:

-- A longer description of the package.
-- description:

-- The license under which the package is released.
license:            GPL-3.0-or-later

-- The file containing the license text.
license-file:       LICENSE

-- The package author(s).
author:             eleanorofs

-- An email address to which users can send suggestions, bug reports, and patches.
maintainer:         lu80mmgmt5nm@blurmail.net

-- A copyright notice.
-- copyright:
category:           Web
build-type:         Simple

-- Extra doc files to be distributed with the package, such as a CHANGELOG or a README.
extra-doc-files:    CHANGELOG.md

-- Extra source files to be distributed with the package, such as examples, or a tutorial module.
-- extra-source-files:

common warnings
    ghc-options: -Wall

executable web
    -- Import common warning flags.
    import:           warnings

    -- .hs or .lhs file containing the Main module.
    main-is:          Main.hs

    -- Modules included in this executable, other than Main.
    -- other-modules:

    -- LANGUAGE extensions used by modules in this package.
    -- other-extensions:

    -- Other library packages from which modules are imported.
    build-depends:    base ^>=4.15.1.0

    -- Directories containing source files.
    hs-source-dirs:   app

    -- Base language which the package is written in.
    default-language: Haskell2010

To ensure your project is created properly, run:

cabal update && cabal run

You should see "Hello Haskell" printed in addition to some other output.

Adding Scotty to your Haskell project

To make Scotty available for import, add it as a build dependency in your_.cabal_ file.

-- Other library packages from which modules are imported.
build-depends: base ^>=4.15.1.0, scotty

You can test that your .cabal file is correct by going ahead and importingWeb.Scotty into your app/Main.hs file and running again with the command above.

app/Main.hs

module Main where
import qualified Web.Scotty
main :: IO ()
main = putStrLn "Hello, Haskell!"

If your app compiles and runs successfully, you know you're ready to start writing code with Scotty.

Writing a "Hello, world" action in Scotty

In order to use Scotty (with reasonable developer ergonomics), you'll want the OverloadedStrings language extension. This allows string literals to be used as other string-like objects when appropriate.

Once you have OverloadedStrings, you can write a Scotty ActionM action for greeting the world.

{-# LANGUAGE OverloadedStrings #-}
module Main where
import qualified Web.Scotty

homeAction :: Web.Scotty.ActionM ()
homeAction = Web.Scotty.html "<h1>Hello, world</h1>"

ActionMs are monads, which means technically we can write our action as ado block like this:

app/Main.hs

{-# LANGUAGE OverloadedStrings #-}
module Main where
import qualified Web.Scotty

homeAction :: Web.Scotty.ActionM ()
homeAction = do Web.Scotty.html "<h1>Hello, world</h1>"

...although this may look ugly for trivial examples like the one shown here.

Specifying a port and running a server in Scotty

Finally, we're ready to create our server. This example uses port 3000.

{-# LANGUAGE OverloadedStrings #-}

module Main where
import qualified Web.Scotty
homeAction :: Web.Scotty.ActionM ()
homeAction = do Web.Scotty.html "<h1>Hello, world</h1>"

main :: IO ()
main = do Web.Scotty.scotty 3000 $ 
    do Web.Scotty.get "/" $ 
        do homeAction

When you run this with cabal run, you should be able to see your server running at http://localhost:3000/.

In conclusion

Whether you use Nix or not, I hope this has been helpful to people getting started with Scotty.

Running and Connecting to Postgres Using Docker Compose

webbureaucrat — Thu, 15 Jun 2023 00:00:00 +0000

Setting up a new development environment from scratch can feel like a slog. This is a quick copy-paste recipe for getting up and running quickly with Postgres in docker compose.

Start with a .env file

At the very least, we know we will need a POSTGRES_PASSWORD environment variable, and our .env file doesn't rely on any other files, so it's a good place to start.

I personally am not crazy about hiding files by beginning them with periods, so I'm going to call my file database.env.

database.env

POSTGRES_USER=postgres_user
POSTGRES_PASSWORD=postgres_password
POSTGRES_DB=postgres_database

It goes without saying, but this is for local development. Sensitive information for any database you intend to stand up for a while should be treated better than this. Use stronger passwords, and don't publish them in a blog post on the Internet, etc., etc.

Create database scripts

This section is more or less the "Draw the rest of the owl" portion of this article. The idea here is to create whatever database scripts--tables, stored procedures, etc--in ./database/docker-entrypoint-initdb.d. Any .sql or compressed .sql file in this folder will be run by the database at startup. (Other file extensions are supported. See the official documentation for more.)

Create a docker-compose.yml file

Now we're ready to get started with our docker compose file. There's no magic here--we're just exposing our ports, referencing our database.env file, and feeding in our scripts from our scripts directory.

docker-compose.yml

version: "3.8"
services:
  database:
    env_file: "database.env"
    image: postgres:latest
    ports:
      - "5432:5432"
    volumes:
     - ./database/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d

You should now be able to run this with docker compose up.

Connecting to a locally-running Postgres container

With that compose file running, we can connect via SSH like so:

docker compose exec database bash

Note that "database" is the identifier chosen in the docker-compose.yml.

Lastly, we can run psql from within the container to run commands directly inside the container. Use the values from your database.env file.

psql --dbname postgres_database --host localhost --username postgres_user

This can be shortened to:

psql -d postgres_database -h localhost -U postgres_user

From here, you can run Postgres queries against your database.

Wrapping up

Starting with a blank sheet of paper can be kind of daunting, so writing (and having) basic tutorials like this to lay out some basic first steps to be a good motivational and organizational tool. I hope this has been helpful.

Idris FizzBuzz Part IV: Main and .ipkg Files

webbureaucrat — Fri, 19 May 2023 00:00:00 +0000

This is the fourth and final part of a walkthrough of FizzBuzz, a common interview problem, in Idris. If you haven't read the other parts, you can start with Part I. To show how to import and use libraries, we're going to divide this project into a library and an executable. Along the way, we will create .ipkg packages for both.

Idris .ipkg files for libraries

Start by running idris2 --init in the fizzbuzz project and fill in some sensible defaults. This is what I ended up with:

fizzbuzz.ipkg

package fizzbuzz

authors = "eleanorofs"
brief = "a fizzbuzz example in the Idris language."
bugtracker = "https://gitlab.com/eleanorofs/idris-fizzbuzz/-/issues"
-- packages to add to search path
-- depends =
-- name of executable
-- executable =
homepage = "https://gitlab.com/eleanorofs/idris-fizzbuzz"
license = "MIT"
-- main file (i.e. file to load at REPL)
-- main =
maintainers = "eleanorofs"
-- modules to install
modules = Division, FizzBuzz
opts = "--warnpartial"
readme = "./README.md"
sourcedir = "src"
sourceloc = "https://gitlab.com/eleanorofs/idris-fizzbuzz.git"
version = 0.0.1

The important thing here is that main and executable are not filled in because this is a library.

Writing an Idris executable

Now we can create a new Idris package for the executable. As before, let's start with the source.

Let's recall that we have a method numberToFBNString which takes a single number and returns the string FizzBuzz equivalent of the number. Now, consider how we might do that recursively for a list of numbers. One way might be to combine the numbers into a long string and then print that string, but that would result in a slow-feeling user experience for large numbers as it would take a long time to concatenate the string. Instead, let's print the numbers one at a time, using the do syntax and the IO () monad.

idris-fizzbuzz-main/src/Main.idr

module Main

import FizzBuzz

printFizzBuzz : Vect n Nat -> IO ()
printFizzBuzz Nil = putStrLn ""
printFizzBuzz (x :: xs) = 
  do putStrLn $ FizzBuzz.numberToFBNString x
     printFizzBuzz xs --recursive call on the rest of the list

Now we can write a main function which calls printFizzBuzz on a long vector, and we're done.

idris-fizzbuzz-main/src/Main.idr

module Main

import Data.Vect --imports fromList
import FizzBuzz

printFizzBuzz : Vect n Nat -> IO ()
printFizzBuzz Nil = putStrLn ""
printFizzBuzz (x :: xs) = 
  do putStrLn $ FizzBuzz.numberToFBNString x
     printFizzBuzz xs --recursive call on the rest of the list

total
main : IO ()
main = printFizzBuzz $ fromList [ 1 .. 1000 ]

Note that main is a total function! We have a strong guarantee that it will never error out.

Idris .ipkg files for executables

Now run idris2 --init again, but then change the values to an executable by including the main file and the executable name. Then, add your fizzbuzzlibrary as a dependency using depends. You should end up with something like this:

idris-fizzbuzz-main/fizzbuzz-main.ipkg

package fizzbuzz-main
authors = "eleanorofs"
brief = "prints FizzBuzz from 1 to 1000."
license = "MIT"
maintainers = "eleanorofs"
readme = "./README.md"
-- homepage = 
-- sourceloc =
-- bugtracker =

-- packages to add to search path
depends = fizzbuzz

-- modules to install
modules = Main

-- main file (i.e. file to load at REPL)
main = Main

-- name of executable
executable = "fizzbuzz-main"
opts = "--warnpartial"
sourcedir = "src"
version = 0.0.1

Compiling and running an Idris executable

With this configuration in place, we should be able to compile our executable with idris2 --build fizzbuzz-main.ipkg. This will produce a build folder. We can run the executable, then, as ./build/exec/fizzbuzz-main.

You should see, well, FizzBuzz.

If something isn't quite right, have a look at this Nix shell script which walks through all the steps needed to run this executable, including downloading and installing the previous FizzBuzz library.

#!/usr/bin/env nix-shell
#! nix-shell -i bash --pure
#! nix-shell -p bash cacert chez git idris2

mkdir dependencies
cd dependencies
git clone https://gitlab.com/eleanorofs/idris-fizzbuzz
cd idris-fizzbuzz
idris2 --build fizzbuzz.ipkg
idris2 --install fizzbuzz.ipkg
cd ../..
idris2 --build fizzbuzz-main.ipkg
./build/exec/fizzbuzz-main

(This is something I love about Nix--scripts themselves are not only perfectly reproducible but include self-documenting lists of dependencies.)

Wrapping up FizzBuzz for Idris

I hope this has been a useful introduction to Idris and its basic usage and syntax. This was a fun little project for me, and, if you're reading this, I hope to see what fun little projects you write in Idris, too.

Idris FizzBuzz Part III: Defining Types and Importing Modules

webbureaucrat — Wed, 10 May 2023 00:00:00 +0000

This is Part III of my attempt to explain how to use the Idris programming language through a tutorial on FizzBuzz, the common software development hiring interview problem. If you're new to Idris and haven't read Part I and Part II, I recommend doing that now. This article will go over defining our own types and importing our own modules as well as recap what we've learned about case-matching and basic syntax.

Just to recap, here's what we have so far:

module Division

||| Returns a `Just of the remainder of two numbers, or `Nothing` if the 
||| divisor is zero.
total
modulo : Nat -> Nat -> Maybe Nat
modulo _ Z = Nothing --can't divide by zero, so Nothing
modulo Z _ = Just 0
modulo dividend divisor = 
  if dividend >= divisor
  then modulo (assert_smaller dividend (minus dividend divisor)) divisor
  else Just dividend

||| Returns `True` if the first number divides the second evenly, otherwise 
||| returns `False`. Also returns `False` if the divisor is zero. 
total
divides : Nat -> Nat -> Bool
divides divisor dividend = 
  case dividend `modulo` divisor of 
    Nothing => False
    Just remainder => remainder == 0

We have completed our Divides module, which holds all of the basic arithmetic we need for our program, so now we get to work on FizzBuzz specific logic. Let's put that logic in a different module and call it FizzBuzz.

When we think about what we need for FizzBuzz, one of the first things we should notice is that we're classifying numbers and specifying different behavior based on their properties. In object orientation, we might define a Printable interface and have Fizz Buzz, FizzBuzz and regular Number implementations, but in Idris we can simply define a union type like so:

src/FizzBuzz.idr

module FizzBuzz

data FizzBuzzNumber = FizzBuzz | Fizz | Buzz | Number Nat

Note that Number has a Nat data member just like Just had a Nat data member in our previous article.

This is a little terse, though. We can do better.

Idris documentation comments in type definitions

Recall that a comment defined with three bars (|||) is a documentation comment in Idris, meaning it can show up in the Idris tooling and help the user as well as the reader of the source. Let's fix this union type up with documentation comments.

src/FizzBuzz.idr

module FizzBuzz

data FizzBuzzNumber = ||| Represents a number divisible by both 3 and 5.
                      FizzBuzz 
                    | ||| Represents a number divisible by 3. 
                      Fizz 
                    | ||| Represents a number divisible by 5.
                      Buzz 
                    | ||| Represents a number divisible by neither 3 nor 5. 
                      Number Nat

Importing modules in the Idris programming language

Next we need a way of getting from Nat numbers to FizzBuzzNumbers, which means we need our divides function from the previous post. To start, let's export just the divides function from the Division module by decorating the divides function with the export keyword.

src/Division.idr

module Division

||| Returns a `Just of the remainder of two numbers, or `Nothing` if the 
||| divisor is zero.
total
modulo : Nat -> Nat -> Maybe Nat
modulo _ Z = Nothing --can't divide by zero, so Nothing
modulo Z _ = Just 0
modulo dividend divisor = 
  if dividend >= divisor
  then modulo (assert_smaller dividend (minus dividend divisor)) divisor
  else Just dividend

||| Returns `True` if the first number divides the second evenly, otherwise 
||| returns `False`. Also returns `False` if the divisor is zero. 
export total 
divides : Nat -> Nat -> Bool
divides divisor dividend = 
  case dividend `modulo` divisor of 
    Nothing => False
    Just remainder => remainder == 0

Now, we can go ahead and import the Division module by using the import keyword in the FizzBuzz module.

module FizzBuzz

import Division --imports the `divides` function

data FizzBuzzNumber = ||| Represents a number divisible by both 3 and 5.
                      FizzBuzz 
                    | ||| Represents a number divisible by 3. 
                      Fizz 
                    | ||| Represents a number divisible by 5.
                      Buzz 
                    | ||| Represents a number divisible by neither 3 nor 5. 
                      Number Nat

I went ahead and put in a comment explaining exactly what we're importing because a peculiar thing about the Idris language is that, by default, Idris exposes all exposed modules.

(Frankly, I'm not crazy about that as a default, so a comment is a good practice.)

Nested conditional logic in Idris

I admit I'm torn on using the infix notation from the previous article. I'm not crazy about filling up my code with a bunch of backticks, but for mathematical expressions where the English really lends itself to saying something like, "if 3 evenly divides n then..." I think infix makes sense.

module FizzBuzz

import Division --imports the `divides` function

data FizzBuzzNumber = ||| Represents a number divisible by both 3 and 5.
                      FizzBuzz 
                    | ||| Represents a number divisible by 3. 
                      Fizz 
                    | ||| Represents a number divisible by 5.
                      Buzz 
                    | ||| Represents a number divisible by neither 3 nor 5. 
                      Number Nat

||| Given a number, returns a Fizzbuzz representation of the number depending
||| on whether it is divisible by three, five, or both, using the `divides` 
||| function from the `Division` module.
total
classify : Nat -> FizzBuzzNumber
classify n = 
  if 15 `divides` n 
  then FizzBuzz
  else if 3 `divides` n 
       then Fizz 
       else if 5 `divides` n then Buzz else Number n

Note again that we don't have to specify Division.divides in our code, though in most cases I think I would, anyway.

As you can see, nested conditionals in Idris work a lot like they do in other languages, or more precisely, like the ternary (?:) operators do in other languages since both clauses evaluate to the return type.

Converting a number to a `String` type in Idris

Now we can pattern match on the type FizzBuzzNumber as we have before.

src/FizzBuzz.idr

module FizzBuzz

import Division --imports the `divides` function

data FizzBuzzNumber = ||| Represents a number divisible by both 3 and 5.
                      FizzBuzz 
                    | ||| Represents a number divisible by 3. 
                      Fizz 
                    | ||| Represents a number divisible by 5.
                      Buzz 
                    | ||| Represents a number divisible by neither 3 nor 5. 
                      Number Nat

||| Given a number, returns a Fizzbuzz representation of the number depending
||| on whether it is divisible by three, five, or both, using the `divides` 
||| function from the `Division` module.
total
classify : Nat -> FizzBuzzNumber
classify n = 
  if 15 `divides` n 
  then FizzBuzz
  else if 3 `divides` n 
       then Fizz 
       else if 5 `divides` n then Buzz else Number n 

total
fbnToString : FizzBuzzNumber -> String
fbnToString FizzBuzz = "FizzBuzz"
fbnToString Fizz = "Fizz"
fbnToString Buzz = "Buzz"
fbnToString (Number n) = show n

As you can see, for most numbers, I'm using the show function, which converts a Nat to a String in Idris.

Modular encapsulation in Idris

Clearly, we're pretty close to being able to use our FizzBuzz module. It would be great, though, if we we could hide the FizzBuzzNumber type entirely by exposeing a function to convert a number to a FizzBuzz String directly.

Let's do that now:

src/FizzBuzz.idr

module FizzBuzz

import Division --imports the `divides` function

data FizzBuzzNumber = ||| Represents a number divisible by both 3 and 5.
                      FizzBuzz 
                    | ||| Represents a number divisible by 3. 
                      Fizz 
                    | ||| Represents a number divisible by 5.
                      Buzz 
                    | ||| Represents a number divisible by neither 3 nor 5. 
                      Number Nat

||| Given a number, returns a Fizzbuzz representation of the number depending
||| on whether it is divisible by three, five, or both, using the `divides` 
||| function from the `Division` module.
total
classify : Nat -> FizzBuzzNumber
classify n = 
  if 15 `divides` n 
  then FizzBuzz
  else if 3 `divides` n 
       then Fizz 
       else if 5 `divides` n then Buzz else Number n 

||| Converts a `FizzBuzzNumber` value to a `String`. 
total
fbnToString : FizzBuzzNumber -> String
fbnToString FizzBuzz = "FizzBuzz"
fbnToString Fizz = "Fizz"
fbnToString Buzz = "Buzz"
fbnToString (Number n) = show n 

||| Converts a `Nat` to a `String` according to the standard requirements of
||| FizzBuzz, displaying "Fizz" if the number is divisible by 3, "Buzz" if the
||| number is divisible by 5, or "Fizzbuzz" if the number is divisible by both
||| 3 and five. 
export total
numberToFBNString : Nat -> String
numberToFBNString n = fbnToString (classify n)

What we now have is effectively a small library that exports two functions: Division.divides and FizzBuzz.numbertoFBNString. In the next article, we'll set up a .ipkg package file and make the function available on our system.

In conclusion

In this tutorial, I hope you've learned the basics of declaring a union type and how importing modules works in Idris. Let me know if there's anything I can make any clearer. In the next module, we'll be looking at setting up our main function and trying our hands at dependent types!

DEV Community: webbureaucrat

Finding a Successful Build of NodeJS in Nixpkgs

It's not you; it's Node.

Steps to finding a successfully pre-built NodeJS version from Nix's Hydra

Building a Directory with `buildNpmPackage` in a Nix Derivation

The Ten Commandments of Writing Programming Tutorials

Name things descriptively.

Annotate types always.

Keep code in a working state.

Avoid summarizing code.

Highlight syntax.

Write descriptive headings.

Use images where appropriate.

Distinguish between compiler and runtime errors.

Include the full message when describing errors.

Import everything explicitly.

Epilogue

When I was a junior dev I'd look at some problems and think "This is hard because I'm not very good at this and need to get better" and now I look at a lot of those same problems and think, "This is hard because this is badly-designed garbage."

Emacs for Python and Poetry Using `basedpyright-langserver`

Why basedpyright?

Configuring your Poetry projects to work with basedpyright or pyright

Installing basedpyright as a language server

Configuring emacs to use basedpyright-langserver

A general tip for debugging lsp-mode

Happy coding!

A Font Family Choice for Pragmatism and Disability Allyship

Atkinson Hyperlegible is font choice for disability allyship

Atkinson Hyperlegible is a font choice for any pragmatist

Atkinson Hyperlegible may be a font choice for you

Iced for Desktop Development in Rust

Setup

Writing a State Model for Iced in Rust

Writing a Message Enum for Iced in Rust

Implementing iced::Application

Writing a main function to run an Iced Application

Wrapping up

Setting and Reading Session Cookies in Rust with Actix Web

Starting with Hello World in Rust with Actix Web

Getting started with actix-session

Building out a cookie session in Actix Web

Reading from a cookie in Actix Web

Setting the session cookie in Actix Web

Wrapping up

Writing a (Nix-Friendly) Hello World Web App in Haskell with Scotty

Prerequisites for Haskell and Scotty

Initializing a Hello World App in Haskell with cabal

Adding Scotty to your Haskell project

Writing a "Hello, world" action in Scotty

Specifying a port and running a server in Scotty

In conclusion

Running and Connecting to Postgres Using Docker Compose

Start with a .env file

Create database scripts

Create a docker-compose.yml file

Connecting to a locally-running Postgres container

Wrapping up

Idris FizzBuzz Part IV: Main and .ipkg Files

Idris .ipkg files for libraries

Writing an Idris executable

Idris .ipkg files for executables

Compiling and running an Idris executable

Wrapping up FizzBuzz for Idris

Idris FizzBuzz Part III: Defining Types and Importing Modules

Idris documentation comments in type definitions

Importing modules in the Idris programming language

Nested conditional logic in Idris

Converting a number to a String type in Idris

Modular encapsulation in Idris

In conclusion

Configuring emacs to use `basedpyright-langserver`

Implementing `iced::Application`

Writing a `main` function to `run` an Iced `Application`

Getting started with `actix-session`

Initializing a Hello World App in Haskell with `cabal`

Converting a number to a `String` type in Idris