I’ve been using Nix for a year now. It’s been going fairly well, by the way. Here are some misconceptions I’ve had to overcome to become a more productive Nixer. False: You can’t deploy Nix software to Docker or Kubernetes False. If you can push to a docker registry such as docker.io, you can deploy to Docker or Kubernetes using Nix. You can use dockerTools.buildImage to build a docker image from Nix.
Sorry if I upset any of the nice Racket folks out there. It’s time for a little reality check. First, repeat after me: Coding is a tool to get stuff done. If you let your programming language impact your productivity, you are not in charge, the technology is calling the shots. Why would I use Racket today? Do I want to iterate every 18 hours waiting for the pkgs.
Source lives here. Play it here. In a joint effort, Aliasing and myself have created a novel top-down action rogue-lite for the 2023 Spring Lisp Game Jam. Aliasing is an experienced game dev so in a way, I was along for the ride. Still, I managed to contribute some game mechanics, features, unit testing, CI/CD that deploys to super-rogue.workinprogress.top on every commit. This was a fun devops exercise for me - Aliasing mentioned to me that I helped keep him on track with the addition of automated testing and per-commit deploys to a website (it makes it easy to play-test pull requests).
I’ve been operating Sillypaste (source code) - a simple Django pastebin created for dogfooding. In this post I hope to capture some of the painpoints of working with Django, Python, Heroku, and the migration to fly.io. Ever since Heroku sold its soul to SalesForce its been on the decline. Customer service is worse than ever, giving wonderful canned responses to most questions. It used to be free to host Sillypaste on heroku, now is a $17/mo ordeal.
Figure 1: Pre-commit running within GitLab CI I’ve been using pre-commit as my tool to set up hooks to run when I commit to Git. It helps me catch gotchas such as fixing line endings, fixing whitespace, refusing to commit on linter errors, and so on. Often, I’ve noticed with working on teams is it’s fairly easy for a new contributor to forget to set up pre-commit on their development machine.
Figure 1: your computer on low memory TL;DR: yes. You can throw more swap at most processes and it’ll eventually finish… Eventually. Last year I warranty-ed a Dell XPS 13 with 32 GiB of RAM, all specced out. Sidenote: I wouldn’t recommend the Dell XPS 13, at least in 4K. The laptop gets anywhere from 1-3 hours of real world usage and gets hot as most Macbooks. The Dell XPS 13 4K is not a viable product.
Here’s a small outline of how I validate used computers as “usable” and “in working condition”. My hope is these steps help computer users spot “lemons” - machines that shouldn’t be depended on because they don’t work all the time. Basics Before stress testing or examining SMART data, consider the following checklist: Turn it on and ensure you can access the firmware settings/BIOS. F2 and Delete seem like the most common keys.