Forem: Andreas Barbesgaard

Learn to ride a bike before learning to ride a motorcycle

Andreas Barbesgaard — Tue, 18 Mar 2025 08:07:06 +0000

Take everything with a gain of salt I'm a student leaning how to program

When I was 5 years old, I was learning how to ride a bike. A shiny day, the wind rustling through the leaves. My small body had to manage balance, the feel of the handlebars, and my father's encouraging cheers from the sidewalk. I turned my head to smile and bam - faceplant.

Now imagine if I had started on a motorcycle instead.

Dead before turning 6, I guess.

Why mention this? Because this analogy perfectly captures the relationship between learning to code and jumping straight to using Large Language Models (LLMs).

Just as we respect the natural progression from bicycles to motorcycles, I should approach coding with the same reverence for the learning process.

A child masters balance and basic controls on a bicycle before graduating to the power and complexity of a motorcycle. Similarly, I as a Developer, need to understand programming fundamentals before effectively harnessing LLMs.

When I, without fundamental skills, rely entirely on LLMs to generate code I don't understand, I've essentially placed my self in the shoes of a child riding motorcycles—unaware of the dangers and unprepared for the consequences when things go wrong.

The stakes have never been higher. Code is increasingly controlling critical systems in our world. Understanding what happens under the hood isn't just academic—it's essential for building safe, reliable software that won't endanger lives when it inevitably encounters edge cases and unexpected scenarios.

How to write dirty code

Andreas Barbesgaard — Fri, 25 Oct 2024 04:42:55 +0000

Are you sick of hearing about "clean code"?

Do you long for the good ol' days of cryptic variables, magical numbers, and code that looks like it was written by a very ambitious raccoon? Look no further!

Presenting: the ultimate guide to writing code that will make your colleagues cry and future you ask, “What in the world was I thinking?”

1. Use Incomprehensible Variable Names

Why settle for clear names like customerEmail or orderTotal when you can achieve peak confusion with x1 and totalStuff? The goal is simple: nobody (especially you) should be able to figure out what the variables mean in the future. Ambiguity is your friend.

Example: Let temp hold… something important. Or maybe not. That’s for others to figure out!

public class y
{
    public void x()
    {
        int x1 = 43;
        string y2 = "_,,_";
        var z3 = new List<int> { 1, 2, 3, 4, 5 };

        var yb = x1 + z3[1];  
        var x12 = ab(y2); 


        for (int i = 0; i < yb; i++)
        {
            tb(x12);
        }
    }

2. Avoid Comments Like the Plague

Comments are for those who lack confidence in their code’s mystique.

You wanna be dirty... and mysterious!

If you insist on commenting, keep it ambiguous: something like

//wtf
or
// ?

Your code should be dirty!

Bonus Tip: If you absolutely must add comments, make sure they’re misleading or redundant, like // fetch data here in a line where no data is fetched. You know, like the stuff you get back from LLM's.

3. Embrace the One-Million-Line Method

Who needs small, readable functions? One method should handle everything: data fetching, processing, updating the UI, and maybe even making coffee. If a function is under 500 lines, it’s practically under 500 lines.
Functions are like money a higher number is better!

def ult():
    u = gtdb()  # "u" for usrp

    s = sorted(u, key=lambda x: x['n'])  
    svdb(s)  # Save sorted stuff
    ui(s)  # Update 
    eml(u)  # Send emails to u <3

    t = 0
    for x in s:
        t += scr(x)  # Totally obvious!

    sui(t) 

    import datetime
    if datetime.datetime.now().hour > 23:
        nlm()  # Yes
this)
    l(u, s, t)  # Log

4. Forget Reusability

Reusability is for quitters. Copy that chunk of code everywhere it’s needed and tweak each one slightly, making future bug fixing an exercise in patience and detective work. Refactoring? That’s just a waste of time.

Pro Tip: Reinventing the wheel each time you code something slightly different builds character and job security.

5. The Magic Number Mystery

Constants are for the weak.

You should Hard-code values everywhere.

6. Bug Fixing is for Amateurs

If something doesn’t work, it’s probably user error. Don’t waste time "fixing" bugs. Leave them there to be discovered later when they’re much harder to diagnose. The trick is to bury them so deep, not even Sherlock Holmes could track them down.

Bonus: If someone insists on a bug fix, sprinkle a few try-catch blocks around that silently ignore exceptions.

7. Tests are Overrated

Testing code is for people who don’t trust their own genius. Who has time to check if things work? Why even ask this question? It works on you computer right?

Pro Tip: If anyone dares mention unit tests, nod, smile.

THE M.O.I.S.T Principle

Andreas Barbesgaard — Thu, 24 Oct 2024 07:59:13 +0000

TLDR
The MOIST principles provide a balanced approach to writing code that prioritizes clarity, maintainability, and readability. While the DRY principle focuses on minimizing repetition, MOIST acknowledges the practical need for some redundancy to achieve these goals.

Before you dive into this incredible article, a quick word from our sponsor: RAID: Shadow Legends! Yes, that game you've definitely heard about. Immerse yourself in its thrilling graphics and captivating gameplay. And, of course, don’t forget to use the code '/s' for absolutely no reward.

Meaningful

Ensure that the code has purpose and context, even if it means some repetition to enhance clarity.

Organized

Keep the code well-structured and easy to navigate, which might involve some necessary redundancy.

Intentional

Be deliberate with repetitions, understanding when they serve a functional or communicative purpose.

Simplified

Advocating for simplicity and clarity in code design and implementation.

Transparent

Make the code’s intentions clear, even if this means duplicating logic to make it more understandable.

Meaningful

Ensure that the code serves a clear purpose and is provided with context, while avoiding unnecessary repetition that could obscure its intent.
Meaningful code is characterized by well-chosen names for variables, functions, and classes, promoting readability and aiding other developers in understanding its purpose.

Following Robert Martin’s Clean Code philosophy, emphasis is placed on self-explanatory code, enhancing clarity and purposefulness. By keeping related behavior localized, the code becomes easier to understand without requiring developers to jump across the codebase.

// Example of meaningful code with clear purpose and context

public class Rectangle
{
 public double Length { get; }
 public double Width { get; }
public Rectangle(double length, double width)
 {
 Length = length;
 Width = width;
 }
public double CalculateArea()
 {
 return Length * Width;
 }
}

Organized

Maintain a well-structured codebase that is easy to navigate, minimizing redundancy where possible.

Organized code follows a logical structure with distinct separations of concerns, reducing the need for duplicated setup or initialization code across different modules.

Martin Fowler’s iterative approach suggests refining the code’s structure over time, starting with initial organization that may include redundancy, which is then fine-tuned during refactoring.

By keeping related functions and data close together, the code becomes more understandable and easier to reason about.
// Example of organized code with a clear structure

public class Rectangle
{
 public double Length { get; }
 public double Width { get; }
public Rectangle(double length, double width)
 {
 Length = length;
 Width = width;
 }
public double CalculateArea()
 {
 return Length * Width;
 }
}

Intentional

Be deliberate in the use of repetitions, understanding when they serve a functional or communicative purpose.

Intentional repetition ensures that redundant code is included for a reason, such as enhancing readability or aiding future maintainers in understanding the code.

While Clean Code advises against unnecessary repetition, it also emphasizes that readability should not be sacrificed solely to avoid redundancy. Intentional repetition aligns with this nuanced approach, allowing for initial clarity before refactoring to eliminate unnecessary duplications while preserving intent.

By keeping related logic together, intentional repetition makes behavior more localized and easier to follow.
// Example of intentional repetition for clarity

public class Greeting
{
 public void Greet(string name)
 {
 Console.WriteLine($"Hello, {name}!");
 Console.WriteLine($"Welcome to our website, {name}!");
 }
}

Simplified

Maintain simplicity in the code structure, even if it occasionally results in redundant segments to enhance clarity and ease of maintenance.

Simplified code prioritizes readability by reducing complexity and avoiding unnecessary abstractions.

Robert Martin advocates for simplicity as a core principle of Clean Code, encouraging straightforward and understandable solutions.

By minimizing cognitive overhead for developers, simplified code supports maintainability, making it easier to debug, refactor, and extend. Starting with straightforward implementations and refining them over time fosters a better understanding of the system’s behavior and facilitates collaboration among developers.
// Example of simplified code with reduced complexity

public class PrimeChecker
{
 public bool IsPrime(int n)
 {
 if (n &lt;= 1)
 return false;
for (int i = 2; i &lt;= Math.Sqrt(n); i++)
 {
 if (n % i == 0)
 return false;
 }
return true;
 }
}

Transparrent

Ensure clarity in the code structure and logic, even if it requires duplicating certain aspects to enhance understandability and ease of maintenance.

Transparent code makes its purpose and behavior explicit, prioritizing understandability for anyone reading it. By reducing cognitive load, transparent code makes it easier to comprehend, debug, and modify.
Supporting the principle of locality of behavior, transparent code keeps related logic together and ensures the purpose of each code segment is evident.

By aligning with principles such as self-documenting code and expressive programming, transparent codebases are easier to maintain, understand, and extend over time.
// Example of transparent code with clear logic and purpose

public class PriceCalculator
{
 public double CalculateTotalPrice(double[] prices, int[] quantities)
 {
 double total = 0;
 for (int i = 0; i &lt; prices.Length; i++)
 {
 total += prices[i] * quantities[i];
 }
 return total;
 }
}

Conclusion

Following the MOIST principles provides a balanced approach to writing code that prioritizes clarity, maintainability, and readability. While acknowledging the need for some redundancy, MOIST ensures that clarity and intentionality are maintained throughout the codebase. By adhering to MOIST principles, developers can create code that is both clear and maintainable, promoting collaboration and reducing the risk of errors.

Sources

Clean code

martin Flowers book on refactoring

Locality of Behaviour

Mine 14 dage med Cursor

Andreas Barbesgaard — Thu, 24 Oct 2024 04:40:36 +0000

Introduktion

Disclaimer! Jeg er i gang med datamatikeruddannelsen og er ikke endnu uddannet.

Da jeg så, at Cursor IDE var det nyeste og mest hypede værktøj, besluttede jeg mig for at prøve det. Cursor præsenterer sig som en IDE med en fuldt integreret LLM, der skal gøre kodning hurtigere og smartere — i hvert fald ifølge deres løfter.

Mit mål med at afprøve cursor var at finde ud af hvad der gør denne IDE så interessant i forhold til fx VS Code med Copilot plugin.
Kort oprids af funktioner

Kode generering

For mig minder dette om det man kan finde allerede hos Copliot. En slags intellisense på steoider.

Multi-line Ændringer

Denne funktion har jeg ikke benyttet mig. Men der er da smart.

Smart Rewrites

Som en nybegynder er dette som sendt fra gud(eller Ai overlords), at se den rigtige syntax komme frem for øjnene af én er igen — smart.

CTRL+k

Min mest brugte funktion var CTRL+k

Denne gjorde det muligt for min nye Ai-ven at hurtigt redigere en markeret kode og rette den til med en prompt man smider ind lige over den kode man ønsker ændret — og så flyver robotten ellers ned gennem koden og ændrer alt det kode man ellers var så stolt af at have kommet frem til.

Stakkels Tab

Min erfaring med Cursor

Når jeg arbejdede med Cursor, opdagede jeg, at det ikke handlede så meget om at skrive kode, men snarere om at læse den. Cursor præsenterer dig konstant for forslag og genereret kode, hvilket betyder, at min Tab-tast blev den mest brugte knap på mit tastatur.

Men her er problemet: Når jeg bruger mere tid på at læse kode i stedet for at skrive den, mister jeg noget af mit fokus. Det er let at blive fanget i at godkende forslag uden nødvendigvis at forstå alle detaljerne.

Når det er sagt, så er Cursor imponerende hurtigt til at tage dine idéer og omsætte dem til kode. Der er ikke langt fra tanke til udførsel — men det kræver, at du allerede har en god forståelse for kodningens grundprincipper. Hvis du er rutineret og har et solidt greb om best practices, kan Cursor være et fantastisk værktøj.

For en som mig, der stadig er under uddannelse og ikke har mange års erfaring med programmering, kan Cursor dog være overvældende. De mange funktioner og automatiske rettelser gør det svært at følge med i, hvad der præcist sker i koden. I stedet for at lære ved at skrive, ender man med at lære ved at læse — hvilket kan føles som en hæmsko, når man stadig er i gang med at lære det grundlæggende.
Opsummering

Cursor er uden tvivl et kraftfuldt værktøj, især hvis du allerede er en erfaren udvikler. Den korter afstanden mellem idé og udførelse, og den integrerede LLM kan spare tid ved at generere kode og rette fejl. Men hvis du, som jeg, stadig er under uddannelse eller er ny inden for programmering, kan Cursor give mere hjælp, end du egentlig har brug for. Det kan få dig til at miste overblikket og fokusere for meget på maskinens forslag frem for din egen læring.

Mit råd til andre studerende ville være at bruge Cursor med omtanke — og kun når du er klar til at forstå de forslag, du bliver præsenteret for.

7 Principper for Microservices

Andreas Barbesgaard — Thu, 24 Oct 2024 04:29:33 +0000

Sam Newman’s principper for microservices fokuserer på at skabe en arkitektur, der er fleksibel, skalerbar og robust. Hans tilgang tager udgangspunkt i en række principper, som hjælper med at sikre, at systemer kan tilpasses forretningsbehov og udvikles på en effektiv måde.

1. Modelleret ud fra `business domain`

Microservices bør organiseres omkring forretningsdomæner snarere end tekniske krav. Ved at modellere services omkring forretningskapaciteter, kan teams fokusere på specifikke domæner som kunde-, ordre- eller produktstyring.

Systemet bliver mere fleksibelt og let at vedligeholde, fordi hvert domæne kan udvikles og ændres uafhængigt. Denne tilgang fremmer også domain-driven design (DDD), som hjælper med at sikre, at teknologien understøtter forretningsmålene direkte.

2. En automatiseringskultur

Automatisering er afgørende i en microservices-arkitektur, især når det kommer til test, deployment og overvågning. En stærk CI/CD-pipeline (Continuous Integration/Continuous Deployment) gør det muligt at implementere ændringer hurtigt og pålideligt.

Risikoen for menneskelige fejl bliver reduceret og sikrer, at nye versioner af en service kan distribueres hyppigt. Automatiseringen skal også inkludere overvågning, fejlhåndtering og skalering, så tjenester kan reagere automatisk på ændringer i belastningen eller fejl.

3. Gem implementeringsdetaljerne

Hver microservice skal være isoleret, hvilket betyder, at de skjuler deres interne implementeringsdetaljer fra resten af systemet. Dette koncept kaldes også encapsulation.

Andre services bør kun interagere med en given service gennem veldefinerede API’er. Ved at skjule implementeringen kan den interne logik ændres eller optimeres uden at påvirke andre dele af systemet.

Det giver fleksibilitet i forhold til teknologi, da forskellige services kan bruge forskellige programmeringssprog, databaser eller andre teknologier, uden at det påvirker hele systemet.

4. Decentralisér alt

Decentralisering er kernen i microservices-arkitekturen. I stedet for en centraliseret database eller governance, har hver service kontrol over sine egne data og sin egen teknologi.

Beslutninger træffes lokalt, hvilket øger fleksibiliteten og gør det muligt at vælge den bedste løsning for hver enkelt service. Samtidig kan forskellige teams arbejde selvstændigt, hvilket reducerer behovet for koordination og forbedrer udviklingshastigheden.

5. Deploy enkeltvis

En af de største fordele ved microservices er muligheden for at implementere hver service separat. Når en enkelt service skal opdateres eller skaleres, kan dette gøres uden at påvirke andre services i systemet.

Denne uafhængighed muliggør hurtigere implementeringscyklusser, færre fejl ved deployment, og en generel højere grad af fleksibilitet. Det kræver dog, at infrastrukturen understøtter denne form for selvstændig implementering gennem automatiserede deployments, test og overvågning.

6. Isolér fejl

Fejlisolering er et afgørende aspekt af en microservices-arkitektur. Ved at sikre, at fejl i en service ikke spreder sig til andre dele af systemet, forbedres systemets robusthed.

Teknologier som circuit breakers og retries kan bruges til at beskytte mod kaskadefejl. Hvis en service fejler, bør systemet stadig kunne fungere delvist, måske med reduceret funktionalitet.

7. Observér alt

Microservices-arkitekturer kan være komplekse, og derfor er omfattende overvågning afgørende. Dette indebærer at have synlighed i hver enkelt service, inklusive dens ydeevne, fejl, afhængigheder og brugerinteraktioner. Ved at observere alt kan teams hurtigt opdage problemer og reagere proaktivt.

Jeg forstår det simpelthen ikke

Andreas Barbesgaard — Wed, 23 Oct 2024 12:11:25 +0000

Op til eksamen på 1. år af datamatikeruddannelsen havde jeg tankerne kørende rundt i mit hoved, fordi jeg ikke havde nogen idé om, hvad der foregik i min kode, når jeg trykkede på start. Jeg vidste, at når jeg trykkede på knappen, så kørte programmet, og på magisk vis kunne min computer forstå den kode, jeg havde skrevet, og variablerne, jeg havde erklæret, samt ændre dem løbende. Men hvordan?

Jeg havde brug for et program eller en løsning, der gjorde, at jeg kunne se den kode, jeg havde skrevet, aktiveret, når jeg interagerede med de forskellige elementer i mit system. Det var ikke nok for min forståelse at se bilen køre; jeg ville se, hvordan motoren så ud, når den startede, når jeg trykkede på bremsen, og når jeg accelererede.

Jeg søgte på nettet efter en løsning og fandt ud af, at C# har en umiddelbart god løsning til dette formål:

Debug.WriteLine();

Jeg brugte denne metode flittigt i min kode.

Når jeg startede en metode op så skrev jeg

Debug.WriteLine("MethodName");

Det fungerede fint. Men strukturen i de beskeder, jeg modtog, var ofte meget simpel og kunne se således ud:

Metode1 start
variable1 = 1
Metode1 Slut

Og hvis du forestiller dig en ordentlig røvfuld metoder der sparker i gang, blev dette ikke lettere at læse.
Jeg manglede struktur i mit kodes debug-output. Derfor valgte jeg, lige inden eksamen, hurtigt at sammensætte et bibliotek, der senere kom til at hedde Debugland (mere om det senere).
Dette gjordre at min debug log kom til at se sådan ud:

[Metode1]
  - Initiated
  - The Variable Sovs has been declared with a value of Hollandaise
[/Metode1]

… og ved flere metoder, så koden sådan ud:

[Metode1]
  - Initiated
  - The Variable Sovs has been declared with a value of Hollandaise
  [Metode2]
    - Initiated
    - The Variable tilbehør has been declared with a value of fritter
  [/Metode2]
[/Metode1]

Denne struktur fungerede super godt for min forståelse af, hvad der skete, når jeg interagerede med mit system. Jeg fik svar på de spørgsmål, jeg havde til min kode, om hvad der præcist skete, når forskellige processer blev aktiveret under "kølerhjelmen" af systemet.
Det eneste problem ved implementeringen af Debugland i ens kode er, at det kan fylde ret meget. Når det er sagt, har det været guld værd for min forståelse af, hvad der sker under runtime.

Debugland

Som jeg lovede tidligere er her en lille præsentation af det bibliotek jeg lavede.

Udfordring

Jeg manglede en stuktur i den måde jeg fik vist de beskeder som jeg fik tilbage fra systemet når jeg kørte programmet.

Løsning

Lav en "wrapper" til C#'s Debug, som omslutter sprogets output i en mere struktureret form.

Kode kode kode

Det hele starter med MethodInitiated metoden fra biblioteket

   [Conditional("DEBUG")]
   public static void MethodInitiated(string methodName)
   {
        // Store the initial Debug.IndentLevel
        int initialIndentLevel = Debug.IndentLevel;

        // Writes the name of the method to the debug window for the initial level
        Debug.WriteLine($"[{methodName}]");

        // Enter the loop starting from 1 to initialIndentLevel (including 0)
        for (int i = 1; i <= initialIndentLevel; i++)
        {
            // Adjusts the Debug.IndentLevel for each iteration
            Debug.IndentLevel = i;
        }

        // After the loop, reset Debug.IndentLevel to the initial value
        Debug.IndentLevel = initialIndentLevel + 1;
        Debug.WriteLine($"{(char)26} initiated");
   }

Denne sætter indenteringen for resten af koden og skriver at metoden, som man gerne vil vide mere om, er "initiated".
Det er dog vigtigt her at man altid for afsluttet med MethodTerminated metoden, da indenteringen ikke vil forløbe korrekt.

 [Conditional("DEBUG")]
 public static void MethodTerminated(string methodName)
 {
        // Gets the initial IndentLevel
        Debug.IndentLevel += 0;
        // unindents
        Debug.Unindent();
        // Writes the name of the method to the debug window.
        Debug.WriteLine($"[/{methodName}]\n");
}

Og for mig var dette hele hulmen for at kunne få fornemmelsen af hvilken metode der aktiverede i en anden metode, som ændrede en variabel der gjorde gud ved hvad.

En Implementering af dette kunne for eksempel se sådan ud:

public void Metode1(int number)
{
  Debugger.MethodInitiated(nameof(Metode1));
  Debugger.MethodParameter($"{number}");
  int a = 1;
  Debugger.Variable("a",$"{a}");

  Debugger.MethodTerminated(nameof(Metode1)); 
}

Rigtig mange linjer skal til for at man får fornemmelsen af hvad der sker. Men dette gav mig syn for sagen og jeg bruger ikke nær så mangler linjer mere.

Dette vil give følgende output, hvis vi siger at metoden aktiveres på følgende måde Metode1(1)

[Metode1]
  - Initiated
  - Parameter value was: 1
  - The Variable a declared with the value of 1
[/Metode1]

Dette har været et uundværlig redskab for mig i arbejdet med forståelsen af hvad der sker når kode aktiveres

Nyt i Debugland

I den nyeste implementering er jeg gået til hvordan man får præsentereret fejl i C#. For mig er det nærmest latin.

Error reading the file. ---> System.IO.FileNotFoundException: Could not find file 'nonexistentfile.txt'.
   at System.IO.FileSystem.OpenFile(String path, FileMode mode, FileAccess access, FileShare share)
   at System.IO.File.ReadAllText(String path)
   at Program.Main(String[] args) in C:\path\to\your\file.cs:line 10

… altså, hvis jeg kigger efter kan jeg da godt forså det. Men det er jo det. Jeg skal se efter. Jeg vil bare gerne have en lyn hurtig besked om hvad fejlen er, hvor den er og hvordan den eventuelt kan løses.
Jeg er kommet frem til følgende struktur:

1 |   Exception Occurred in ---> [TestExceptionMethod]
2 |   Time Stamp: 10/21/2024 8:51:16 AM
3 |   
4 |   Message: Test exception occurred
5 |   Source: TestProject
6 |   Target Site: Void LogException_Should_Format_Exception_Details_Correctly()
9 |   Inner Exception:
- |   Message: Inner exception occurred
- |   Source: 
- |   Target Site: 
14|   Method: at TestProject.DebuggerTests.LogException_Should_Format_Exception_Details_Correctly()
15|   File Path: /home/andreas/Documents/Projects/Debugland/TestProject/DebuggerTests.cs
16|   Line Number: 45
17|      throw new Exception(exceptionMessage, new Exception(innerExceptionMessage));

Dette er work in progress og er ikke langt op i repo endnu.

Mit arbejde med Debugland har været en rejse mod bedre forståelse af, hvad der sker under overfladen, når kode udføres. Ved at implementere en struktureret tilgang til debug-output har jeg ikke blot opnået indsigt i mine metoder og variabler, men også fået mere tillid til min evne til at identificere og rette fejl.
I takt med at jeg udvikler Debugland videre, håber jeg at kunne dele dette værktøj med andre, der står over for lignende udfordringer. En klar og struktureret måde at se, hvad der sker i koden, kan være afgørende for læring og fejlfinding, især for dem, der er tidligt i deres programmeringsrejse.

Jeg ser frem til at fortsætte med at forbedre Debugland og gøre det til en endnu mere værdifuld ressource for både mig selv og mine medudviklere. Med dette værktøj kan jeg lettere navigere i kompleksiteten af programmering og få det fulde udbytte af mine kodeskrivningsfærdigheder.

Tak fordi du læste med, og jeg håber, at mine erfaringer kan inspirere dig til at udforske og forbedre din egen tilgang til debugging og kodeforståelse.

link til Debugland
https://abarbesgaard.github.io/Debugland/

Forem: Andreas Barbesgaard

Learn to ride a bike before learning to ride a motorcycle

How to write dirty code

1. Use Incomprehensible Variable Names

2. Avoid Comments Like the Plague

3. Embrace the One-Million-Line Method

4. Forget Reusability

5. The Magic Number Mystery

6. Bug Fixing is for Amateurs

7. Tests are Overrated

THE M.O.I.S.T Principle

Meaningful

Organized

Intentional

Simplified

Transparent

Meaningful

Organized

Intentional

Simplified

Transparrent

Conclusion

Sources

Mine 14 dage med Cursor

Introduktion

Kode generering

Multi-line Ændringer

Smart Rewrites

CTRL+k

Stakkels Tab

Min erfaring med Cursor

7 Principper for Microservices

1. Modelleret ud fra business domain

2. En automatiseringskultur

3. Gem implementeringsdetaljerne

4. Decentralisér alt

5. Deploy enkeltvis

6. Isolér fejl

7. Observér alt

Jeg forstår det simpelthen ikke

Debugland

Udfordring

Løsning

Kode kode kode

Nyt i Debugland

1. Modelleret ud fra `business domain`