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.
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.
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!