Using <depot>'s gemma project with `dockerTools.buildLayeredImage` because I
need access to a nix-packaged server and gemma is the first thing that comes to
mind.
I'm attempting to setup my blog using the following:
- Google Cloud Run: I whitelist a docker image that packages my application and
then Google runs it "statelessly" (i.e. without persistence). The stateless part
should be fine for the time being.
- Nix: Using `<nixpkgs>.dockerTools.buildLayeredImage` to output docker images
from Nix expressions.
- Docker: Upload the output image from the Nix expressions and upload it to
Google Container Registry from which it can be run from Google Cloud Run.
Some helpful commands:
```shell
> sudo gcloud auth login
> nix-build ./docker/cloud_run.nix
> sudo docker image import ./result
> sudo docker tag <name> gcr.io/<google-cloud-project-id>/<name>:<tag>
> sudo docker push gcr.io/<google-cloud-project-id>/<name>:<tag>
```
I'm unsure if Google Cloud Run is my desired end goal, but it may help me
publish a blog faster than setting up a Kubernetes cluster, which is what I'd
ultimately like to do. Cloud Run should be cheaper financially and time-wise.
A Poem:
I wanted to try out this package...
30 minutes later after a dozen failed attempts at packaging it...
I no longer want to try this package...
for now.
The previous commit that adds Java code is part of a larger project intended to
use Nix to package Clojure. I'd like to build something similar to @tazjin's
buildLisp except for Clojure instead of for Common Lisp. Once building for both
ecosystems is similarly easy, it will be easier for me to compare the two
languages. Right now `buildLisp` is so good that it attracts me to Common Lisp
even when I don't know the language.
Add an example of two java files, Main.java and Another.java, where Main.java
depends on Another.java. This is part of a larger example of attempting to use
Nix to package these.
Also ignoring the *.class files that `javac <filename>` outputs.
Removing the default.nix that I used to attempt to build prove, a Common Lisp
unit testing library. Also removing the lisp module with the unit tests
themselves.
After some toil, I have a working proof-of-concept blog. The idea is simple:
write blog posts in markdown and store the posts in the `./posts`
directory. Then use the server and `pandoc` to convert these markdown files into
HTML at request time. I'm using nix to package everything together. It's far
from perfect, but it works at the moment, which is encouraging.
All of this is still a work-in-progress. Just checking in my work.
Also:
- Write function `render-post` to convert a markdown file into HTML. This is
still a work-in-progress since we need to capture the output and not just have
it printed to *standard-out*.
- Return dummy data in /posts
- We need the markdown files, to be in the /nix/store and the server needs to be
aware of there location.
- Since we're dependending on `pandoc`, our server needs to know about it too.
For both of these cases -- especially for the latter case -- I imagine there may
be a more idiomatic way of doing this.
Attempting to write a blog where:
- The server is Common Lisp. Why? I'd like to learn Common Lisp.
- The blog posts can be written in Markdown.
- The package is developed and deployed using Nix.
Most of this is a learning exercise. The blog itself is something that I'd like
to use instead of Medium and other forums.
Create a third_party subdirectory and a third_party/lisp. This directory layout
resembles and is inspired by the layout of Google's mono-repo, Google3. @tazjin
borrowed this idea from Google and I'm borrowing the idea from him.
Using @tazjin's depot/default.nix to bootstrap this project. I'll be borrowing
his Nix idioms until I better understand Nix and have preferences of my own.
My first foray trying to package Common Lisp with Nix. I'm using @tazjin's
buildLisp and other libraries, all of which I'm importing as `tpkgs`, and all of
which have been a tremendous boon to my productivity.
Getting some practice with Python's heapq module (which I'm unsure if I used
correctly) to do a priority-first-traversal of a graph: known as Dijkstra's
algorithm.
Solves the InterviewCake.com problem that asks us to write a function that
returns the number, y, that occurs twice in a list, xs, where xs is an unsorted
list of integers from 1..n with a length of n + 1.
This is just a small org table that I created to help me
Fun fact: In Emacs, you can insert literal TAB character by pressing `C-q
TAB`. For creating tables, using TAB characters feels perfectly
acceptable. Perhaps the TAB name comes from TABle.
Solves an InterviewCake.com problem that returns the index of the element in a
list that should be the first element in that list. It's an exercise that's
useful for seeing other applications of a binary search.
Solves an InterviewCake.com problem that returns all of the permutations of a
string input. The problem states that it's acceptable to assume that your input
string will not have repeated characters, which is why using a Set is
acceptable. I like this solution because it builds a permutations tree and then
assembles all of the permutations by doing a DFT over that tree.
Cameron sent over some property tests for his File.split function, which is a
part of a larger effort to port f.el, a nice library for working with file
paths, over to Haskell.
While I've done these algorithms before, I'm preparing for an on-site with
DeepMind, so I created a subdirectory called deepmind where I'm storing my
second attempts at these problems. The idea of storing them in a second
directory is to remove the urge to check my existing solutions that also exist
in this repository.
This is a work-in-progress. I'd like to add a README to this project to explain
my intention. The goal, roughly, is to port Elisp's fantastic f.el module to
Haskell. I consider Haskell APIs to be useful but somewhat sloppily designed. In
the same spirit as Elixir wrapping Erlang APIs, many of the functions I intend
to define will simply wrap existing Haskell APIs, but with a hopefully cleaner
API that I find more intuitive.
Adds some of the code I generated while studying for a role transfer at Google
using the fantastic resource, InterviewCake.com. This work predates the
mono-repo.
I should think of ways to DRY up this code and the code in
crack_the_coding_interview, but I'm afraid I'm creating unnecessary work for
myself that way.
I believe I have multiple other snippets and attempts scattered across /tmp,
~/programming, and other directories. Again, I created these files and others
before the mono-repo.
Well, unexpectedly (perhaps naively so), I only made it to Day 7. I created
these before I stumbled upon the idea of the mono-repository; otherwise, I like
to think I would have more granular commits introducing this work.
