1. A new new new blog

    Wed 17 June 2020

    Yeah it's another blog update, just really some style updates and looking back at something I did a long time ago and say what the heck was I thinking?. I don't know, I think things that I don't have time to spend up usually end up being a craptastic design by copy-and-paste. Anyway, still using Pelican but upgraded to Python3 and fixed the CI configuration a bit. Got rid of the bourbon/{sass,neat} mixins because that was so 2013. Still using sass though.

    Oh and remove as much as possible like javascript easter-eggs and social links, because who needs that stuff :)


  2. The stages of a side project

    Wed 17 June 2020

    One experience of mine, though it has roughly mapped to previous side projects:

    • Wow this thing that has no business model is a cool idea, I wonder if anyone has done it before?
    • This is fun, let's spend an evening hacking on it
    • Wow this is taking way more time than I thought it would ...
    • Can I do this without spending any money? Let's use AWS free tier to get this going
    • OK let's ship this thing, wow it's getting a lot of attention! Front-page on hackernews, subreddit, etc.
    • I'm totally ready for this, I have a scaling plan
    • Oops my scaling plan is completely useless because the bottlnecks are not where I expected they would be
    • Wow traffic really drops off when it isn't on hackernews 🤔
    • Oh wait someone tweeted it, there goes traffic again..
    • I should probably add CI to make this a bit easier to maintain
    • OK things are stable again
    • Wait my free tier is about to expire, let's figure out how to host this for free by using multi-cloud
    • Whoa this is taking longer than I thought
    • .. years pass
    • OK something is broken and getting some email complaints, I really have lost interest in this thing
    • Have a free weekend, let's look at the code from years ago
    • Good god, it's terrible
    • Well, a bunch of things are now deprecated, let's at least fix that
    • OK so if I am going through this trouble I should probably re-write some of it, especially the last parts that were just thrown together...
    • Whoa this is taking longer than I thought...

    Introducing a newer version of cmdchallenge .. A lone survivor in a sea of broken things I have had an itch to build.


  3. Never use git submodules

    Wed 17 June 2020

    I'm writing this as a reminder to my future self never to use git submodules. For most things I would say never say never but let's make an exception for this one.

    I've used submodules for the following reasons:

    • There is some logical separation or a clear defined interfaces between two things, and repos are cheap
    • There is a 1 to many (usually 2 or 3) relationship between this thing (that has stable interface) and something else

    The problem is that this 1-to-many thing usually starts as 1-to-2 and usually doesn't go much further than that. It's always this could eventually increase in scale but usually those hunches are wrong.

    So where does it fall down? It seems like it rarely works well:

    • Cognitive overhead for multiple git commands to keep things updated
    • Doing normal things with git (conflict resolution, reviews, etc) feels super clumsy
    • With reviews, it often means reviewing multiple times and messes up approval workflows
    • It's 2020 and this process still looks unnecessarily complex https://stackoverflow.com/questions/1260748/how-do-i-remove-a-submodule

    My alternative for now for better gitops workflows is mono-repo everything, this seems to work better with CI anyway


  4. Using GitLab CICD for your static blog

    Tue 05 June 2018

    In the process of making all of my private repositories public on Github and moving off of GitHub pages I have also decided to move most of my repos over to GitLab. One reason is that setting up a CICD pipeline makes it extremely easy to publish these posts automatically. This in combination with GitLab's web IDE makes minor changes a little bit easier to make.

    CICD piplines in GitLab are controlled with a single file, .gitlab-ci.yml that is placed at the root of the repository. Wit this file, on every commit, the following pipeline runs that deploys to draft.jarv.org and on the master branch for jarv.org.

    GitLab has integrated CI/CD runners that allow you to execute whatever you want in a docker image of your choice for generating a deployment pipeline.

    Here is what the gitlab-ci.yml configuration looks like for the jarv.org repository:

    Some notes about the setup:

    • There are two stages, build and deploy. Build generates the html for the blog and deploy deploys it to both draft and the main site.
    • Deploying to the main site only happens with a manual job
    • I am using a custom image that has some of the blog dependencies pre-installed, it is created with this docker file.
    • Every time the deploy happens, an invalidate is sent to the cloudfront distribution in front of it.
    • Since I am no longer using GitHub pages, the blog is hosted in an S3 bucket so the CICD pipeline does an aws s3 sync ... to get the static files on the bucket.

    There is a special key named environment that hints to GitLab that the stage is a deploy step. With this the URL provided will show up under operations->deployments like this:

    envs

    That's it! It couldn't be simpler and I think one of the nicest things about this setup is the ability to use the GitLab web ide to make quick changes.

    Disclaimer: I work for GitLab though the opinions here are my own.


  5. Removing all of my private repos from GitHub

    Thu 31 May 2018

    Today I decided to remove all private repositories from GitHub. Why? Interesting that having private repositories generally meant that I was not being as careful about managing secrets properly. Checking in API tokens, keys and especially cloud tokens into git never a good idea and looking through some of my old private repos I was doing exactly that. So for others who are interested in going from a developer GitHub account back to free I highly recommend doing it! Granted it's only $5 a month savings but I definitely feel a bit more transparent than I did 15 minutes ago. :) For finding secrets you can use something like trufflehog to ensure that there no sensitive bits in your git history.


Page 1 / 4 »