-
We All Write Monads, Whether We Know It or Not
Recently I’ve been rebooting my Haskell by working through Advent of Code, and bogging about it: Re-learning Haskell with Advent of Code - Part 1, Re-learning Haskell with Advent of Code - Part 2, and it’s got me thinking. I was quickly re-introduced to the concepts of: Functors, Applicative Functors, Monoids, Monads, a strong type system, higher kinded types, and functional purity, and straight away, started spotting these patterns in the code I write every day at work (predominantly Rust with some Bash, Python, and C++ thrown in for good measure).
Read more… -
Re-Learning Haskell with Advent of Code - Part 2
In Part 1, I skipped the day 2, 5, & 7 problems that get you to build and use a Intcode computer. Each problem provides an Intcode program to run: A series of integers that can each either represent an instruction or data, and can mutate itself. Looking forward, every odd number day from day 5 onwards uses the Intcode program. So I decided to come back to them, and make a concerted effort at a few of them in a row.
Read more… -
DRY Shouldn't be a Goal in Itself
DRY, “Don’t Repeat Yourself”, is often described as a “principle” of software engineering. I looked up what “principle” is defined to mean and Google says: a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning. Maybe in this case that’s a bit strong. I’d think in the case of a software principle we’re talking more about an idea of how things should be, or a guide1 to decision making.
Read more… -
Re-Learning Haskell with Advent of Code - Part 1
A few years ago I learned myself a Haskell for greater good from a book “Learn you a Haskell for greater good”1 and the first few chapters of another book “Haskell from first principles”2. It was fun to learn. I didn’t go onto use Haskell to build any real applications, beyond coding up some exercises and mini programs to learn things. I believe I got a lot from it. At the very least it’s joyful to solve problems in Haskell.
Read more… -
Itertools - A Force for Good?
Itertools are a way of bringing along a bunch of list manipulating goodies from functional languages into procedural languages. I’ve encountered it as a Python library and a Rust crate. A quick bit of google’ing shows some evidence of this existing in other languages. I used to write Python a lot. Now I write mostly Rust. I used to err on the side of not using itertools in Python. I’m more than happy to read or write Rust code using itertools.
Read more… -
Rust - Converting between file formats - JSON, YAML, & TOML
Rust’s serde library is a generic serialize-deserialize framework that has been implemented for many file formats. It’s an incredibly powerful framework and well worth giving the documentation a read. It can deserialize a file format into a strongly typed rust data structure, so that the data in code has no affiliation to the data format it was read from, then can be serialized into another file format. #![allow(unused_variables)] use serde_derive::{Deserialize, Serialize}; #[derive(Serialize, Deserialize, Debug, Clone, PartialEq)] #[serde(rename_all = "camelCase", deny_unknown_fields)] struct MyData { field_one: usize, field_two: String, field_three: bool, some_data: std::collections::HashMap<String, usize>, } fn main() -> anyhow::Result<()> { let my_data_yaml = r#" fieldOne: 7 fieldTwo: "lorem" fieldThree: true someData: x: 1 y: 2 z: 3 "#; let my_data_toml = r#" fieldOne = 7 fieldTwo = "lorem" fieldThree = true [someData] x = 1 y = 2 z = 3 "#; let my_data_json = r#" { "fieldOne": 7, "fieldTwo": "lorem", "fieldThree": true, "someData": { "x": 1, "y": 2, "z": 3 } } "#; let deserialized_yaml = serde_yaml::from_str::<MyData>(my_data_yaml); let deserialized_toml = toml::from_str::<MyData>(my_data_toml); let deserialized_json = serde_json::from_str::<MyData>(my_data_json); assert!
Read more… -
Language Servers Are Cool
In slight contrast to my previous post where I espoused the virtue of code being text and not relying on developer tooling to interact with it: language servers are cool. They decouple the back end of gaining semantic understanding of code in a particular language from the editor implementation. A language server for each language can be written, and the editor only needs to integrate the language server protocol once, to get a host of IDE style features for each language.
Read more… -
You Shouldn't Need an IDE to Read Code
This is important. Code is read far more often than it’s written. Primarily, it’s read through a web GUI. You want to read the source code of a library you’re using. Say it’s in Github, you’re going to start looking at it through the Github GUI. If you want to take a deeper look, you might clone the repo and open it in you’re editor, but the vast majority of library code you read will be through a GUI.
Read more… -
Testing Microservices with Mockserver
Mockserver is a great piece of tooling that takes a huge amount of heavy lifting away from testing microservices. There’s no need to mock out downstream dependencies or client APIs. There’s no need to write complex test code to synchronously handle the mechanics of requests going back and forward while also trying to embody some comprehensible declaration of the designed behaviour. It does about as much of the mechanics of testing for you as it’s possible for it to do.
Read more…