This originally appeared on Marty Henderson’s personal blog

Or, how to use Gitpod and GitLab so that no one else has to care about your questionable coding language choices. A true rockstar has a good developer experience!

Example Repo

For the impatient – Gitpod launch link

Alright, in this we’re going to break down a little project I did that leverages Gitpod, GitLab and the sensational hair band programming language Rockstar.

…Rockstar? Really, Marty?

Yes. Rockstar in summary is a programming language that uses 80’s music terminology to create code. It works with several different interpreters and was all started because of a tweet asking about a Rockstar language so that people could say they were “Rockstar Developers”. However, it’s definitely not a production language, lacking certain first-level functions we’d expect and is, quite frankly, rather ridiculous and verbose to accomplish the same thing.

I chose this, specifically, because you don’t want this in your IDE. You probably don’t want to install Node (if you don’t have it) and then install this interpreter just to go through a FizzBuzz-like example of a language in which My desire is an explicably dizzyingly jackhammer is actually acceptable variable assignment. However, if you saw my previous blog post on Ring Road you might be expecting Gitpod. And you’d be right.

So the example repo for this is here with a handy button to launch Gitpod. (If you don’t have a gitpod account, you can sign up for free, and no matter if you use GitLab, Github, or BitBucket, you can access that repo).

Are you going to teach Rockstar?

No. The point of this is not to teach you how poetic literals work or argue about whether they should include modulo (they shouldn’t). If there’s demand, I can break down why the script works, but it’s pretty much an implementation of their FizzBuzz example with a variable that gets reassigned (more Python than Clojure here!).

What are we trying to solve?

There’s an excellent site called Project Euler of interesting math problems that you can explore and solve. It’s a good way to practice coding, for sure, and the first one is very similar to the FizzBuzz example that most developers have seen.

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

So, instead of reporting Fizz or Buzz (and FizzBuzz) on every multiple of 3 and 5, we’re adding them together and doing a single output. This is way, way easier to script in things like Python and Clojure.

Python:

    def multiples_of_3_or_5():
        for number in xrange(1000):
            if not number % 3 or not number % 5:
                yield number

    print sum(multiples_of_3_or_5())

Clojure:

(println (->> (range 1000)
(filter #(or (= (mod % 3) 0) (= (mod % 5) 0)))
(apply + )))

However, on top of it, no one has Rockstar installed on their machine. So, let’s setup our environment with Gitpod!

Gitpod Configuration

So, here’s what I am rolling out

tasks:
  - name: Rockstar Setup
    init: |
      git clone https://github.com/RockstarLang/rockstar && 
      npm --prefix rockstar/satriani install &&
      gp sync-done setup
    command: echo "Stage is set!"
  
  - name: Rock Out
    init: gp sync-await setup
    command: node rockstar/satriani/rockstar three-or-five.rock

vscode:
  extensions:
    - TabNine.tabnine-VSCode

The Gitpod workspace by default has Node, so I didn’t need to install that (nor git), but it lacks the rockstar interpreter.

The first step (Rockstar Setup) grabs the Rockstar interpreter, clones it down, and installs it. Of note, I am leveraging --prefix so that I don’t have to change directories. Another point is that it’s lifting the gp sync-done with a sync named setup (a name I chose and not protected). This is because if you try to run the node command in “Rock Out” before it’s installed, the terminal will light up like a Christmas Tree whose only presents are disappointment.

However, once the npm install is done, it lets the Rock Out step know to run and that invoked the command to interpret and present the code for the three-or-five.rock file written.

All of that runs before you get your hands into the code, meaning your environment already has this setup and has ran the main script once—when you run it, you should have “my number is 233168”, which is the solution. This means before you did anything at all, it setup your environment and ran the code for you.

I also included TabNine. Of note, the Rockstar plugin isn’t on Open VSX, so I couldn’t include it as the open VS Code that Gitpod uses does NOT use the closed Microsoft plugin system.

Okay, cool, so you have a solution and an IDE. You’re almost a Rockstar! One more little thing.

GitLab Integration

Rockstar, yes, includes tests for the interpreter. We should definitely run them. But I am very lazy and would prefer to type as little in the terminal as possible. So, I have GitLab do it for me.

The GitLab CI file in there is pretty straight forward, but includes a few cool features that make GitLab very useful. Here’s what I am bringing to the stage:

stages:
- build
- test
- production
sast:
  stage: test
include:
- template: Security/SAST.gitlab-ci.yml

build_env:
  stage: build
  image: node:15
  script:
    - git clone https://github.com/RockstarLang/rockstar 
    - npm --prefix rockstar/satriani install 
  artifacts:
    paths:
      - rockstar/


yarn tests:
  stage: test
  image: node:15
  needs: 
    - job: build_env
      artifacts: true
  script:
    - yarn --cwd rockstar/satriani/ test

produce answer:
  stage: production
  image: node:15
  needs: 
    - job: build_env
      artifacts: true
  script:
    - node rockstar/satriani/rockstar three-or-five.rock

This allows us to run tests and run the code, but without needing a ton of steps and as quickly as things are available.

You’ll notice that SAST is included for free. It doesn’t work on Rockstar, but I throw it on all my projects to detect potential vulnerability. Much like locking your computer when you step away from it, it’s just a good habit.

So, during build, you’ll see that it has an artifacts keyword. GitLab can store all kinds of outputs, but for this here, it’s the generated Rockstar directory from installing the git repo of the interpreter. Since we’re storing that generated output and reusing it, we don’t need to run npm install for each step.

Both yarn test and produce answer have a needs: keyword. This means as soon as the build_env is done, they can trigger. This is called a Directed Acyclic Graph which is a way of saying that events are related to other events (yes, mathematicians, I did just try to distill graph theory down. Please forgive me!). In this case, as soon as the event that needed to be done is completed, this step can continue.  GitLab introduced this recently with DAG and needs and offers a slick visualization in the pipeline graphs. Ours, however, looks, much more simple.

GitLab Pipelines

However, you can chain these deep but don’t need to wait, they can do all the pipelines without needing intervention. In this case, as soon as the artifacts are built, the yarn tests run and the answer is also produced.

These pipelines are super simple but can make it easy to test and run production (and development) environments and keep you from waiting to install libraries each and every time, but still get a fresh copy each time the pipeline runs, regardless of number of steps.

Also, working on a Merge Request and want to see the code? Throw the branch name in Gitpod or in GitLab, change the drop down to Gitpod and actually look at the code being brought in. It really does help you keep the flow of approvals going without needing to rebuild your environment each time.

Gitpod drop down in GitLab

Well, what did we learn?

You can deliver code that needs to have various libraries installed and make it available via Gitpod for anyone to use and only need to build it once in Gitlab for it to work everywhere. No one doing this experiement had to do anything more than open two browser tabs to have their hands on code and see it run and build. Really, a true rockstar keeps the tech barriers out of the way to focus on coding and sharing what you do with others. Help your colleagues, leaders, and mentees by making your code easy to access, test, and validate.

Also, writing in Rockstar definitely makes you a Rockstar Developer for all those “hip” job postings on LinkedIn. Be proud you Rockstar!

About the Author

Marty Henderson profile.

Marty Henderson

Principal Technologist

Marty has spent 15 years in technology journeying across many regulated fields, primarily focused in security and platform. Outside of technology, Marty writes, tinkers with his home lab, and tries cooking recipes in languages he doesn’t speak.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Airflow Logging: Task logs to Elasticsearch
This is part three of a five-part series addressing Airflow at an enterprise scale. I will update these with links as they are published. Airflow: Planning a Deployment Airflow + Helm: Simple Airflow Deployment More […]
Using Nix as a Professional
How to use Nix as a tool to optimize developer time with real-life examples.
Enterprise Auth for Airflow: Azure AD
This is part three of a five-part series addressing Airflow at an enterprise scale. I will update these with links as they are published. Airflow: Planning a Deployment Airflow + Helm: Deploying the Chart Without […]
More Charts: Adding TLS to Airflow
In this post, we will be adding TLS to Airflow on Azure Kubernetes Service. This is part three of a five-part series addressing Airflow at an enterprise scale. I will update these with links as […]