Okej! Du har kanske hört talas om Docker. Men har du hört talas om DevContainers? Paketera hela utvecklingsmiljön in i docker och koppla dig till den helt lagg-fritt från din lokala editor! Det borde vara vanligare än det är - låt oss se vad det handlar om...


Om du är riktigt inne i träsket har du kanske till och med hört talas om Docker compose. Det var i alla fall så långt jag hade kommit i "virtualisering" av min utvecklarvardag. Och ändå satt jag där för 10e gången på ett år och skulle försöka få någon antik kod med ett obskyrt frontend-ramverk att köra. Jag som egentligen bara ville implementera en ny feature i ett av våra interna system ute hos kunden. Slet mig i håret för att jag återigen behöver sätta mig in i byggsystem, dependencies, konventioner, avsaknad av linting/hjälpmedler för just det språket m.m. I grund och botten vet jag ju vad jag ska göra med koden, men att få det runt omkring upp och köra är ofta ett projekt i sig.

Detta är något som man ofta stöter på i rollen som konsult, eller som del av ett team som försöker skapa en snabbare onboardingprocess för ny anställda (eller inhyrda konsulter). Jag trodde detta bara var "som det var", och att lösningen hette "standardisering av projekt-setup" och en bra dokumentation i varje projekts README om hur man bäst kommer igång. Det var därför jag fort blev väldigt intresserad när jag läste om "DevContainers" för första gången.


Här är hiss-säljsnacket (elevator pitch):

Tänk dig att någon som har koll på allt med projektet, går in och konfigurerar din maskin och utvecklingsmiljö helt perfekt för att göra utvecklingsjobbet - du kan hoppa direkt på det som faktiskt är kul - utveckling av business logik/APIer och den nya fina frontenden.

DevContainers är ett sätt att definiera inte bara hur programmet kan köras i Docker, men också allt det runt omkring så som linters/plugins/package-hantering som förväntas finnas på plats i det givna IDE't som används. Jag kommer använda VSCode som exempel, men motsvarande teknologi finns för IntelliJ också.




Låt oss ha ett exempel. Jag är utvecklare på ett team där vi har ett projekt som har en Express webserver och en Postgres databas.
Då kan vi skapa en simpel DevContainer för detta. Filstruktturen ser ut såhär:



En devcontainer fil:

Med tillhörande docker-compose.yml och två Docker filer:





Om vi nu har ett repo med denna foldern incheckad, och en VsCode IDE där vi har laddat ner denna från CMD-SHIFT-P > Dev Containers




Så är det allt som ska till för att nu köra CMD-SHIFT-P > Dev Container: Rebuild Container Without Cache

Vi kan nu slänga ihop en simpel express applikation:



För att få någon data att jobba med, använder vi en feature av postgres databas-imagen som gör att man kan seeda data om det ligger i en speciell folder, så vi placerar följande i ./pg_init/init.sql
som vi kopierade in under /docker-entrypoint-initdb.d
i Dockerfile.pg tidigare.


Eftersom vi har "forwardat" port 3000, kan vi nu besöka localhost:3000/users  - och se där!



Detta är egentligen mest Docker compose magi, i kombination med den "init" featuren från postgres imagen som är ganska cool på egen hand.

Det fina är att vi nu också har den integrerade terminalen i VS Code. Denna kommer koppla upp sig mot den docker compose containern som vi har specificerat som service i devContainer.json filen. Här kanske vi skulle vilja använda psql för att kunna debugga fel i koden också, eller för att manuellt föra in mer data. Låt oss installera psql i vår devcontainer image:


När vi nu öppnar terminalen i VSCode, kan vi köra psql postgresql://postgres:postgres@localhost:5432/postgres och vi är nu kopplat mot Postgres databasen från samma container som vår Express app kör. Tänk vad najs nu när din kollega har några problem och du hoppar in på videomötet för att hjälpa: Du vet att hon har psql installerat så det är bara att börja att felsöka, istället för att sitta och installera det manuellt.


Det finns också stöd för att i devContainer-speccen beskriva vilka extension som ska vara installerade. Inuti devcontainers.json lägger vi till:



Vi kan nu köra CMD-SHIFT-P > Dev Containers: Rebuild Container Without Cache, alltså öppna kommand-paletten och köra dev containers kommandot för att bygga om hela DevContainern. När vi nu försöker skriva kod, får vi spell-check på det vi skriver. Vi får också "tab completions" som är en funktion i VsCode för att föreslå kodförslag om man trycker på TAB. Det får också alla andra som försöker röra denna koden och som använder sig av vår DevContainer. Nice!




Varför är inte detta vanligare där ute i det vilda?



Jag antar att det har lite att göra med att det kanske upplevs som en tröskel att sätta upp allt, eller att nuvarande setup fungerar "bra nog" för att det ska vara värt att lägga tid på. En bidragande faktor kan säkert vara att folk har sitt egna uppsätt på maskinen som fungerar för dem. De vill helt enkelt använda sitt IDE på sitt sätt och inte dra in massa config från någon annan. Men, egentligen förstår jag inte varför vi inte bara använder det här hela tiden - det finns inget bättre än när "någon" bara har fixat allt och jag kan börja koda. Samt att man får den skalerings-effekten av att om jag fixar vår DevContainer, så får alla nytta av det direkt. Fått en ny dependency, eller börjat använda en ny tool? In med det i DevContainern så alla kan få använda det. Jag är säker på att jag kommer försöka pusha för DevContainers nästa gång jag är ansvarig för att skapa ett nytt projekt/kodbas. Något vi inte hann gå igenom här, men som också är väldigt intressant, är att det inte finns något behov för att köra detta lokalt. Du kan ha DevContainern körande på en remote maskin eller till exempel GitHub Codespaces, som är en SaaS lösning som baserar sig på detta konceptet. Men mer om det en annan gång!

Har du några insikter/åsikter här? Dela gärna med dig!


Sammanfattning

Vi har nu skrapat lite på ytan av den här nya paradigmen som buntar ihop koden med dess kör-miljö, dependencies OCH utvecklingsmiljö på ett sätt som vi kan återanvända och checka in i Git. Vi har sett hur man med en grundinsats i början på ett projekt kan skapa förutsättningar för vem som helst att fortsätta utvecklingen utan att skapa massa problem på den personliga maskinen. Vi fick också sett lite snabbt på hur man enkelt kan få upp en test-databas och seeda den med data, samt felsöka mellan containers.

En släde kommer lastad med DevContainers!

Welcome to the seventh installment of Bekk Christmas

Welcome to our advent calendar. Or Christmas calendar. I never really figured out the politically correct way to phrase it. But it’s here. It’s jolly. And it’s full of original content. While the days become shorter and darker, enlighten yourself with bright ideas, thoughts and learnings.

Bekk has always been incredibly invested in our sharing culture. Our entire organization is rigged towards helping ourselves learning new things, discussing them with colleagues and sharing them with the industry. And bekk.christmas is one of the best ways this manifests itself for the people looking in.

This year, we’re happy to provide you with over 100 original articles, created exclusively for Bekk Christmas. They’re all produced by Bekk engineers, designers, strategists, product owners and team leads, sharing their insights and unique experiences with the rest of you – and reinforcing their learning as they do it.

You’ll find between 3 and 5 articles in both Norwegian and English most days, and we hope you learn something new from them.

If you’re a fan, make sure to share them with your colleagues.

Happy holidays to you all!

Bekk Christmas 7.0

After a while, some things just become tradition. That's why we're so excited to bring back our beloved advent calendar for the sixth consecutive year!

This year, like the years of Bekk Christmas' past, we'll share new original articles, podcasts, tutorials, listicles and videos every day up until Christmas Eve. It's all written and produced by us – developers, designers, project managers, agile coaches, management consultants, specialists and generalists, people with decades of experience and months of experience. 

Bekk Christmas is a wonderful blend of everything that's us. We learn by sharing, we talk about things that matter to us, and we do so to make both ourselves and you a bit better every day. We're sure you'll find something new to use in your day-to-day job.

We actually started early this year, meeting up for a full traditional Christmas dinner (with vegan options, this time!) way back in October, together with our beloved 10 meter tall inflatable Santa. We loved getting together to brainstorm, combine ideas or just talk to others about what they should share.

New features!

A new feature this year is that we've implemented a newsletter, to get the content of the day right in your inbox every day (or every week, if you prefer that). Make sure to sign up below!

We're starting to amass quite a few still relevant articles from previous years as well. If you want to go spelunking, check out the new categories view (which also includes a new, neat search feature), which will let you find cool stuff from the last 5 years as well.

So without further ado, we hope you enjoy today's articles, and that you come back a few more times this holiday season. 

Happy holiday wishes from the Bekk Christmas crew! 👋🎅

Welcome back to Bekk Christmas

Your true love might desire four calling birds for Christmas, but your colleagues do not have the same opportunity to raise their wishes. I suggest 4 pranks!


Although the 1st of April is still months away as I am typing this, a good prank is timeless and could very well be used today! Even if you wouldn't call yourself a prankster, it is never a bad idea to know what you're up against. Thus, I present to you 4 pranks of varying severity, use them at your own discretion.

1. Change a semicolon to a greek question mark

Someone once decided that they wanted to watch the world burn, so they designed the greek question mark exactly like the semicolon. Or perhaps it was the other way around. I dunno, ask a chicken 🐓<>🥚. We can take advantage of this to cause some havoc. Simply find a semicolon in your targets code and replace it with a greek question mark. If you don't have the greek question mark on your keyboard already, a simple trick is to copy-paste it from Wikipedia (or this article, here you go ; ). 

This will not work if your colleague is a Rust developer however, they actually went out of their way to prevent this. I'm betting there is a core Rust developer out there who was just a tad too frustrated of being victim to this prank.


2.  Install cloud-to-butt Chrome Extension

Installing an extension is a prank you can pull on almost anyone, and it is often very entertaining for both parties.

I once got to be a spectator to an extension-prank 5 years in the making. Suddenly, a furious mail ticked into a mailing list including me between student business relation volunteers and a developer. You see, for 5 years we had written that an external company were recruiting butt engineers. After some investigation, much giggles and some diplomacy, the culprit was revealed to be the cloud-to-butt extension which had processed all static text of the HTML-file the developer had tested a new web editor with ☁️.

If you haven't got the gist of it yet, what the cloud-to-butt extension does is to rewrite every occurence of "cloud" to "butt", and "the cloud" to "my butt". Which explains why you can store endless files in Google Butt 🍑.

So when your developer colleague just wants to quickly change a translation string and opts to do so through i.e. Githubs editor, you're in for a treat (and hopefully an entertaining review instead of a revert-commit).


Chrome Store

Firefox Marketplace


3. Alias cd to go somewhere random

Besides git status and ls, cd might be my most used command. It was thus an easy target when I naively left my computer unlocked to go get my coffee cup filled. Upon return, I expected nothing and was baffled when I failed to change directory to a subfolder of my project. Certain that my harddrive or terminal were completely whack, I gave the machine a quick reboot, met with much snickering from my colleagues. I then suspected foul (🦅) play, and indeed, I was the victim of this prank. 

To achieve this, you will have to edit your colleagues config file. In their terminal, navigate to their home folder through cd ~. Then, list all the content of the folder through ls -la. If you see a file named .zshrc there, you have found our target. If not, look for .bashrc. If both are non-existent, abandon all hope: your colleague uses another terminal configuration and is most likely too advanced for you.

To edit the configuration file, simply write open .zshrc or open .bashrc, depending on what you found in the previous step.
This should most likely open an editor with the file. To change cd, simply paste this into the bottom of the file and press save:



This finds a random subfolder of the current location, and either cds into that folder or cd upwards if there are no subfolders 😈

4. [object Object] in feedback forms

Known as the terror of JavaScript, [object Object] has been seen by many web developers when they try to print an object. Usually, one expects to see the content of the object, but are met by this beautiful work of art. 


It might also show up when you wrongfully deserialize an object as a string. As such, it can be quite entertaining to watch the one colleague that actually reads feedback pull their hair out trying to understand where the serialization/deserialization goes wrong.

Don't forget to change it up with a VPN, different browsers, etc. to really ensure that you are not easily detected.

What now?

If 4 pranks for christmas was not enough, you can expand your arsenal with 4 more, written by John Sparrow. You can read about them on his page. The sixteen other pranks of the christmas developer prank calendar is up to you! Look forward to your coal! ☃️



4 Ways to Prank Your Developer Colleagues 🤠

Another meeting where everyone feels like this is a waste of their time. Why could we not just have done this over email? Do we have to get everyone into a room (or even worse, a zoom room) to figure out whether or not to start on this task next week?

Photo by Rodeo Project Management Software on Unsplash

Well, I think the answer is more often than not "yes". It didn't have to be this way, but we made it like this, and now we reap what we sowed. There is a way out, but to get there we must understand why we sit through so many of these "pointless" meetings.

Why all the meetings?

So, your calendar is full of meetings, half of which you have no clue why you have been called in for, and the other half probably make you long for the sweet relief of Friday afternoon. This is your life now, unless you can find some way to make the rest of the company see the light. But why aren't they? The truth is, they know as well, but we have made a series of bad decisions along the way, making these meetings necessary.

Our emails are too long (or too short)

If this meeting could have been an email, how would that email have looked? Probably a mile long! With references, links to external and internal sources, 15 people on CC, and a dozen questions that needs answers. Just imagining it is enough to raise my blood pressure! That email was a pain to write, and now, 15 people have to take the time to read it and comprehend it. Taking into account the varying time available for this in everyone's schedule, it will take a lot of time for some to read it.

In the meantime, several answers just as long as the original email has arrived in your inbox, and we are off to the races. While you type up your 5000-word answer, someone else answers, and you have to spend an hour revising your answer to incorporate the new information and arguments. This can go on forever, and at some point, someone will email the group saying: "Can we schedule a meeting to clear this up?". And just like that, we are back to meetings, but not before having wasted a week with back and forth emails the length of Ulysses.

But this is not solved just by shaving down your emails to three lines. We end up with the same problem, in reverse. People need more information to be able to make a decision. And you will end up with a mountain of incorrect assumptions to fill the gaps in your explanation.

Writing a concise summary of an issue, that does not leave out any details needed for the decision, is an art mastered by few. In the world of politics it is a skill more often seen, as career politicians can't be bothered to read more than absolutely necessary, but also must have all relevant information available. Their advisors are highly trained (and paid) for this exact reason. We must adopt this skill if we are to have any hope of moving decisions from meetings to email.

Emails asking for a decision to be made are ignored

Having received the aforementioned wall-of-text email, knowing full well that John from accounting will have a lengthy reply with at least 10 new issues that are linked to this and must be resolved as well, I do what most people do: I wait. And why shouldn't I? There are no rewards for answering first, no incentive for me to start writing my thoughts on the subject, maybe not even a reason for me to start reading the email until a couple of days later.

This contributes to lengthening the response time, causing the sender of the questions to doubt if email was the right forum for this decision. You can guess what happens next: Meeting time!

We ask for decisions just in time

Email is an asynchronous medium. This means that the participants don't have to be active and present at the same time. This is great to ensure that we don't bother people when they need to focus. But it also means that we need to allow for enough time between sending a question, and needing an answer.

I for one don't get a lot of emails where 1) an important decision is to be made, and 2) there is an ample amount of time to make said decision. It is usually a question of how fast can we have this answer, we needed to report this to the board yesterday. This happens because there is too little slack in people's workdays. In order to maximise performance and efficiency, most people are given way more tasks than they could possibly complete, to ensure that there is no "wasted time" in their days. But this also leaves no room for deep thinking or reflection when an important decision has to be made. Instead, it is easier for everyone if a meeting is called, as it is naturally time boxed, and if anyone questions your time spent in the meeting, you can usually blame the person who asked you to be there.

Some things are difficult to convey in writing

If there is one thing I think we have all felt during the pandemic, it is that some things have been objectively more difficult while working from home. Sometimes it has been difficult to put our finger on exactly what, but I think it has to do with how we as humans communicate. A lot of our communication is nonverbal. When we see each other on camera in two dimensions, in low resolution, and with an infuriating latency, a lot of information is lost. It is the same when making decisions over email.

How certain is Pete that the solution he has proposed is actually going to work? If we sat in the room with him, we might see a flicker of doubt in the eyes, or shifting in the chair. It might be easier to admit that we are uncertain when we can see an gauge the reaction of our peers, instead of having to send that "I don't know" into the void, and wait for hours or days for a reply. And some processes are so complex that explaining them all in writing is just not worth it, and we need to have a conversation where the participants can ask the questions they need clarified in order to understand, while we can skip everything that is common knowledge.

Writing so that we are understood in the same way as when we speak face to face is difficult. It requires us to know the person (or people) we are writing to, and we need to be thorough in our choice of words. This, in addition to my earlier point on writing with the correct level of detail, increases the difficulty of writing an email that can actually replace a meeting. If The Boss is the one who needs an answer, and her calendar is already pressured, the efficient decision from her point of view is to call a meeting! Instead of spending hours formulating that perfect email, twenty minutes of explaining usually delivers the same results.

Leaders have the power to call meetings

With the above in mind, there is no wonder people would rather call a meeting. But there is one more factor that makes this happen. When your boss sends you an invite to a meeting, attendance is not optional. When was the last time you hit decline on a meeting invitation just because you didn't think the meeting would be worth your time? Probably never.

We have a culture where the person calling a meeting is usually a superior. Either your team lead, or the person in the team with the most experience. Most companies also don't have any guidelines regarding meeting invitations, and whether they can be declined, negotiated, or must be accepted. Fearful of the consequences, the easiest think is to accept.

To make matters even worse, meeting organizers usually "asks" for the attendance of all the people they think are necessary to resolve an issue, or that might be needed, should a tangent arise that needs answering. This is of course understandable from their perspective: Organise one single meeting where the issue at hand is presented and resolved. Unfortunately, this ensures that most people in the meeting have nothing to contribute and gather no new or useful information.

What to do then?

Well, first of all I think we should be careful to dismiss meetings as generally useless, as I feel some might be prone to. Second, we must adjust several things about how we work, and how we write:

There must be enough slack in peoples workdays to enable both good writing, high quality thinking, and generally space for new ideas. Without this, there is no hope of replacing a meeting with an email.

In addition, we must all become better writers. Whatever your actual job, you must write with the intention and eye for details of a political speech writer. Weighing your words, ensuring they are appropriate for your audience, and bringing out the essence of the issue takes practice, feedback, and time.

When these things are in place, we must also create a culture where declining meetings (with a polite notice of why) is not only acceptable, but expected when someone feels they have nothing to contribute to the meeting. The person calling a meeting must be able to convey why each person in the invitation needs to be present. Without a clear reason to be present, the default should be to spend our time elsewhere.

These are not overnight fixes. It will require leadership, buy in from everyone in the organisation, as well as a good portion of hard work. But if we do it right, we can reclaim our time from meetings, and actually make some real decisions by email!

No, this meeting couldn't have been an email – and we're all to blame

Bekk Christmas is the culmination of decades of iterating on sharing culture. Let's dive into what this is, and how it came to be.

Bekk Christmas is entering its fifth year, and with it, a fresh new take on how we share what we know. 

What is Bekk Christmas?

Bekk Christmas is an annual tradition, where we share some of the favorite things we've learned the last year, through opinion pieces, tutorials, podcasts, deep dives and lots of other formats. We focus on what we know, which is typically something about technology, design or strategy – sometimes all at once.

Each day in December, we'll share a curated selection of articles, podcasts, talks and whatever other format we felt like. Pick the ones that seem interesting to you, and consume them while you're commuting, relaxing, working or pooping. 

You'll also find hundreds of other articles, tutorials and podcasts on this site, available through either exploring our archives or using the nifty search feature.

Either way, we're sure you'll find something useful, interesting and fun here. We hope you enjoy.

What's the history behind Bekk Christmas?

Bekk Christmas didn't start out as Bekk Christmas - it started with going domain shopping over a few glasses of wine. Kristofer Giltvedt Selbekk started his React lead career by purchasing react.christmas, hacking together a solution in CodeSandbox, and publishing 24 short articles about React in 24 days.

React Christmas picked up some traction, and when the next holiday season arrived, three other competency leads wanted to join in. A tradition was born.

The following couple of years, Bekk Christmas turned into a company-wide project, with 23 calendars and 552 pieces of content. Each with their own .christmas domain! At one point, the owner of the .christmas TLD even asked to sponsor us for bringing so much traffic to their fringe TLD.

To us, this is such a great symbol of our company culture. We love to share, love to learn and can't wait to share it with you.

What's different this year?

Previously, we had a ton of different domains, like react.christmas, ux.christmas and strategy.christmas. It was a fun approach to get started, but we soon noticed that it came with its own set of issues. We had to make sure we had 24 days worth of content for each topic, which made a lot of people stress out. In addition, we had to maintain ownership over tons of fringe domains forever. Not great.

To alleviate this, we've moved all content to a single platform, with a single domain – bekk.christmas. It's still the same concept, but you can find all our content in a single place.

We've also rewritten the website from scratch, and moved all of our content into Sanity's wonderful content platform. We're super excited to show it all off.

Who is Bekk?

If you don't live in Norway, you probably don't know who Bekk is. That's completely fine. Bekk is a 500+ people consultancy that specializes in technology, design, strategy and management consulting. 

We've been around since 2000, and work with some of Norway's largest clients to help create solutions for millions of users. Without being too corporate-y, we think.

If you live in Oslo or Trondheim, and are looking for a job, please send us your resume!



Merry Christmas!

Finally, we just want to wish everyone a merry Christmas. Or happy holidays, if Santa isn't your jam. We hope you find some cool stuff, and share it with your network if you did. 

👋 

Kristofer, Vikki, Jørund, Kirstine, Ola, Beate and Anders
The Christmas Crew

Meta

En släde kommer lastad med DevContainers!

Bekk Christmas 7.0

Welcome back to Bekk Christmas

4 Ways to Prank Your Developer Colleagues 🤠

No, this meeting couldn't have been an email – and we're all to blame

Welcome to a brand new Bekk Christmas