DEV Community: Heechul Ryu

Don't Give Up on Nix Just Yet

Heechul Ryu — Thu, 06 May 2021 11:35:24 +0000

In my case, I almost did, but I'm glad that I ended up not.

There are many great articles to show how Nix can be useful, so instead of me repeating those points, I will link them at the bottom of this post.

WTH is Nix?

Before I go ahead and talk about why I felt like giving up and why you shouldn't, let me describe what's my perspective on Nix and why I'm interested to keep using it.

You may or may not have come across Built with Nix from something like direnv wondered What Nix is.

Nix is at least these three things:

Nix, the (programming) language that you write in *.nix files to let Nix work for your liking.
Nix, the package manager powered by few binaries like nix
NixOS, Linux "distro" that comes with Nix to configure OS itself

Although I have a super tiny experience about NixOS before, I'm not really using NixOS at the moment so my focus in this post is solely about Nix the package manager and Nix the language.

Why did I even care to try Nix?

There are multiple motivations and below is one of them.

I don't write Go programs often enough that usually Golang is not installed in my machine.
But when I need to, installing Go was a bit painful and confusing enough for me (surprisingly almost every time!). And my usual approach to deal with this issue is using Docker. All though I often use containers like in a way of using VM to avoid polluting my host machine, a container is no localhost, so it's limited and it could "force" you to be container "expert" when you don't need to be just yet.

What you wanted to do was just to write a Go program and run it remember? 😅

Then I discovered Nix and I gave it a Go. 😆

$ go env
zsh: command not found: go

$ nix-shell -p go

# now you are in Nix shell

[nix-shell:~]$ go env 
# ...
GOOS="darwin"
GOPATH="/Users/username/go"
# ...

[nix-shell:~]$ cat <<EOF > hello.go
package main

import "fmt"

func main() {
    fmt.Println("Hello, 세상")
}
EOF

[nix-shell:~]$ go run hello.go
Hello, 세상

[nix-shell:~]$ exit
$ go
zsh: command not found: go

That felt like a breeze to me. I didn't need to do anything like setting the right environment variables and so on. Just nix-shell -p go then I have it and exit then I don't!

Technically you still do but it doesn't pollute the environment. The reality is more complicated than that but let's leave it at that for now.

This, my first experience with Nix and it was probably like a year ago or so. But then I didn't go into Nix much yet until recently.

Since I do like to isolate environments, reuse configurations, and reproduce those setups to multiple devices, I've been using my own dotfiles and sometimes, containers.

What other tools I used before Nix

Since I didn't want to use all different tools for all different OSes (and their own package managers), Homebrew (and Linuxbrew) was my first choice to install necessary packages.

But I find some issues with it in my use case, as it's often the case with any other tools.

To list some:

installing specific versions with Homebrew can be challenging. (Especially when you need both at the same time)
many times, it feels slow to update new formulae (brew update) which it always seems to run when I brew install [package]

Enter asdf.

asdf solves those issues mostly for programming language packages.

But in my opinion, Asdf is more of a runtime version manager than a package manager.

However I'm going to skip explaining about asdf since this is a post about Nix! But you should definitely check it out if you are interested :)

However, remember that I mentioned that I used Nix briefly before? At this point, I felt like Nix can be a tool that can complement both tools in a "new way".

So I decided to try Nix to see if it's possible to replace other tools. Therefore my dotfiles started to add Nix files.

Why I felt like giving up

So it felt like everything was actually going ok until it didn't. I reached the point one package didn't install properly on macOS, while it was fine on Linux with the unstable channel. While this can be fixed over time I wanted to make an exception just for few packages only for Darwin (macOS) platform.

And I couldn't manage to actually make that happen for a while.

Why? Because I wanted to do this kind of advanced stuff without actually understanding the language first.

Why did I do that? I think because that's how I approached with other tools.

I usually learn tools first by knowing which command and arguments to use to do this and that.

And Brewfile (in case of brew) and .tool-versions (in case of asdf) are extra that comes after just typing commands. I'm pretty sure I'm not alone on this.

But in the case of Nix, using Nix the language properly could be essential very fast.

What advanced stuff that I tried to do?

Optional overlaying for Darwin

if any of this stuff doesn't make any sense to you feel free to skip to the next section

This is a typical top line you may come across with .nix files

{ pkgs ? import <nixpkgs> {} }:

What if you want to overlay some packages conditionally? You can try something like the below.

{ pkgs ? import <nixpkgs> {
  # to simplify the code, we import `overlay.nix` for now which you will get to see in a minute
  overlays = [] ++ pkgs.lib.optionals pkgs.stdenv.isDarwin [ (import ./overlay.nix) ];
} }:

But how do I get pkgs.lib and pkgs.stdenv if I'm in the import section that doesn't know about pkgs yet?

You can actually import inside import (with let ... in in this case) like below.

{ pkgs ? import <nixpkgs> (
  let
    unstable = import <nixpkgs> {};
    stdenv = unstable.stdenv;
    lib = unstable.lib;
  in
    {
      overlays = [] ++ lib.optionals stdenv.isDarwin [ (import ./overlay.nix) ];
    }    
  )
}:

Seems too many imports in the first import section and it looks confusing? Also, can you even do that?

Yes, it might look weird but this is very valid in Nix. Inside () it just expects any valid Nix expression. Therefore, let ... in { ... } is a perfectly valid because {...} # AttributeSet is expected after import <nixpkgs>. Why import <nixpkgs> expect AttributeSet? We will get to that in the Demystifying Nix files below for details.

Now we solved the issue but because it could look confusing I split the files below.

# my-pkgs.nix
{ pkgs ? import <nixpkgs> (import ./fallback/darwin/optional-overlaying.nix) }:

# ...

# fallback/darwin/optional-overlaying.nix
let
  unstable = import <nixpkgs> {};
  stdenv = unstable.stdenv;
  lib = unstable.lib;
in
  {
    overlays = [] ++ lib.optionals stdenv.isDarwin [ (import ./overlay.nix) ];
  }

# fallback/darwin/overlay.nix
self: super:
let
  # different channel to fallback
  fallback = import <nixpkgs-fallback-darwin> {};
  pkgs = fallback.pkgs;
in with pkgs;
{
  # imagine these two are broken for Darwin in your main channel, `<nixpkgs>`,
  # now you can fallback to a different channel, `<nixpkgs-fallback-darwin>` that may work for Darwin
  inherit hello;
  inherit bash;
}

Like I said earlier if these don't make much sense yet it's ok and the section X will help you

Is Nix the language difficult?

Not really, once you get to know it, it's quite simple but it did look foreign and scary to me for a bit initially.

Because even though it's simple but also it's very flexible like lego blocks.

Nix is an actual programming language not like much simpler configuration files like Brewfile or .tool-versions and even though I've been writing code for a while I couldn't help but notice myself asking but why the whole (programming) language to manage packages?

And not just language itself in a file but also each file look somehow different to each other. For example, why default.nix looks different than shell.nix and all other .nix. What's really expected in .nix files? I got confused.

Therefore I somehow resisted embracing the Nix language. It also didn't even "look" good until I got the aha moment.

Turns out it's because Nix is super flexible. Anything that is a valid Nix expression can be .nix file. Even just the number 3 is a valid Nix expression and you can import it to other .nix files and do anything with it.

Demystifying Nix files

After this section, you will get to know why all nix files kind of somewhat don't look similar to each other except they all look Nix-y.

I tried to come up with why and this is one of my speculations that we are quite used to somewhat (implicitly) structured files.

Some example implicit structure scenarios:

maybe main.xxx file has to exist in order for your program to work
import lines should be on the top of the file
main function somewhere
have to have one function in a file at least
could be even a whole main class should exist
can't just have the number 3 as a whole file content

With Nix, we may need to rethink that, and to simply put, .nix files just need to be valid Nix expression and that's it.

For example, these are all valid.

you can just have 3 and that's it

# number-three.nix
3

just a list if you want

# list-simple.nix
[ 1 2 ]

import can be anywhere, I mean literally

# list-with-import.nix
[ 1 2 (import ./number-three.nix) ]
# [ 1 2 3 ]

You can think of what import does as simply embedding the source file to the target file.

# attributeset-with-import.nix
{
  one = 1;
  two = 2;
  three = import ./number-three.nix;
}

# attributeset-with-import-2.nix
let
  number_three = import ./number-three.nix;
in
  {
    one = 1;
    two = 2;
    three = number_three;
  }

even this can be valid

# function-mirror.nix or function-identity.nix
x: x

and you can use like this

# import-identity.nix
2 + (import ./function-identity.nix 3)
# 5

for two arguments, you can:

# function-add.nix
a: b: a + b

# import-add.nix
import ./function-add.nix 2 3
# 5

maybe AttributeSet as an argument

# function-arg-as-attr.nix
{ argInAttr, secondArg ? "with the default value" }:
argInAttr ++ secondArg

# import-arg-as-attr.nix
# I skip secondArg because it's with default value
import ./function-arg-as-attr.nix { 
  argInAttr = "I skip secondArg because it's "; 
}

now you should know these are nothing special

# just a function that has two arguments called `self` and `super`
self: super:
# ...

# just a function that expect AttributeSet that may have `pkgs`, if not `import <nixpkgs> {}` is the default value
{ pkgs ? import <nixpkgs> {} }:
# ...

# perhaps this way helps you to see it better
{ 
  pkgs ? (import <nixpkgs> {}) 
}:

But why import <nixpkgs> {}, why {}?

Because <nixpkgs> will be evaluated to a function that expects AttributeSet as a parameter that can be empty.

For example, let's look at another file below that is a function.

# https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/exa/default.nix

{ lib, stdenv, fetchFromGitHub, rustPlatform, cmake, pandoc, pkg-config, zlib
, Security, libiconv, installShellFiles
}:
# it's just this file is expecting to be called by consumer that will provide all these attributes

So far when I've been with other tools, usually command line proficiency first and conf file after.
With nix, I think it's inevitable to need to be comfortable with Nix language to unleash the potential of Nix. And that's why I think there is a whole programming language to a package manager.

You can find good resources for the language:

The good thing about Nix is that there are tons of examples you can find on Github. Go ahead and get yourself familiar with them!

OK, so maybe you are convinced that Nix the language is not something we should be afraid of but is that why should I use Nix, though?

Benefits of getting started with Nix

Fresh way of doing things

It could be refreshing if you are willing to learn a new of doing things, just like embracing FP for the first time!

Nix language is actually interesting

you might not welcome less familiar syntax but they actually could help you decouple how you think with syntax.

Nix could look foreign at first just because it's different from what you are used to but it's actually quite simple and works like lego blocks. I hope that becomes more clear in the previous section.

Good opportunity for getting used to Functional Programming

Have you been wanting to use/learn FP but haven't had a chance yet?
Then maybe it could be even more interesting to you.
I don't think I mentioned that Nix is a functional programming language and it is.
It can be a good opportunity to get used to FP since, with Nix, it's very easy to start small.

You don't have to use NixOS or anything else that you don't need/want yet

Start small with nix-shell or nix repl

You get to learn how your packages are built

For example, this is how ponysay is built, https://github.com/NixOS/nixpkgs/blob/d600f006643e074c2ef1d72e462e218b647a096c/pkgs/tools/misc/ponysay/default.nix

My Nix usages so far

A cheap and fast way of installing or trying out new packages

$ nix-shell -p cowsay
[nix-shell:~/tmp]$ cowsay hi
 ____
< hi >
 ----
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

So much more you can do

So far I'm not using many things like NixOS, nix-darwin, etc. but you can, whenever you want.

There are also multiple ways of installing your packages even just within Nix ecosystem

Wrapping up

There is nothing wrong with existing tools depends on your perspective/usage.

And of course, I'm still using other package managers like apt-get and brew, asdf, etc. They are good when trying everything with Nix is not quite smooth, but Nix certainly became my default package manager and reduced the usages of other tools significantly!

I'm just glad that I've embraced this new way of managing packages and my environments.

It feels clearer what exactly I need and how it's being installed and what are the dependencies and so on.

It was hard to feel that way with apt-get, etc.

I'm not sure if I will ever be a Nix "expert", but I'm pretty sure Nix will be still useful in anyways.

I'm also collecting useful links for Nix here, https://gist.github.com/ryuheechul/a0bd4e4b69565da86301ee8cc26311e1

Quickest Way to Run NixOS on Your VMWare Fusion

Heechul Ryu — Wed, 06 Jan 2021 00:02:11 +0000

It is all started from this tweet.

// Detect dark theme var iframe = document.getElementById('tweet-1346136404682625024-723'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1346136404682625024&theme=dark" }

Even though I'm already pretty happy with macOS itself. I was intrigued about using (and learning) NixOS in a way he would.

Start using it with VMWARE Fusion

Oh boy. Let me tell you, it's not straightforward at all.

You can download ISO image from here, https://nixos.org/download.html

And (attempt to) install it via creating a new VM with the image.

Please tell me that I wasn't the only one that was completely lost after booting via the (CD) image.

After clicking this and that and rebooting SEVERAL times, my poor soul later discovered that there is actually no (automatic) installation is provided by this image, unlike Ubuntu! I have to do that all by myself!

Alright, maybe it's time to learn all the low-level goodies of doing everything from scratch. Let me read the documentation, https://nixos.org/manual/nixos/stable/index.html#sec-installation.

You know what, I'm not ready to do that just yet especially when I just wanted to have a taste of what it's like to use it as a guest VM (on VMWare Fusion).

Thanks to this blog, https://davedellacosta.com/posts/2019-03-29-why-nixos-is-hard-and-how-to-fix.html I feel better about myself not being able to do this as if it was a trivial thing. Also, it links me to https://nixos.wiki/wiki/NixOS which introduced me to https://github.com/jeaye/nixos-in-place.

nixos-in-place sounds all nice but I would still need another VM that is already installed with other distros if I were to avoid installing anything.

Staying lazy

You know what? VMWare actually can import VirtualBox VM and NixOS provides ready-to-run VM on VirtualBox already. Why don't I just import it?

Yes, it worked.

Whether you are playing with the pure ISO image or imported VM for VirtualBox, you will soon notice one thing that is very annoying. Which is your mouse gets trapped in VM as soon as you hover your mouse on VM.

I got a hint here though about what to do. https://discourse.nixos.org/t/nixos-as-vmware-guest/7441 which was not very straightforward as a newcomer to NixOS. But I still found out what to do with googling. You will need to add in a configuration file via [sudo] nano /mnt/etc/nixos/configuration.nix

Once you edited that, you can apply this by sudo nixos-rebuild switch. You will probably also have to reboot your (virtual) machine via reboot. After that, amazingly your mouse doesn't get trapped anymore 🎉.

That's good enough for me to feel I accomplished something today, I guess 😅.

Btw, if you didn't know or worried about the cost of VMWare instead of the free of charge that VirtualBox offers, VMWare Fusion actually offers a free license as well, https://my.vmware.com/web/vmware/evalcenter?p=fusion-player-personal

My First *.rs Other Than main.rs

Heechul Ryu — Sat, 05 Dec 2020 11:10:52 +0000

In this post, I assume that you played with Rust at least a little bit.

When you first create a project with cargo init my-project, this is what you get out of the box.

❯ tree my-project
my-project/
├── src/
│  └── main.rs
└── Cargo.toml

And you start writing code and it may look like this.

// src/main.rs

fn main() {
  Greet::hello();
}

struct Greet {
  // you may have some fields here
  // ...
}

impl Greet {
  fn hello() {
    println!("Hello, world!");
  }

  // let's pretend you have 100 more lines of some functions below
  //
  // fn foo(...) {
  // ...
}

// and there might be other stuff here for `main.rs`

You check if this actually runs by cargo run and it outputs Hello, world!

It works OK but there are a couple of issues that may bug you.

📜 the code for Greet struct is quite long (it's more than 100 lines!)
🍯 you don't want to couple Greet struct and the other purpose functioning codes in main.rs which might happen without realizing if you keep them in the same file for long enough
🏠 you don't want to read code for Greet stuff when you want to edit just main.rs and vice versa

So now you want the Greet struct to be on its own file so you moved things and it looks like these now.

// src/main.rs

fn main() {
  Greet::hello();
}

// `Greet` struct moved out from here
// ...

// src/comm.rs (comm for communication)

// there are moved from `main.rs`
struct Greet {
  // ...
}

impl Greet {
  // ...
}

You cargo run again but it doesn't work anymore. Does it?

At this point when I search google about how to split a struct into another file, I get all sorts of information and I'm sure they are very helpful but all I wanted to do right now is simply splitting a file into two or more so I can manage the code better. I don't know about you, but I'm not interested in learning about crates and all the other stuff just yet.

OK, let me see if I can make minimal changes to make it work... and tada!

  // src/main.rs

  // acknowledge `comm` module which corresponds to `comm.rs`
+ mod comm; 

  // use `Greet` struct from `comm` module
+ use comm::Greet;

  fn main() {
    Greet::hello();
  }

  // ...

  // src/comm.rs

  // we add `pub`s for things to be accessible from other files like `main.rs`

- struct Greet {
+ pub struct Greet {
    // ...
  }

  impl Greet {
-   fn hello() {
+   pub fn hello() {
      println!("Hello, world!");
    }

    // ...
  }

Now when you cargo run it should work like a charm :)

You probably have some questions about why mod comm; corresponds to comm.rs, and the answer is here, https://doc.rust-lang.org/rust-by-example/mod/split.html and the specific chunk in the link are below.

// This declaration will look for a file named `my.rs` or `my/mod.rs` and will
// insert its contents inside a module named `my` under this scope
mod my;
// ...

I hope this was helpful (I actually wrote it for the future myself who always tends to forget particular details). Since I'm still a Rust (re)beginner, I might have not understood things correctly. When you have improvement suggestions on terms and expressions I used here or even a better way to approach the same problem, please let me know!

Developing React components with (completely) dark-themed Storybook

Heechul Ryu — Sun, 28 Jun 2020 20:53:14 +0000

Hey, this is my first post at Dev.to!!

Motivation

I'm a developer but not a professional React (or Web) developer. I've still developed small open source web apps before though because I like Web (tech)!. One of them is called Galley which was developed in 2017 (why does it feel so old... 😭) and it was for helping my YAML engineering back then.

Although it was not quite a complex app, I enjoyed developing it by learning and using the new tech like React, ReasonML, Grommet, RxJS,and others.

I'm currently a full-time DevOps Engineer working with Kubernetes & Helm and other DevOps tools such as Terraform.

I recently came up with an idea to build an open-source tool that would help to debug Helm (template) development (to be more efficient at YAML engineering 😅).

the tool that I mentioned that I wanted to build is actually quite irrelevant for the rest of the post so we can focus on setting the ground up React component dev environment here

Getting started

Instead of planning the "perfect" app design first, I wanted to develop the idea further by actually building it.

UI stuff

I'm not following very closely with bleeding-edge web tech. So I chose React for a safe bet. I used create-react-app for the first time to kick start quickly.

$ yarn create react-app darkbook

This time I wanted to use a different React UI framework than Grommet. I chose Chakra UI after some research because it:

supports dark mode
looks nice out of the box
has no CSS dependencies

UI first approach for prototyping

Unlike what I did for Galley, I wanted to work on UI parts first before working on any real business logic so that I can concern less of other stuff and focus better on prototyping to enable me to feel what would an app actually could look like.

At first, I considered using a testing library just because of the white background of the web page was too bright for me at night - Yeah, my open sourcing activity is happening mostly at night when I'm free of day time duties ✌🏼.

also because initially, I struggle to get started with Chakra UI with a dark mode which you will see later

After a while, I quickly realized that the testing library isn't really for visual development. So I started looking for alternatives and eventually I was considering Storybook for the first time.

Every new stuff can be intimidating at all different levels. To overcome this, I first made myself familiar with Storybook by going through an official tutorial and it was easy and simple enough to follow. Storybook itself also supports dark mode which is another great point!

After the tutorial, I integrated it into the app I just generated with create-react-app earlier.

$ cd darkbook
$ npx -p @storybook/cli sb init
$ yarn storybook

Commands above will open the basic light-themed Storybook web page.

I played with some code files under src/stories to understand how it actually works and I discovered that Storybook is quite well structured and easy to use even though it was new to me.

I also added manager.js to enable the dark mode on Storybook.

// .storybook/manager.js

import { addons } from '@storybook/addons';
import { themes } from '@storybook/theming';

addons.setConfig({
  theme: themes.dark,
});

Working with Chakra UI

If you are not familiar with it, I encourage you to visit the website. It looks quite nice.

I will be honest with you though. Even though it looked nice and the documentation initially seemed fine enough, later I actually struggled quite a bit. Especially when I was trying to enable the dark mode by default.

And that struggle was actually why I decided to post this article hoping this post might be helpful for the first time Chakra UI users like me.

The glimpse of struggles

which you can skip if you are not interested to hear about

I followed the getting started page which essentially running this:

# I recommend you not to do this though and you will see why
$ npm install @chakra-ui/core @emotion/core @emotion/styled emotion-theming

And tried to enable the dark mode by default by following this page, https://chakra-ui.com/color-mode.
However, I couldn't find the way to do it except for toggling the light and the dark mode (which I didn't want)

After trying and looking at this and that, I finally discovered this issue, which shows a history of struggles of others as well for enabling dark mode by default. And it also was a hint that indicating it might be dealt with the version 1.0.

So I started looking at Releases page and found the pre release.

This pre-release looked much more promising than the current stable version and the instruction made more sense so I followed the instruction from it.

Getting actually oriented with Chakra UI

I basically installed Chakra UI like this instead.

$ yarn add @chakra-ui/core@1.0.0

You will probably be prompted to choose the correct version and I chose 1.0.0-next.2 which was the latest pre-release at the time of writing this post.

To enable the dark mode for every Story, I added preview.js.

// .storybook/preview.js
// which is modified off from https://github.com/chakra-ui/chakra-ui/blob/657103491bc70194fdd62dcf6ef7e16648c2a6c3/.storybook/preview.tsx

import CSSReset from "@chakra-ui/css-reset"
import theme from "../src/chakra"
import { ChakraProvider, Box } from "@chakra-ui/core"
import { addDecorator } from "@storybook/react"
import * as React from "react"

const newTheme = {
  ...theme,
  config: {
    initialColorMode: "dark",
    useSystemColorMode: false,
  }
}

export const Chakra = ({ children }) => (
  <ChakraProvider theme={newTheme}>
    <CSSReset />
    <Box p={5}>
      {children}
    </Box>
  </ChakraProvider>
)

addDecorator(StoryFn =>
  <Chakra>
    <StoryFn />
  </Chakra>)

.storybook/preview.js basically allows you to have the "layout" page for every Story. Now it feels like we are going somewhere.

Not so fast. Don't forget to actually fetch the theme.

# in ./src
$ npx chakra-cli init --theme

You will see there is a lot of files downloaded that are required to be committed to your own repo and supposedly this will make it a lot easier to customize your own theme according to the Chakra UI and I agree with it too.

Although this can be a bit of bad news for minimalists like me since I also didn't plan to change much of the theme yet. Perhaps let's ignore this issue and be generous about it for now.

We are almost there. It's time to make a few changes to stories to actually use Chakra UI components

# src/stories/1-Button.stories.js

-import { Button } from '@storybook/react/demo';
+import { Button } from '@chakra-ui/core';

# src/stories/0-Welcome.stories.js

-import { Welcome } from '@storybook/react/demo';
+import { Box, Link } from '@chakra-ui/core'
+
+const Welcome = ({showApp}) => (
+  <>
+    <Box>
+      This is a custom welcome message using Chakra UI
+    </Box>
+    <Link onClick={showApp} color="teal.500">
+      Let's go to see the button
+    </Link>
+  </>
+)

Was it enough?

Yes, it was!

<Welcome />

<Button /> with text

<Button /> with emoji

This means I finally managed to fully set up the environment that I can develop UI components in a way it's completely dark-themed!!!

Here is the repo that you can take a look for the code and commits in case you want to.

Wrapping up

Storybook wasn't much of overhead even though it was a new tool to me
enabling dark mode was much more of a (mental) hassle than I thought but I'm quite happy now that it works!
I'm quite excited to create all the new components and get my hands dirty with all these tools

Misc.

if you don't see stories that have a dark background, make sure to try different browsers.

In my case, Safari kept resetting the page back to the light mode after few milliseconds somehow. So I switched to chrome and worked.
Also, you might need to refresh the page or restart the storybook.

That's it for now and thanks for reading!

DEV Community: Heechul Ryu

Don't Give Up on Nix Just Yet

WTH is Nix?

Why did I even care to try Nix?

What other tools I used before Nix

Why I felt like giving up

What advanced stuff that I tried to do?

Optional overlaying for Darwin

Is Nix the language difficult?

Demystifying Nix files

Benefits of getting started with Nix

Fresh way of doing things

Nix language is actually interesting

Good opportunity for getting used to Functional Programming

You don't have to use NixOS or anything else that you don't need/want yet

You get to learn how your packages are built

My Nix usages so far

A cheap and fast way of installing or trying out new packages

My home that comes with all the packages I want/need across all my devices

Also it's reusable to do something else like Building a Docker image

Using it in a project

So much more you can do

Wrapping up

Quickest Way to Run NixOS on Your VMWare Fusion

Start using it with VMWARE Fusion

Staying lazy

My First *.rs Other Than main.rs

Developing React components with (completely) dark-themed Storybook

Motivation

Getting started

UI stuff

UI first approach for prototyping

Working with Chakra UI

The glimpse of struggles

Getting actually oriented with Chakra UI

Yes, it was!

Wrapping up

Misc.