Setting up reliable environments for our software is tricky. 
The task has kept developers and sysadmins up at night for decades. Making environments and packages truly reproducible and reliable for more than a few weeks before regression sets in, is surely no easy task. In this post, we'll see how we can set up truly deterministic, reproducible and even ephemeral environments with the help of a clever set of tools called Nix, so we can sleep better, knowing our systems can be installed from literary scratch and be guaranteed the same binary packages down to the lowest dependencies.



What's in a name?


Let's face it, "Nix" has a quite ambiguous name that can reference a lot of things, so first, let's get the naming out of the way.

When people hear "Nix", they might think about "*nix", or the commonly spoken variant (without the asterix) "nix", the short name the industry has adopted for systems based on good old UNIX. Linux is "nix", macOS is "nix", BSD is "nix" - and in a way, "Nix" is also... well, "nix." Confused? Yeah.

Nix, in our context, refers to three things: the Nix Expression Language, a pure, lazy, functional language. This language makes up the foundational building blocks of the Nix package manager, which can be installed on any "*nix" system (like Linux or macOS) or as it's own unique Linux distro, NixOS. So a language, a package manager and even a distro. What's this all about?


What makes Nix so special?


With the naming out of the way, what makes Nix so special? What does it have to offer that apt, yum, or brew don't have?

First off, it's cross platform. The Nix Package Manager can run on the most common Linux systems, as well as macOS, but that is true for many package managers these days, and is not it's main advantage.

What makes Nix special is how it manages packages and dependencies. Nix guarantees reproducible packages, which means that all steps involved in building a package can be run again and again with the same outcome, and if any of the variables in the dependency chain change (all the way down to low-level packages like libc), it will result in a new version of this package, that can be installed side-by-side with the old version. This is possible thanks to the nature of the functional Nix language. From the docs: 

Nix is a purely functional package manager. This means that it treats packages like values in purely functional programming languages such as Haskell — they are built by functions that don’t have side-effects, and they never change after they have been built. 

Nix stores packages in the Nix store, usually the directory /nix/store, where each package has its own unique subdirectory such as 



where b6gvzjyb2pg0… is a unique identifier for the package that captures all its dependencies (it’s a cryptographic hash of the package’s build dependency graph). This enables many powerful features.

In more practical terms, this is accomplished by generating hash values of all dependencies going in to the package build, as well as the outcome of the build itself.


Kicking the tires

Let's look at an example package called hello. 
The Nix-script responsible for building the package can be found in the nixpkgs-github repo (all packages are essentially built and installed from these scripts) and it looks like this:


We begin by installing it to the user's environment:

As we can see, a lot of things was required for a simple program that prints out Hello, World!.

One might look at this list and think "Hey, i see curl on there - curl is already installed on my machine, why do I need it again, and won't multiple versions of the same package wreck-havoc on my machine?"

To address the first comment, this neat little trick is what makes Nix-packages self-contained and immune to what else might be installed on the system.

Other package managers, like apt or brew are often heavily dependent on there existing one version of a package or it's transitive dependency. This is why installing packages on different systems can lead to quite different results, and why a package update can break a system. With Nix, all package dependencies comes bundled and are stored in their own hashed directories. The model Nix follows is that every transitive dependency must be defined in a Nix-expression that can be built itself, thus supplying a dependency chain of "build instructions" all the way to the lowest parts.

If one lower-level dependency change, the main package can not be seen as the same exact version as we had before, and will be installed side-by-side with the old version, completely isolated. This nifty feature is why Nix and NixOS has become a favorite among developers and system administrators alike, it makes for highly robust and deterministic systems, easy to update or rollback.
To address the concern of multiple versions of curl, let's take a look at what we have on our PATH after the install of hello:


curl being a transitive dependency for hello does not place it on our PATH, the version of curl provided by macOS is still in place.

If we install curl as a top level package, the story would be different:


To keep score of what version of a Nix-package is currently being used, Nix takes leverage of symlinks:


If we regret installing curl via Nix or something broke, Nix keeps track of the users environment in Generations, making it easy to rollback the system:




Creating reproducible development environments with nix-shell

Another powerful tool provided with Nix, is nix-shell. Software teams have always been struggling with the famous "works on my machine" syndrome, where a build or piece of code works as expected on one machine, but not on another.

Creating reproducible development environments has been the holy grail for many, and tools like Packer and Vagrant takes the virtual machine way to solve this, by building VM images that can have tool pre-installed or installed via provisioning systems like Ansible.

Another way to solve this is with containers, typically with Docker and Docker-Compose.
Both virtual machines and container technology has pros and cons, but the mayor drawback is that it is quite hard to make truly reproducible environments.

Both are great for freezing a setup in time (like a VM image or a container image), but are hardly deterministic.
A badly written Dockerfile can produce different results when built on two different systems (as a side note, it is possible to build reproducible and small Docker images with Nix).

nix-shell on the other hand leverages the power of Nix to build local, reproducible, isolated and ephemeral shell-environments.

Let's say we want python3 but don't want to install it user/system-wide. It is possible to use nix-shell to provide an on-demand shell with just python3:

When exiting the shell, no version of python3 is available on path.

With the Nix language, it is possible to write declarations for these shells that can be shared among the development team.
Let's say the team is maintaining a Java application, deployed on Kubernetes, and want a setup that just works™ on all systems:



This script can be stored in the root of the Java-project and added to version control. When a developer wants the environment, a simple command will provide it:

As we can se, the selected packages and dependencies are all installed.

To clean up old nix-shell sessions, we can simply run

It's also possible to build the entire Java application with Nix, leveraging it's deterministic nature to ensure a reproducible build. 

Conclusion

This post has been a brief intro to Nix and what at can provide in terms of reproducible, isolated systems. It is possible to do so much more than just install pre-built packages. I would recommend How Shopify Uses Nix for further inspiration on how to build and deliver software using Nix, as well as checking out the home-manager project for managing user environments. I would also like to recommend Ian Henry's Learning Nix Guide.

Interested in building your first Nix package? See the excellent nix-tutorials website and start hacking!



Deterministic systems with Nix

I en verden som jobber med å bli mer sirkulær, er begreper som verdikjeder, ressurser, forretningsmodeller og materialstrømmer sentrale for det meste som blir skrevet om teamet. For å kunne jobbe med å bli mer sirkulær i praksis er det derfor viktig å kjenne til de grunnleggende mekanismene, slik at man forstår de reelle driverne for å bli mer sirkulær. Denne artikkelen vil ikke gjøre deg til ekspert på temaet, men gi deg en grunnleggende innføring i sirkulære verdikjeder og materialstrømmer.

Vi har tidligere skrevet en intro til hvordan man kan gå fra lineær til sirkulær forretning ved hjelp av tre ulike strategier: slanke, bremse, lukke. I denne artikkelen vil vi dykke litt mer ned i ressursflyten, gjennom å se på den sirkulære verdikjeden og materialstrømmene som flyter gjennom verdikjeden. Dette legger et grunnlag for å kunne se videre på sirkulære forretningsmodeller, hvilket er tema i noen kommende artikler.



Verdikjeder - hva er det?

En verdikjede representerer tradisjonelt sett nødvendige aktiviteter, og rekkefølgen på de, for å kunne levere et produkt eller en tjeneste til kunden. På selskapsnivå har verdikjeden ofte blitt knyttet opp mot selskapets verdiskapingsprosess og operative modell. På produkt- og tjenestenivå representerer verdikjeden ofte produktets liv fra råvareinnhenting og produksjon, til bruk hos en kunde og til slutt avfall. Et økt fokus på supply chain management, har også ført til at man ser mer på verdikjeder mellom aktører og på tvers av produkter, da med et tydelig logistikkfokus. 

Den sirkulære verdikjeden

I en sirkulær verden fokuserer man mer på produktene og ressursenes livsløp, heller enn selskapets verdiskapingsprosess. Fokuset i starten av den sirkulære verdikjeden er produktsentrert, mens det dreier mer mot et ressursfokus etter hvert. Sentralt for sirkulære verdikjeder er at 1) minimalt med nye ressurser skal komme inn i verdikjeden, 2) ressursene skal holdes så lenge så mulig i verdikjeden i sin høyeste verdi og 3) minimalt av ressurser skal gå ut av verdikjeden når de først har kommet inn. Tanken om lukkede verdikjeder med ressurser som går i evig sirkel gjennom flere produkters livsløp er en tydelig ambisjon i en sirkulær økonomi. 



Materialstrømmer og reverserte sykler

Vi skiller mellom biologiske og tekniske materialstrømmer som flyter gjennom en verdikjede. Biologiske materialstrømmer består av materialer fra naturen, der de kan komme tilbake til naturen via kompostering eller liknende biologiske prosesser. Tekniske materialstrømmer inkluderer materialer som metaller, mineraler og plast, og for disse er det ikke er mulig å bringe råstoffene tilbake til naturen på samme måte. Man er derfor avhengige av andre kjemiske prosesser for å holde de inne i et lukket kretsløp.

Med bakgrunn i dette, har Ellen MacArthur Foundation laget et rammeverk for å beskrive hvilke prosesser man kan ta i bruk for å holde de tekniske og biologiske materialstrømmene i verdikjeden så lenge som mulig.

Rammeverket omtaler ulike prosesser, eller reverserte sykler, for å beholde ressurser i verdikjeden, og definerer fire prosesser for tekniske materialstrømmer og to for biologiske materialstrømmer. De tekniske materialene kan holdes i verdikjeden gjennom 1) reparasjon og vedlikehold, 2) gjenbruk og redistribusjon, 3) renovering og reproduksjon og 4) resirkulering. Rekkefølgen på disse er sentral med tanke på å bevare ressursen i sin høyeste verdi. En reparert jeans har en høyere verdi enn et resirkulert jeans-stoff. 



De biologiske materialene kan holdes i verdikjeden gjennom 1) kaskadering og formålsendring og 2) biokjemisk råstoff ekstraksjon, og rekkefølgen på disse representerer det samme som for de tekniske. Dersom det ikke er mulig å gjennomføre noen av de reverserte syklene, vil materialstrømmen gå ut av verdikjeden gjennom energigjenvinning eller havne som avfall på deponi.



Kjennskap til den sirkulære verdikjeden og forståelse for materialstrømmer og reverserte sykler, gir et godt grunnlag for å se at man er en del av en helhet, der ressursene vi bruker for å skape verdi bare et ledd i ressursens livsløp. Helhetsperspektivet gir mulighet for å bruke ressurser og designe produkter og tjenester på en måte som legger til rette for at ressursene kan holdes så lenge som mulig i verdikjeden, og ikke bare maksimeres for delen man selv får kommersiell nytte av. Hvordan man kan gjøre dette på en måte som skaper verdi, vil vi utforske videre når vi dykker ned i ulike sirkulære forretningsmodeller.



Relevant resources

Lüdeke-Freund et al. (2019) - A Review and Typology of Circular Economy Business Model Patterns

Ellen MacArthur Foundation (2012) - Towards the circular economy Vol. 1: an economic and business rationale for an accelerated transition

Sirkulære verdikjeder og materialstrømmer - The basics

Drypp er en lavterskel podcast fra Bekk.

En liten gjeng samlet inn heftige påstander og inviterte til Drypp-innspillingskveld på Trondheimskontoret - med julebrus, godis og god stemning. Resultatet ble seks episoder med brannfakler. God lytt.

Brannfakkel - Skal data leve evig? (Del 5 av 6)

Web har alltid vært en plattform hvor innholdet må tilpasse seg forskjellige skjermer og skjermteknologier. Media queries har gjort det mulig for oss å tilpasse designet vårt til denne hverdagen, men i en hverdag hvor vi skriver flere og flere komponenter strekker ikke media queries alltid til. Møt CSS container queries, et nytt standard-forslag som endelig skal la oss kode komponenter uavhengig av resten av designet!

Responsive web design ble først definert som designtankegang helt tilbake i 2010 av Ethan Marcotte, og har blitt et påkrevd verktøy for enhver som jobber med front-end. Teknologier som media queries, responsive bilder og grid har etterhvert gjort det veldig mye enklere å lage responsive sider som både laster kjappere, og bedre tilpasser seg besøkende til de sidene vi lager.

Men der våre eksisterende teknologier fungerer veldig bra når vi designer og har kontroll på helheten, er det noe som mangler når vi begynner å kode enkeltkomponentene som utgjør helheten, spesielt med utbredelsen av designsystemer og komponentbiblioteker. Når vi mister kontroll over helheten, og blir en brikke i det store puslespillet, ser vi at vanlige media queries kommer til kort.

Container queries prøver å svare på spørsmålet; hvor stor plass har egentlig jeg? Ikke hvor stor skjerm har brukeren som er inne og ser på siden nå, men hvor stor plass har egentlig jeg. Fokus flyttes fra helheten til enkeltkomponentene vha. av container queries, og gir endelig enkeltkompomonententene mulighet til å blomstre uavhengig av alle de forstyrrende elementene rundt 🚀.

Se for deg at du skal designe en inngang til Bekks sider som skal fungere i mange forskjellige kontekster, f.eks. de tre variantene under (jeg er ingen designer…).



I utgangspunktet et ganske enkelt design å implementere, hadde vi bare visst hvor mye tilgjengelig plass du har. Jeg skal ikke gå gjennom hele forslaget til container queries, se på kildene for inngående og oppdatert informasjon, men på nåværende tidspunkt kunne CSS’en sett slik ut for dette designet:



(På nåværende tidspunkt 13.12.2021 fungerer ingen av eksemplene på container queries i Chrome Canary, så jeg får dessverre ikke lenket til et fungerende eksempel 😢)

Det som er så behagelig med denne koden er at vi ikke har brydd oss noe om verden utenfor vår lille komponent, Bekk-inngangen kan være plassert på toppen, i hovedartikkelen eller i en aside uten at vi trenger å tenke på dette når vi koder vår CSS.

Hvis vi ønsker litt mer kontroll så er det mulig å navngi containere, slik at vi kan tilpasse designet til for eksempel en søkeside-container eller en handlekurv-container. Det jobbes også med nye enheter for å dynamisk kunne endre innhold basert på størrelsen på containteren uten nødvendigvis å bruke container queries, på samme måte som vi har vh og vw med dagens viewport-baserte størrelser.

Oi, dette ser gøy ut, tenker du nå, og som meg har du sikkert lyst til å ta dette i bruk så fort som mulig… Dessverre er det ikke helt klart ennå; det jobbes aktivt med hvordan denne standarden kan se ut, og Chrome Canary er foreløpig eneste nettleser du kan teste ut dette i, selv om det med dagens versjon dessverre ikke fungerer helt optimalt. Men andre nettlesere vil raskt følge etter når dette blir en standard og det finnes en eksempelimplementasjon, og jeg ser frem til en fremtid hvor vi kan lage enda bedre tilpassede sider for våre besøkende :)

Får å få flere detaljer om container queries anbefaler jeg å ta et dypdykk i de vedlagte kildene, og hvis du snarere er en person som liker å høre noen snakke om dette vil jeg på det sterkeste anbefale å ta en titt på Una Kravets "Designing in the Browser" på YouTube, https://goo.gle/dib-chrome, og spesielt de følgende episodene hvor hun snakker om container queries.





Kilder

developer.mozilla.org

Say Hello To CSS Container Queries

A Primer On CSS Container Queries

On Container Queries

Samling av eksempler på codepen.io

CSS Container Queries

Your true love might desire four calling birds for Christmas, but your colleagues do not have the same opportunity to raise their wishes. I suggest 4 pranks!


Although the 1st of April is still months away as I am typing this, a good prank is timeless and could very well be used today! Even if you wouldn't call yourself a prankster, it is never a bad idea to know what you're up against. Thus, I present to you 4 pranks of varying severity, use them at your own discretion.

1. Change a semicolon to a greek question mark

Someone once decided that they wanted to watch the world burn, so they designed the greek question mark exactly like the semicolon. Or perhaps it was the other way around. I dunno, ask a chicken 🐓<>🥚. We can take advantage of this to cause some havoc. Simply find a semicolon in your targets code and replace it with a greek question mark. If you don't have the greek question mark on your keyboard already, a simple trick is to copy-paste it from Wikipedia (or this article, here you go ; ). 

This will not work if your colleague is a Rust developer however, they actually went out of their way to prevent this. I'm betting there is a core Rust developer out there who was just a tad too frustrated of being victim to this prank.


2.  Install cloud-to-butt Chrome Extension

Installing an extension is a prank you can pull on almost anyone, and it is often very entertaining for both parties.

I once got to be a spectator to an extension-prank 5 years in the making. Suddenly, a furious mail ticked into a mailing list including me between student business relation volunteers and a developer. You see, for 5 years we had written that an external company were recruiting butt engineers. After some investigation, much giggles and some diplomacy, the culprit was revealed to be the cloud-to-butt extension which had processed all static text of the HTML-file the developer had tested a new web editor with ☁️.

If you haven't got the gist of it yet, what the cloud-to-butt extension does is to rewrite every occurence of "cloud" to "butt", and "the cloud" to "my butt". Which explains why you can store endless files in Google Butt 🍑.

So when your developer colleague just wants to quickly change a translation string and opts to do so through i.e. Githubs editor, you're in for a treat (and hopefully an entertaining review instead of a revert-commit).


Chrome Store

Firefox Marketplace


3. Alias cd to go somewhere random

Besides git status and ls, cd might be my most used command. It was thus an easy target when I naively left my computer unlocked to go get my coffee cup filled. Upon return, I expected nothing and was baffled when I failed to change directory to a subfolder of my project. Certain that my harddrive or terminal were completely whack, I gave the machine a quick reboot, met with much snickering from my colleagues. I then suspected foul (🦅) play, and indeed, I was the victim of this prank. 

To achieve this, you will have to edit your colleagues config file. In their terminal, navigate to their home folder through cd ~. Then, list all the content of the folder through ls -la. If you see a file named .zshrc there, you have found our target. If not, look for .bashrc. If both are non-existent, abandon all hope: your colleague uses another terminal configuration and is most likely too advanced for you.

To edit the configuration file, simply write open .zshrc or open .bashrc, depending on what you found in the previous step.
This should most likely open an editor with the file. To change cd, simply paste this into the bottom of the file and press save:



This finds a random subfolder of the current location, and either cds into that folder or cd upwards if there are no subfolders 😈

4. [object Object] in feedback forms

Known as the terror of JavaScript, [object Object] has been seen by many web developers when they try to print an object. Usually, one expects to see the content of the object, but are met by this beautiful work of art. 


It might also show up when you wrongfully deserialize an object as a string. As such, it can be quite entertaining to watch the one colleague that actually reads feedback pull their hair out trying to understand where the serialization/deserialization goes wrong.

Don't forget to change it up with a VPN, different browsers, etc. to really ensure that you are not easily detected.

What now?

If 4 pranks for christmas was not enough, you can expand your arsenal with 4 more, written by John Sparrow. You can read about them on his page. The sixteen other pranks of the christmas developer prank calendar is up to you! Look forward to your coal! ☃️



13-Dec

Today's posts

Deterministic systems with Nix

Sirkulære verdikjeder og materialstrømmer - The basics

Brannfakkel - Skal data leve evig? (Del 5 av 6)

CSS Container Queries

4 Ways to Prank Your Developer Colleagues 🤠