What's it all about, Alfie?

This morning I was able to make a stripped-down dotfiles GitHub repo that Codespaces will use when a new Docker image is created. If there is a install file in the repo, it'll be executed after cloning the repo to the new user - as specified in the Dockerfile's USER variable.

So in my Dockerfile I now have:

  # Make my user for when we really get going, and pull in my env from GitHub
  ARG USERNAME=drbob
  ARG USER_UID=1001
  ARG USER_GID=$USER_UID
 
  # Create the user and add him to the sudoers so that he can install more stuff
  RUN groupadd --gid $USER_GID $USERNAME \
      && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME \
      && apt-get update \
      && apt-get install -y sudo \
      && echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME \
      && chmod 0440 /etc/sudoers.d/$USERNAME
 
  # [Optional] Set the default user. Omit if you want to keep the default as root.
  USER $USERNAME

and that lands me in the repo's home directory, but I still have to clean up the dotfiles repo, and all the permissions from the last post. To do that, I made a simple function in my ~/.bashrc that does all that:

  #
  # This is a simple function to cleanup the GitHub Codespace once it's been
  # created. Basically, I need to remove the left-overs of the dotfiles setup
  # and clean up the permissions on all the files.
  #
  function cleanup () {
    pushd $HOME
    echo "cleaning up the dotfiles..."
    rm -rf dotfiles install README.md
    echo "resetting the ownership of the workspace..."
    sudo chown -R drbob:drbob workspace
    echo "cleaning up the permissions on the workspace..."
    sudo chmod -R g-w workspace
    sudo chmod -R o-w workspace
    sudo setfacl -R -bn workspace
    echo "done"
    popd
  }

At this point, I can launch a Codespace, it'll have all my necessary environment, and I can continue to refine it in my dotfiles repo as that's only being used for the set-up of these Codespaces. So it's easy to remove things I'll never need there, and make sure it's customized to the things that I do need there.

Very nice. 🙂

Late last week, I was accepted into the GitHub Codespaces beta program, and since I've been looking for something to do coding on my iPadPro, and was doing a little work with GitPod, it was something I was really interested in seeing and comparing with GitPod. So I started with two of the projects I've put into GitPod: Advent of Code, and CQ.

First things, Codespaces is a similar in that it's all about Docker images of the repos with enough of a system wrapped around it to enable the style of development needed. Java, Ruby, Node, Rust - if you can do it on Debian or Ubuntu, then you can do it in Codespaces. It's just that universal.

It's also possible to run other images, like Postgres, Mongo, MySQL, and then have them linked up to the repo's instance so that you can refer to the databases off of localhost and the default port. That's really nice.

It's not particularly easy - unless you really understand Dockerfiles... but if you keep at it, they have examples, and for the most part, you'll be able to get something going, and it's all in the repo, so it's simple enough to drop the image, and create another. It just takes time.

What I did find interesting is that the default user for Codespaces is root. I was not at all interested in working as root - even on a Docker image... it's just too uncomfortable. Thankfully, there is a vscode user you can use, and the USER directive in the Dockerfile will drop you into that user when things get started.

The next thing is the permissions... it's wild... everything is open to the world, and again, while this may be "fine" - it's very uncomfortable for me, so I converted the ownership of the workspace to the vscode user, and then removed the additional ACL security with:

  $ cd /home/vscode
  $ sudo chown -R vscode:vscode workspace
  $ sudo chmod -R g-w workspace
  $ sudo chmod -R o-w workspace
  $ sudo setfacl -R -bn workspace

With these done, the directory is owned by vscode and it's respecting the normal umask values on the creation of new files.

In the future, I'm going to have to figure out how to personalize the codespace by using the dotfiles repo in GitHub, and then installing my dot files and updating all these permissions, etc. as well. If I get to have several of these, it'll pay off to have it all done properly from the start...

This morning I wanted to be able to copy my bookmarks from Safari to Safari Technology Preview and thought "This should be easy" - and Hoo Boy! I'm glad I was right. 🙂 I will confess that I was a little surprised that the Bookmarks are implemented as a plist, but I guess that's as simple a storage scheme as macOS has, and there are system calls to make sure that updates are atomic... so I guess it's as good as any.

The key is that this Bookmarks.plist is in ~/Library/Safari and can be copied to the target directory:

  $ cp ~/Library/Safari/Bookmarks.plist ~/Library/SafariTechnologyPreview/

after that, there wasn't even the need to restart Safari Technology Preview - just the next time I looked at the Bookmarks, they were updated. Nice! 🙂

As part of the onboarding process at The Shop, today was getting set up with the development tools to run all the Docker containers for an Airplane Mode development set-up on my laptop. Nice... I have always liked that mode - as it limits damage that can be done, and at the same time, allows everyone to develop without stepping on each other's toes.

I've used MongoDB before - back at PEAK6 with the MMD (Magic Middle Dude), and there was a lot ot like about it back in 2011, but they certainly have been making changes since then, and it was fun to get back to working with it - but the first thing was to get a decent command-line client for mongo - and thankfully, Homebrew was there to help!

The steps are pretty easy - given that I didn't want to run mongo on my laptop - Docker was here for all that... I just needed the client:

  $ brew tap mongodb/brew
  $ brew install mongodb-community-shell

and then it's ready to use as mongo. Could not be simpler!

Running it against the Dockerized replica set, that was part of the set-up, wasn't bad:

  $ mongo --host rsetname/host1:27017,host2:27017,host3:27017 \
          --username dev-guy  --password dev-local \
          --authenticationDatabase dev-local

This is just the example of the replica set called rsetname running on the three hosts called host1, host2, and host3 - all on the default mongo port of 27017. The username, password, and authentication database are all simple examples, and this is all easily made into an alias that makes it even easier to start.

I'm looking forward to working with mongoDB again... it's been a while.

One of the Finance Shops I was at happened to have a Post-Trade Management system, and it was built in Java that had all kinds of interesting capabilities to aggregate and plot different levels of aggregations and filtering on the positions, and folks really seemed to like it. One of the key components to that system was a UI toolkit from a consulting shop that was entirely driven on XML configuration files.

I can remember adding a few lines of XML, and adding a very complex dialog box to the app, and thinking - There is no way that's a 1:1 mapping of the config! And I was right. These were heavily built library modules, and adding a few lines really added entire subsystems and connections for those UI elements.

I've also worked at a Dot-Com Shop where the complete build of a machine was described in a single YAML file. This includes all the user accounts, all the software packages, all the configuration for the software packages, and all sitting in a YAML file.

I'm currently looking at a CI/CD Pipeline that is completely specified by a YAML file. This includes shell commands, with options, and variable expansion, and while it's understandable why the developers of each of these systems chose XML, or YAML, as their configuration files - there are loads of parsers that are solid and reliable, and the files can mix in simple data structures, and in those data structures, you can add shell commands and can then do variable expansion... so it makes sense.

What concerns me is that so many developers seem to feel that these configuration files are not nearly as important as the code backing them. That it's easy, safe, and simple to change the configuration and try it again... and maybe for some things it is... but chances are, if your configuration is really your code - then you need to treat it as such.

For example, it is very common to have multiple layers of configuration files. Maybe there's a company level, and overlaid on that is a project level, and overlaid on that is an environment level. These probably get parsed, and then merged one on another to allow certain things to be set at one level, and others at another, and the sum total of all the config data is what's used.

What could go wrong?

Well... imagine if one component of the config is a list of strings that have to be processed in a specific order - let's say top to bottom, as they appear in the file. But then another of the layered config files has another list - with the same name - maybe it's a typo, maybe it's not. How are these merged?

Does the latter stacked file overwrite the lower level? That's one way, but then it's hard to make sure that those lower-level commands are being run/parsed properly. Could lead to duplication in the upper-level files, and that's not really the point of the stacking, is it?

What if you simply append the upper entries to the lower entries? That could be just as bad because the writer of the lower ones may be making assumptions about the state left after the processing of the upper file.

In short - having configuration files store data structures, is fine - and it's useful... but having it include what amounts to executable code means that it needs to be treated like code. And can you imagine writing a function that's layered from multiple files, and then executed at runtime? The difficulty in tracking down errors would more than offset any gains in reuse.

So if you want to have layered configuration files - Great! Just leave it to data that's easily flattened, and tested... but if you're going to have it include executable code - make it simpler - a single layer. You'll be glad you did. 🙂

It's always good to be kind to the "Next Guy" who has to pick up your code. Writing clean code, and making sure it's readable and understandable is very important, but there's really far more to it than that, and I was reminded about that in Slack this morning, and I wanted to write it down so that I wouldn't forget about it.

When a project gets so large that the tests take more than, say 15 min, to run, often times, a developer will disable the tests because it really gets in the way of making progress. This makes perfect sense. But then you get into a problem that the more you do this, the more likely it is that someone will check in code that fails on one of these disabled tests, and then you have a broken build.

Sure, some will say "That's OK... that's what the CI/CD Pipeline is for." which could be true, until the tests are long enough that multiple people are submitting pull requests and they don't want to wait for the full set of tests to run, and so they move on. But then there's a failure, and another team member has more changes that need to go in, and their tests passed, and so the first developer has to let the other dev go through, and then update their pull request based on the new code, and that's frustrating to them.

So now, developers don't want to add tests, because that just makes the situation worse, and now there's less coverage on the code, and less reliability on the system overall, and it just starts to slide downhill. But there's more... if they are waiting too long for tests, they could be skipping writing good docs or commit messages because they know they have a long wait ahead of them, and they aren't thrilled about that.

Take away good tests, complete tests, and good docs, and now we're really starting to erode the quality of the code - simply because things take too long to be comfortable, and it's perfectly understandable. But we each need to push through that initial response, and work to make the tests faster, and the documentation better, and make sure that the "Next Guy" who works in this code gets the best possible codebase they can have.

Today I was spending a little time moving another of my little projects to GitPod, and I was amazed at the execution speed I was seeing, compared to my 2019 decked-out 16" MacBook Pro. I mean Wow! On my MacBook Pro, the test ran in:

  $ make test
  ./quip 'Fict O ncc bivteclnbklzn O lcpji ukl pt vzglcddp' -kb=t -fwords
  [31967 us] Solution: When I see thunderstorms I reach for an umbrella

which isn't bad... 31.9 msec. About what I get on the ObjC code as well. And when I ran it on the GitPod instance:

  gitpod /workspace/Quip $ make test
  ./quip 'Fict O ncc bivteclnbklzn O lcpji ukl pt vzglcddp' -kb=t -fwords
  [26967 us] Solution: When I see thunderstorms I reach for an umbrella

So the instances they are fronting are at least as good, if not better, in single-core performance, than my recent MacBook Pro. That's impressive. Another good reason to look at doing a little more coding remotely.

I have always hoped that GraalVM would be something that really launched Clojure, and Java, into something that would be fast - and like really fast. But then it was a licensing issue as GraalVM was licensed by Oracle, and so any production deployment was going to cost real money. But even then... for a company, that might not be bad - especially when you have to worry about performance, and you are looking at JNI, or a mixed-mode environment with C++.

So it was very interesting to me to see this article about calling Java from C++, with the GraalVM compiling Java to a shared library (and header), that could then be linked in with C++ like any other shared library.

The key is that this would completely avoid JNI, and it's complications - in coding, versioning, and execution speed. I can imagine having lots of Java code, built and tested in the normal Java way, and then compiled into a shared library for inclusion in a much more performant C++ system for those engines that had to run for long periods of time without restarts, and be very aware of resource management (memory, ports, etc.) and yet built with a simpler system than C++.

The article is interesting, but again... with the licensing, it's only really useful for organizations with revenue streams to support it.

A few days ago, I read about the new JetBrains Mono font that they had created for their IDEs, and it looks interesting with the increased hight of the lower-case letters, and the easily readable "1lI" combination... so I decided to give it a whirl on my editor, and in Xcode.

I have to say I like how Sublime Text and Xcode handles all the weights of the font, and the ligatures for common expressions makes it a lot easier to read the code - as if I'd written it on a chalkboard. Very nice indeed

I'm not sure how it'll play out, but it's pretty nice so far, and I'll play with it for a bit and see what I think. So far... nice. 🙂

This morning I was reading the newsfeeds, and came across probably my favorite Javascript graphing package: Chart.xkcd. The idea is that it can be used to create those seemingly hand-drawn charts the the xkcd comic so often generates as part of their work. But this is easily put into React and other web frameworks, and put on web pages for that casual look that brings a completely different feel to the data being presented.

From the simple docs on the web page, it seems pretty straight-forward... you have to set up all the data for the graph, and then it just renders it. There are some nice mouse-over features as you dig a little deeper, but it's the casual nature of the presentation that really appeals to me:

I don't have a project yet that's in need of this, but I can feel that there will be something coming soon that could really use this less-serious approach to data presentation. After all, not everything is a publication-ready presentation.