You've probably experienced this frustration: you ask Claude, Cursor, or any AI coding assistant to write a function, and it confidently generates code that looks perfect at first glance. But when you try to run it, you discover missing imports, undefined variables, or subtle syntax errors that your IDE would have caught immediately with those familiar red squiggles.

The fundamental issue? AI assistants like Claude work with raw text. They don't have the semantic understanding of code that your IDE provides through Language Server Protocol (LSP). They can't see what symbols are actually defined in your codebase, which imports are missing, or where functions are actually located across your project files.

This is where Serena comes in—and it might just be the missing piece that transforms how AI assistants handle code.

What Makes Serena Different?

Serena is an open-source coding agent toolkit developed by Oraios AI that bridges this critical gap. Instead of treating code as plain text, Serena leverages the same Language Server Protocol that powers your IDE's intelligence features.

The LSP Advantage

Think about what your IDE can do:

• Jump to definitions across multiple files

• Find all references to a function or class

• Auto-complete with context-aware suggestions

• Show you errors before you even run the code

• Navigate complex codebases with semantic understanding

Serena brings these exact capabilities to AI assistants through LSP integration. When Claude uses Serena, it's no longer flying blind—it can actually "see" your codebase the way a seasoned developer using a professional IDE would.

How Serena Works

At its core, Serena implements the Model Context Protocol (MCP), which allows it to integrate seamlessly with Claude and other AI assistants. Here's what happens under the hood:

1. Semantic Code Analysis

Serena starts language servers for your project (supporting Python, TypeScript, JavaScript, Java, C#, Go, Rust, and more). These are the same language servers your IDE uses—like Pyright for Python or TypeScript Language Server for TypeScript.

2. Symbol-Aware Tools

Instead of basic text manipulation, Serena provides tools that understand your code structure:

• find_symbol: Locate function definitions, classes, or variables across your entire project

• find_references: See where a symbol is used throughout your codebase

• goto_definition: Navigate to the exact location where something is defined

• Smart editing tools that understand code context, not just string patterns

3. Project Indexing

For large projects, Serena can index your codebase upfront, making semantic operations lightning-fast. This means Claude can efficiently explore massive codebases without getting lost.

4. Memory System

Serena includes a memory system that allows it to learn about your project over time, storing insights that can be recalled in future sessions.

Real-World Impact

Let me illustrate with a concrete example:

Without Serena:

You: "Add error handling to the user authentication function"
Claude: *Writes code but has to guess where the function is located, 
        what it's called, what imports it needs, and how it's structured*
Result: You spend time correcting the details

With Serena:

You: "Add error handling to the user authentication function"  
Claude: *Uses find_symbol to locate authenticate_user() in auth/handlers.py,
        analyzes its current implementation using goto_definition,
        finds all references to understand usage patterns,
        makes precise edits with full context awareness*
Result: The changes work immediately because Claude knew exactly 
        what was there

Getting Started with Serena + Claude

The beauty of Serena is its simplicity. If you're using Claude Code or Claude Desktop, you can integrate Serena in minutes:

Quick Installation

bash

# Using uvx (recommended)
uvx --from git+https://github.com/oraios/serena serena start-mcp-server

For Claude Code:

bash

claude mcp add serena -- uvx --from git+https://github.com/oraios/serena \
  serena start-mcp-server --context ide-assistant --project $(pwd)

For Claude Desktop:

Add this to your claude_desktop_config.json:

json

{
  "mcpServers": {
    "serena": {
      "command": "/path/to/uvx",
      "args": [
        "--from", 
        "git+https://github.com/oraios/serena", 
        "serena", 
        "start-mcp-server"
      ]
    }
  }
}

Once configured, simply activate your project in conversation:

You: "Activate /path/to/my/project as a project using Serena"

Beyond Basic Code Generation

What makes Serena truly powerful is how it enables sophisticated workflows:

Code Exploration

Ask Claude to explore your codebase: "Show me all the database models" or "Find everywhere we make HTTP requests." With Serena's LSP tools, Claude can traverse your project's symbol graph.

Refactoring

"Rename this function and update all references"—Serena ensures nothing breaks because it knows about every usage.

Debugging

Claude can trace execution paths, find function definitions, and understand call hierarchies to help diagnose issues.

Documentation

Generate documentation that's accurate because Claude can verify what symbols actually exist and how they're used.

Why This Matters for the Future of AI-Assisted Development

The difference between text-based AI coding and LSP-aware coding is like the difference between editing code in Notepad versus a modern IDE. It's a fundamental leap in capability.

Serena represents a shift in how we think about AI coding assistants:

• From guessing to knowing: No more hallucinated imports or phantom functions

• From text to semantics: Understanding code structure, not just patterns

• From surface-level to deep: Navigating complex codebases with confidence

The Open Source Advantage

Being open source and free, Serena offers several benefits:

1. No vendor lock-in: Works with Claude's free tier and can integrate with other LLMs through Agno

2. Transparency: You can see exactly what tools Claude is using and how

3. Extensibility: Add custom tools or language servers as needed

4. Community-driven: Actively developed with contributions from developers worldwide

5. Cost-effective: No subscription fees on top of your Claude usage

Technical Deep Dive: Supported Languages

Serena currently provides robust support for:

Full Support:

• Python (via Pyright/Jedi)

• TypeScript/JavaScript (via TypeScript Language Server)

• Java (via Eclipse JDT Language Server)

• C# (via OmniSharp/Roslyn)

• Go (via gopls)

• Rust (via rust-analyzer)

• C/C++ (via clangd)

• Ruby (via Solargraph)

• And more...

Each language server brings IDE-level intelligence to Claude, adapted through Serena's unified interface.

Configuration and Customization

Serena is highly configurable through YAML files:

Contexts

Different tool sets for different environments:

• ide-assistant: For integration with IDEs like VS Code or Cursor

• desktop-app: For Claude Desktop usage

• codex: For command-line coding with Codex CLI

• chatgpt: For use with ChatGPT (via MCPO)

Modes

Operational patterns:

• planning: Focus on code exploration and analysis

• editing: Emphasis on code modification tools

• interactive: Balanced tool set for conversation

• one-shot: Optimized for single-task completions

You can create custom contexts and modes by adding YAML files to ~/.serena/.

Security Considerations

For production or sensitive environments, Serena can be configured with security in mind:

yaml

# In .serena/project.yml
excluded_tools:
  - execute_shell_command  # Disable command execution
read_only: true  # Prevent file modifications

This allows you to use Serena's analysis capabilities without granting write access.

Performance Optimization

For large codebases, indexing is crucial:

bash

# Index your project before first use
uvx --from git+https://github.com/oraios/serena serena project index

This creates a symbolic index that dramatically speeds up symbol lookup and reference finding operations.

The Road Ahead

Serena is under active development, with the team working on:

• Enhanced LSP features (debugging via DAP, better diagnostics)

• Jetbrains extension for seamless IDE integration

• Additional language server support

• Performance optimizations for massive codebases

The project is sponsored by Microsoft's Visual Studio Code team and GitHub Open Source, signaling strong industry interest in this approach.

Conclusion: Closing the Perception-Action Loop

The "missing piece" that Serena provides isn't just about better code generation—it's about closing what the developers call the "cognitive perception-action loop."

When an AI assistant can perceive code the way a developer does (through semantic understanding) and act on it with precision (through LSP-aware tools), it transforms from a clever text generator into a genuine coding partner.

If you've been frustrated by AI assistants that generate plausible-but-broken code, if you've wished Claude could actually understand your project structure, or if you're tired of manually fixing imports and references—Serena might be exactly what you've been looking for.

And the best part? It's free, open source, and integrates with Claude in just a few commands.

Resources:

• Serena GitHub Repository

So there I was, staring at my shiny new Passbolt installation on Ubuntu 24.04, when that familiar dread crept in: "What happens when (not if) something goes wrong?" After one too many "I'll set up backups tomorrow" moments, I finally decided to build a proper backup system. Spoiler: it was easier than debugging a CSS flexbox issue.

The Problem

Passbolt stores critical password data across multiple locations:

• MySQL database (the crown jewels)

• Configuration files in /etc/passbolt

• GPG keys and data in /var/lib/passbolt

• User avatars and uploads

Manually backing up each component? That's a recipe for 3 AM disaster recovery panic attacks.

# The manual nightmare nobody wants
mysqldump passbolt > backup.sql
tar -czf config.tar.gz /etc/passbolt
# ...20 more commands you'll forget in a crisis

The Insight

Instead of reinventing the wheel, I created three scripts that work together like a well-oiled DevOps machine:

1. Backup Script: Handles all components with proper error handling

2. Restore Script: One-command restoration with safety checks

3. Systemd Timer: Automated backups every 6 hours

#!/bin/bash
# The magic happens here
BACKUP_DIR="/srv/backup/passbolt"
RETENTION_DAYS="${PASSBOLT_BACKUP_RETENTION_DAYS:-30}"

# Backup everything atomically
mysqldump --single-transaction --routines --triggers "$DB_NAME" > "$TEMP_DIR/database.sql"
cp -a /etc/passbolt "$TEMP_DIR/etc_passbolt"
# ... collect all the pieces

# Create timestamped archive
tar -czf "$BACKUP_DIR/${BACKUP_NAME}.tar.gz" "$BACKUP_NAME"

# Auto-cleanup old backups
find "$BACKUP_DIR" -name "passbolt_backup_*.tar.gz" -type f -mtime +$RETENTION_DAYS -delete

Why It Matters

This setup gives you:

• Automated backups running every 6 hours (configurable)

• Point-in-time recovery with timestamped archives

• Automatic cleanup keeping only the last 30 days

• One-command restore that even works during coffee-deprived emergencies

• Systemd integration with proper logging and error handling

The restore script even backs up your current data before restoring, because we've all been that person who "fixed" something into oblivion.

Pro Tips I Learned the Hard Way

1. Always test your restore process - A backup you can't restore is just wasted disk space

2. Use systemd's ProtectSystem=strict - It saved me from accidentally backing up to the wrong directory

3. Include version info in backups - Future you will thank present you when dealing with migrations

4. Set up monitoring - Add OnFailure= to your systemd service to get notified when backups fail

TL;DR

Three scripts + systemd timer = automated Passbolt backups with configurable retention. Install with one command, sleep better at night. (I know it’s in French but… TODO: Translate logging to english)

DON’T TRUST STRANGERS ON INTERNET

# The whole setup in one line
./setup-passbolt-backup.sh

Your passwords are now safer than a JavaScript developer's node_modules folder (and significantly smaller).

What's your backup horror story? Drop a comment below - misery loves company, and we all learn from each other's "learning experiences"! 🎢

The custom Reactotron transport for react-native-logs improves logging by handling various message types, adding metadata, and allowing custom prefixes, making your logs more informative and easier to manage.

The Backstory

Logging is a crucial part of development, especially when debugging or monitoring application behavior. Reactotron is a popular tool for inspecting React and React Native apps, and integrating it with react-native-logs can provide a more seamless logging experience. This custom transport enhances the default logging functionality by adding features like timestamps and custom prefixes.

The Problem

While react-native-logs is powerful, it might not cover all use cases out of the box. For instance, you might want to:

• Add timestamps to your logs for better traceability.

• Prefix logs with custom identifiers to differentiate between different sources or modules.

• Handle various types of log messages (strings, objects, arrays) gracefully.

The Insight

The custom transport addresses these needs by:

1. Handling Different Message Types: It can process simple text messages, arrays, and objects, ensuring that each type is displayed appropriately in Reactotron.

2. Adding Metadata: It includes the log level and an optional timestamp in the metadata.

3. Custom Prefixes: It allows you to add a custom prefix to each log message, making it easier to identify the source of the log.

4. Importance Flag: It marks important logs (based on severity) to make them stand out in Reactotron.

Here's a breakdown of the code:

/**
 * Custom transport for sending logs to Reactotron with enhanced features
 */
export const reactotronTransport: transportFunctionType<{
  showTimestamp?: boolean;
  customPrefix?: string;
}> = (props) => {
  const { level, msg, rawMsg, options = {} } = props;
  const isImportant = level.severity >= 3;
  const prefix = options.customPrefix ? `${options.customPrefix}: ` : '';

  // Enhanced message handling
  let displayMessage: any;
  let previewText = '';

  // Case 1: Array of arguments (like console.log('text', object))
  if (Array.isArray(rawMsg)) {
    const firstItem = rawMsg[0];
    const restItems = rawMsg.slice(1);

    if (typeof firstItem === 'string' && restItems.length > 0) {
      previewText = firstItem;
      displayMessage = {
        message: firstItem,
        data: restItems.length === 1 ? restItems[0] : restItems,
      };
    } else {
      previewText = `Array[${rawMsg.length}]`;
      displayMessage = rawMsg;
    }
  }
  // Case 2: Single object (including array)
  else if (typeof rawMsg === 'object' && rawMsg !== null) {
    if (Array.isArray(rawMsg)) {
      previewText = `Array[${rawMsg.length}]`;
    } else {
      previewText = Object.prototype.toString.call(rawMsg).slice(8, -1);
    }
    displayMessage = rawMsg;
  }
  // Case 3: Simple text message
  else {
    previewText = msg;
    displayMessage = rawMsg !== undefined ? rawMsg : msg;
  }

  // Metadata
  const metadata = {
    level: level.text,
    timestamp: options.showTimestamp ? new Date().toISOString() : undefined,
  };

  // Preview with prefix
  const preview = `${prefix}${previewText}`;

  // Send to Reactotron
  Reactotron.display({
    name: level.text.toUpperCase(),
    value: {
      ...(typeof displayMessage === 'object'
        ? displayMessage
        : { message: displayMessage }),
      ...metadata,
    },
    preview,
    important: isImportant,
  });
};

Why It Matters

This custom transport makes your logging more flexible and informative. By adding timestamps and custom prefixes, you can better track and differentiate logs. The enhanced message handling ensures that all types of log data are displayed correctly in Reactotron, making debugging and monitoring more efficient.

Add parallel: N to your GitLab CI job and pass --shard=${CI_NODE_INDEX}/${CI_NODE_TOTAL} to Playwright to slash your test execution time and keep your team shipping fast.

The Backstory

Last week, our test suite execution time crossed the dreaded 30-minute mark. Team members were context-switching during test runs, and our deploy frequency started to suffer. That's when I discovered we weren't using GitLab CI's parallelization capabilities with our Playwright tests.

The Problem

Running Playwright tests sequentially in GitLab CI can take forever, especially as your test suite grows. Without parallelization, even simple PR validations become coffee-break-length waits:

# The slow, sequential way 😴
test:
  stage: test
  image: mcr.microsoft.com/playwright:v1.51.1-noble
  script:
    - npm install
    - npx playwright test
  artifacts:
    when: always
    paths:
      - playwright-report/
      - junit.xml
    reports:
      junit: junit.xml

The Insight

GitLab CI supports running jobs in parallel using the parallel keyword, and Playwright can shard tests with the --shard flag. Combining these powers is like discovering you can breathe underwater:

# The speed-demon parallel way 🚀
test:
  stage: test
  image: mcr.microsoft.com/playwright:v1.51.1-noble
  parallel: 5  # Run 5 parallel jobs
  script:
    - npm ci
    - npx playwright test --shard=${CI_NODE_INDEX}/${CI_NODE_TOTAL}
  artifacts:
    when: always
    paths:
      - playwright-report/
      - junit.xml
    reports:
      junit: junit.xml

Playwright's --shard flag takes two parameters: current shard index and total shards. The magic here is that GitLab CI automatically provides environment variables CI_NODE_INDEX and CI_NODE_TOTAL that perfectly match what Playwright expects!

Why It Matters

After implementing this change:

• Our test suite execution time dropped from 30+ minutes to under 10 minutes

• Developers stopped context-switching during test runs

• We caught integration issues faster and deployed more frequently

For larger projects, you can refine this further by using GitLab's matrix syntax to run different browser tests in parallel:

test:
  stage: test
  image: mcr.microsoft.com/playwright:v1.51.1-noble
  parallel:
      matrix:
        - BROWSER: [chromium, firefox, webkit]
  script:
    - npm install
    - npx playwright test --project=$BROWSER --shard=${CI_NODE_INDEX}/${CI_NODE_TOTAL}
  artifacts:
    when: always
    paths:
      - playwright-report/
      - junit.xml
    reports:
      junit: junit.xml

The Problem with Raw Error Messages

If you've worked with Appwrite (or any backend service), you're familiar with errors like:

{
    "message": "Invalid id: Parameter must be a valid number",
    "type": "general_argument_invalid",
    "code": 400
}

These messages make perfect sense to developers but can be bewildering to end users. They lack context, often contain technical jargon, and rarely offer guidance on how to resolve the issue.

A Better Way to Handle Errors

The Appwrite Exceptions Translator addresses these issues by:

1. Translating error codes and types into human-readable explanations

2. Supporting multiple languages (currently English, French, Spanish, and Arabic)

3. Providing a consistent error handling pattern across your application

4. Falling back gracefully when no translation is available

How It Works

Using the translator is straightforward:

import { AppwriteExceptionTranslator } from "@itishermann/appwrite-exceptions-translator";
import { LocalTranslationProvider } from "@itishermann/appwrite-exceptions-translator/providers";

// Initialize the translator
const translator = new AppwriteExceptionTranslator(
  new LocalTranslationProvider()
);

// Somewhere in your error handling...
try {
  // Appwrite operations
} catch (error) {
  // Transform the error into a user-friendly message
  const userMessage = translator.translate(error);

  // Display to user (instead of the raw error)
  showNotification(userMessage);
}

Instead of your users seeing "general_argument_invalid", they'll see something like "The request contains one or more invalid arguments" - or its equivalent in their preferred language.

Flexible and Extensible

The library is designed with flexibility in mind:

• Language switching on-the-fly - Change languages without restarting your app

• Prioritized translation strategy - Tries error type first, falls back to error code

• Custom translation providers - Implement your own provider for different translation sources

• Lightweight footprint - No heavy dependencies, just the translations you need

Built for Modern JavaScript Environments

The package is built with TypeScript, includes full type definitions, and supports both ESM and CommonJS. It works seamlessly with:

• Node.js applications

• React, Vue, Angular, and other frontend frameworks

• React Native and other mobile JavaScript frameworks

• Bun projects (it's actually built with Bun!)

Getting Started

Installation is simple:

# Using npm
npm install @itishermann/appwrite-exceptions-translator

# Using yarn
yarn add @itishermann/appwrite-exceptions-translator

# Using bun
bun add @itishermann/appwrite-exceptions-translator

Why I Built This

As a developer working with Appwrite, I found myself repeatedly writing code to transform error messages into something more user-friendly. After copy-pasting the same logic across multiple projects, I decided to extract it into a reusable package.

This translator is part of a larger effort to improve the developer and end-user experience when working with Appwrite - an excellent open-source backend that deserves equally excellent tooling.

Contributing

This is an open-source project licensed under AGPL-3.0, and contributions are welcome! Whether you want to:

• Add translations for additional languages

• Improve existing translations

• Extend the functionality

• Fix bugs

Check out the contribution guidelines to get started.

Conclusion

Error handling doesn't have to be an afterthought. With Appwrite Exceptions Translator, you can provide clear, helpful error messages to your users in their preferred language, improving the overall user experience of your application.

Give it a try in your next Appwrite project, and turn frustrating errors into helpful guidance.

Check out the repository on GitLab or install it directly from npm.

The Challenge: Finding a Motivating Walking Routine

Like many, I was advised to aim for at least 10,000 steps daily. The biggest hurdle wasn’t the walking itself, but the lack of a clear, engaging routine. I wanted a way to combine my daily steps with exploring the city, but none of the existing apps seemed to offer what I needed: a path that starts and ends at the same point, creating a looped walking route that would naturally help me hit my goal.

The Solution: 10K Step Path Generator

Frustrated by the lack of options, I decided to create my own. The result is the 10K Step Path Generator, an open-source app designed to help you achieve your daily step goals by generating personalized looped walking routes.

How It Works:

The app is designed to make reaching your 10,000 step goal simple and fun:

1. Personalized Step Length: You start by entering your height and gender. The app uses this information to calculate your step length, which ensures that the generated routes are tailored to you.

2. Looped Path Generation: Using the OpenRouteService API, the app calculates a looped path that starts and ends at your current location. The path length is automatically adjusted based on your desired step count and step length, guaranteeing that you walk the distance you need to reach your goal.

3. Interactive Map Preview: The route is displayed on an interactive Leaflet map, allowing you to preview the path and terrain. (screenshot)

4. GPX Download: For offline navigation, you can download the route as a GPX file, perfect for using with fitness trackers and apps.

5. Persistent Storage: Your saved routes are stored locally using IndexedDB, so you can easily revisit your favorite paths.

Key Features:

• Personalized Routes: Tailored to your step length, for accurate step goal achievement.

• Interactive Map: Preview routes visually before you go.

• GPX Export: Download routes for offline use.

• Offline Storage: Save your favorite routes directly in your browser.

• Open Source: Available on GitHub, feel free to contribute!

• Free to use: The app is available at 10k-steps.itishermann.me

Getting Started:

1. Visit the website: Go to 10k-steps.itishermann.me in your browser.

2. Enter your height and gender: The app will calculate your step length.

3. Set your step goal: The default is 10,000 steps but you can adjust it as you see fit.

4. Generate your route: The app creates a looped walking path tailored to your step goal, starting and ending at your current location.

5. Preview the route: Check the map to see where your walk will take you.

6. Download: Download the GPX file.

7. Start walking! Open the GPX track in your preferred app (I'd personally recommend Komoot, they even have a tutorial on importing a GPX file) and hit the path and start working toward your daily step target.

Tech Stack
The app is built using:

• Bun: a fast JavaScript runtime

• Next.js: for the React framework

• Tailwind CSS: for styling

• OpenRouteService API: for pathfinding

• Leaflet.js: for map visualization

• Dexie.js: for local storage

Why I Built It

I built this app because I believe that fitness should be integrated into daily life, not something you need to force yourself into. By creating a tool that generates enjoyable, looped walking routes, I hope to encourage others to make walking a regular part of their routine.

Open Source and Contributions

The 10K Step Path Generator is open-source, meaning the code is available for anyone to view, use, and contribute to. If you’re interested in seeing how it works under the hood or want to suggest improvements, you can find the project on GitLab.

Join the Movement

Ready to make your 10,000 steps more enjoyable and engaging? Give the 10K Step Path Generator a try and start exploring your city, one loop at a time!

The Problem

As any developer will tell you, commit messages are crucial for maintaining a clean and understandable project history. But they can also be a major time sink, especially when you're in "THE zone", and writing that perfect message just feels like an unnecessary interruption. My commit logs were beginning to look like a series of random thoughts hastily jotted down, and it was starting to impact my workflow.

The Idea

The idea hit me during one of those late-night coding sessions when you're just desperate for a breakthrough. I had been experimenting with language models (LLMs) and their capabilities, and it suddenly struck me—why not use one to generate my commit messages? If an LLM could write essays, articles, and even poetry, surely it could handle something as straightforward as a commit message?

The Creation of Ollama Commit Summarizer

With a new sense of purpose, I set out to build the Ollama Commit Summarizer. The extension would analyze the changes made in the code and then generate a concise, relevant commit message. It had to be simple to use, efficient, and most importantly, it had to produce commit messages that made sense.

Built with Kotlin for IntelliJ-based IDEs, this plugin seamlessly integrates into your workflow, providing an automated solution for generating commit messages. You can find the extension on the JetBrains Plugin Marketplace and the source code on GitHub. The core functionality is built around the language models available through the Ollama API. The process is straightforward: once you’ve made your changes, you run the summarizer, and it spits out a commit message based on the modifications in your code.

How It Works

Here's a quick rundown of how Ollama Commit Summarizer works:

1. Analyze the Code Changes: The extension get the diffs in your project to understand what changes were made and format it.

2. Generate the Commit Message: It sends this information to the language model, which then crafts a commit message that succinctly describes the changes.

3. Review and Commit: You get a suggested commit message, which you can review, tweak if necessary, and then commit.

Benefits

Since I started using the Ollama Commit Summarizer, my workflow has improved dramatically. Here are some of the benefits I've noticed:

• Consistency: The commit messages are consistently clear and informative.

• Efficiency: It saves me time, allowing me to focus more on coding and less on writing.

• Ease of Use: It's incredibly easy to integrate and use within my existing workflow.

Conclusion

Creating the Ollama Commit Summarizer has been a game-changer. It not only solved a persistent annoyance but also leveraged the power of language models in a practical, everyday task. If you're a developer who dreads writing commit messages as much as I did, I highly recommend giving it a try. You might just find that your commit logs become the most well-written part of your codebase!

You can check out and contribute to the project on GitHub and get the extension down bellow. Let's make tedious commit messages a thing of the past!

What is a BIMI DNS Record?

BIMI (Brand Indicators for Message Identification) is like giving your email a stylish business card. It allows your brand's logo to appear alongside your emails in recipients' inboxes, adding a layer of authenticity and recognition. Think of it as a digital signature with a personal touch, telling your recipients, "Hey, this email is legit!"

Why are BIMI DNS Records Useful?

1. Enhanced Brand Recognition: Your logo in the inbox? Yes, please! BIMI helps your emails stand out and reinforces your brand identity every time someone opens their email.

2. Increased Trust: With phishing and spam on the rise, a recognizable logo assures recipients that the email is genuinely from you. It's like having a friendly face greeting them.

3. Improved Email Deliverability: Emails with BIMI are less likely to end up in the spam folder. This means more of your emails reach the intended audience, boosting engagement and conversions.

4. Competitive Edge: Not everyone is using BIMI yet. By adopting it early, you position your brand as a trustworthy and forward-thinking entity.

How to Deploy BIMI DNS Records

Deploying BIMI might sound technical, but it's simpler than you think. Follow these steps:

1. Create a Verified Mark Certificate (VMC): A VMC verifies your logo and is a crucial part of the BIMI setup. You can obtain it from authorized providers like DigiCert or Entrust.

2. Design Your SVG Logo: Ensure your logo is in SVG format. It needs to be square, less than 32KB in size, and meet BIMI specifications. Check this page for some software that can help you.

3. Authenticate Your Emails: Ensure your emails are authenticated using SPF, DKIM, and DMARC. BIMI requires these protocols to be in place.

Update Your DNS Record: Add a new TXT DNS record for BIMI. The format typically looks like this:

default._bimi.yourdomain.com. IN TXT "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem"

How to Verify BIMI DNS Records

After setting up your BIMI DNS records, it's time to verify them:

1. Use BIMI Inspector Tools: Several online tools, like BIMI Inspector, can check if your BIMI records are correctly configured. This one for example.

2. Monitor Email Deliverability: Keep an eye on your email deliverability rates. If you've set up BIMI correctly, you should see an improvement.

3. Check for Your Logo: Send test emails to major email providers like Gmail and Yahoo. Your logo should start appearing in the inbox once everything is verified.

Final Thoughts

BIMI DNS records are a game-changer for email marketing and communication. By enhancing brand recognition, increasing trust, and improving email deliverability, they ensure your emails get the attention they deserve. Plus, setting them up isn't as daunting as it seems. So, give your emails the VIP treatment and watch your inbox presence shine!

Remember, in the world of email, a little effort goes a long way. So, why not give BIMI a try? Your brand will thank you for it!

In the bustling world of software development, efficiency isn't just a luxury—it's as essential as a morning croissant in Paris. Enter Turbo Repo, a nimble build system tailored for JavaScript and TypeScript monorepos that's as swift as a scooter weaving through the Marais district. While Turbo Repo natively supports various remote caching solutions, opting for a self-hosted remote cache is like having your own private café—complete control, no queue, and the coffee is always brewed to your liking. Let's embark on a journey to deploy your very own self-hosted Turbo Repo remote cache, using the resourceful open-source solution from ThibautMarechal's GitHub repository. So, tighten your beret and let's dive in, because just like the Paris Metro at rush hour, development waits for no one! (nah i'm kidding the beret is overhyped, who wears a beret in paris ? Only tourists...please don't do that 💀)

Why Self-Host a Turbo Repo Remote Cache?

A remote cache serves as a central hub where build artifacts are stored. This means subsequent builds can fetch these artifacts instead of rebuilding them, significantly cutting down build times and improving developer productivity. By hosting your own remote cache, you gain:

• Full control over your data: Keep your sensitive information within your infrastructure.

• Customized scaling options: Scale your caching needs according to your project size and team requirements.

• Reduced external dependencies: Minimize downtime and latency issues associated with third-party services.

Last but not least, you get the Full Turbo. Isn't this beautiful ? 😎🤌🏾

Step 1: Preparing Your Environment

Before you get started with your self-hosted Turbo Repo remote cache, ensure Docker is installed on your server. Docker provides a consistent environment for your cache, making it a bit more reliable. If Docker is not yet installed, you can find installation instructions for various platforms on the official Docker website.

Step 2: Deploying the compose file

Create a Project Directory: Start by creating a dedicated directory on your server for your project. This directory will house all necessary files, including your Docker Compose configuration. You can create it with a command like:

mkdir turborepo-cache
cd turborepo-cache

Prepare the Docker Compose File: Inside your new project directory, create a Docker Compose YAML file named docker-compose.yml. Paste the Docker Compose content provided earlier into this file. This content defines your PostgreSQL database and Turbo Repo remote cache service. Here's a simplified reminder of what to include:

version: '3'
volumes:
  trrc-cache:
services:
  db:
    image: postgres:15.5
    restart: always
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: turborepo
      PGDATA: /var/lib/postgresql/data/pgdata
    volumes:
      - ./data/postgres/:/var/lib/postgresql/data
  turborepo-remote-cache:
    image: thibmarechal/turborepo-remote-cache:1.13.0
    depends_on:
      - db
    ports:
      - "8080:8080"
    environment:
      PORT: 8080
      STORAGE_TYPE: fs
      STORAGE_FS_PATH: /data
      COOKIE_NOT_SECURE: 'true'
      DATABASE_URL: postgres://postgres:postgres@db:5432/turborepo
      ADMIN_USERNAME: admin
      ADMIN_NAME: admin
      ADMIN_PASSWORD: change-me-with-a-long-ahh-password
      ADMIN_EMAIL: you@you-mail-provider.com
    volumes:
      - ./data/fs:/data

Configuration: All the configurations can be applied through the environment of the turborepo-remote-cache service.

• PORT: The port on which the application will run.

• STORAGE_TYPE: The type of storage to use (fs, s3, azure).

• STORAGE_FS_PATH: The path where to store the cache when using file storage.

• STORAGE_S3_ACCESS_KEY_ID: Access key ID for Amazon S3 storage.

• STORAGE_S3_SECRET_ACCESS_KEY: Secret access key for Amazon S3 storage.

• STORAGE_S3_FORCE_PATH_STYLE: Boolean to force path style for S3 requests.

• STORAGE_S3_ENDPOINT: Endpoint URL for S3 storage.

• STORAGE_S3_REGION: Region for S3 storage.

• STORAGE_S3_SSL_ENABLED: Boolean to enable SSL for S3 storage.

• STORAGE_S3_BUCKET: Bucket name for S3 storage.

• STORAGE_AZURE_STORAGE_ACCOUNT: Account name for Azure Blob storage.

• STORAGE_AZURE_STORAGE_ACCESS_KEY: Access key for Azure Blob storage.

• STORAGE_AZURE_STORAGE_CONTAINER: Container name for Azure Blob storage.

• DATABASE_URL: Connection URL for the Postgres database.

• ADMIN_USERNAME: Username for the admin account.

• ADMIN_NAME: Name for the admin account.

• ADMIN_PASSWORD: Password for the admin account.

• ADMIN_EMAIL: Email for the admin account.

• OIDC: Boolean to enable OpenID Connect (OIDC) authentication.

• OIDC_NAME: Name for the OIDC provider.

• OIDC_AUTHORIZATION_URL: Authorization URL for the OIDC provider.

• OIDC_TOKEN_URL: Token URL for the OIDC provider.

• OIDC_CLIENT_ID: Client ID for the OIDC provider.

• OIDC_CLIENT_SECRET: Client secret for the OIDC provider.

• OIDC_PROFILE_URL: Profile URL for the OIDC provider.

• AZURE_AD: Boolean to enable Azure Active Directory authentication.

• AZURE_AD_CLIENT_ID: Client ID for Azure AD authentication.

• AZURE_AD_CLIENT_SECRET: Client secret for Azure AD authentication.

• AZURE_AD_TENANT_ID: Tenant ID for Azure AD authentication.

• COOKIE_NOT_SECURE: false if serving over https otherwise true.

Launch the Services: With your docker-compose.yml ready, use Docker Compose to build and start your services. Execute the following command from within your project directory:

docker compose up -d

This command runs your containers in detached mode, meaning they'll continue running in the background.

Step 3: Integrating with Your Turbo Repo

Let's make your Turbo Repo projects use your new self-hosted cache. It's easy, just run this command at the root of your Turbo Repo

turbo login --login "https://[your-turbo-repo-link]/turbo/login" --api "https://[your-turbo-repo-link]/turbo/api"

This command log you in but the repo is not linked yet, to do so you have to run this command. You will be prompted to choose a team for the project.

turbo link

These commands also create a config file at .turbo/config.json. It is not advised to commit this file.

By doing so, your builds will know exactly where to drop off and pick up their cached artifacts, similar to how Parisians know their way around the métro - but way quicker AND never late compared to the métro.

Parisian metro and Turbo repo are the same but different

Your Build Process, Streamlined

Congratulations! Your Dockerized self-hosted Turbo Repo remote cache is now set up and running, akin to a well-oiled TGV on its way to the Marseille (but still faster). This setup not only optimizes your build times but does so with the elegance and efficiency that would make any developer puff out their chest like a proud Parisian pigeon. Enjoy the accelerated development cycle, enhanced control, and the delightful fact that your builds are now more reliable. Bonne continuation, and may your code compile smoothly.

Project Initialization with TypeScript Template and PNPM

First things first, let's set up our project. We'll use PNPM for its efficiency in handling node modules like a Parisian handling a croissant—carefully and effectively.

Create a new Expo project with the TypeScript template:

pnpx create-expo-app -t expo-template-blank-typescript

Install PNPM if you haven't:

npm install -g pnpm

Voilà! You have laid the foundation of your project.

Installing Dependencies

To handle authentication, we'll need a few packages. Let’s install them like we’re stocking up before a French strike—better safe than sorry!

pnpm expo install expo-auth-session expo-secure-store

These will help us manage authentication sessions and securely store our tokens.

AutoDiscovery with Authentik

Authentik supports OpenID Connect (OIDC) auto-discovery, making it easier than a Monday morning in Parisian metro to configure. Here’s how to set it up:

1. Create an app on your Authentik server

2. Ensure that your Authentik server URL is correct and the app slug is correct.

In your project, create a configuration for Authentik:

// useAuth.ts
import { useAutoDiscovery } from 'expo-auth-session';

const AuthentikClientId = 'your-client-id-here';
const AuthentikAppUrl = 'https:/[Your authentik domain]/application/o/[Your authentik app slug]';

export default function useAuth() {
  const discovery = useAutoDiscovery(AuthentikAppUrl);

  /* ... */
}

💡

Do not include the whole well-known part in the url, the library appends it

Making the Request

When everything is set up, making the request is as simple as ordering a café au lait:

// App.tsx
import { makeRedirectUri, useAutoDiscovery, useAuthRequest } from 'expo-auth-session';

const redirectUri = makeRedirectUri();
const AuthentikClientId = 'your-client-id-here';
const AuthentikAppUrl = 'https:/[Your authentik domain]/application/o/[Your authentik app slug]';

export default function App() {
  const discovery = useAutoDiscovery(AuthentikAppUrl);

    // To retrieve the redirect URL, add this to the callback URL list
  // of your Authentik application.
  // console.log(`Redirect URL: ${redirectUri}`);

    const [request, result, promptAsync] = useAuthRequest(
    {
      redirectUri,
      clientId: AuthentikClientId,
      // id_token will return a JWT token
      responseType: "id_token",
      // retrieve the user's profile
      scopes: ["openid", "profile"],
      usePKCE: true,
      extraParams: {
        // ideally, this will be a random value
        nonce: "nonce",
      },
    },
    discovery
  );

  /* ... */
}

Saving the Token

Once you receive the token, store it securely like a secret recipe for the perfect baguette:

// token.ts
import * as SecureStore from 'expo-secure-store';
import { TokenResponse } from "expo-auth-session";

const AUTH_TOKEN_KEY = 'AUTH_TOKEN_KEY';

export async function saveToken(token: TokenResponse) {
  await SecureStore.setItemAsync(AUTH_TOKEN_KEY,JSON.stringify(token));
}

// useAuth.ts
import { useAutoDiscovery, makeRedirectUri, useAuthRequest } from "expo-auth-session";
import { Alert } from "react-native";
import { useCallback, useEffect } from "react";
import { saveToken } from "./token";

const redirectUri = makeRedirectUri();
const AuthentikClientId = 'your-client-id-here';
const AuthentikAppUrl = 'https:/[Your authentik domain]/application/o/[Your authentik app slug]';

export default function useAuth() {
    const discovery = useAutoDiscovery(AuthentikAppUrl);

    // To retrieve the redirect URL, add this to the callback URL list
  // of your Authentik application.
  // console.log(`Redirect URL: ${redirectUri}`);

    const [request, result, promptAsync] = useAuthRequest(
    {
      redirectUri,
      clientId: AuthentikClientId,
      // id_token will return a JWT token
      responseType: "id_token",
      // retrieve the user's profile
      scopes: ["openid", "profile"],
      usePKCE: true,
      extraParams: {
        // ideally, this will be a random value
        nonce: "nonce",
      },
    },
    discovery
  );

    const handleResult = useCallback(() => {
    if(!result) return;
    if (result.type === 'error') {
      Alert.alert(
        "Authentication error",
        result.params.error_description || "something went wrong"
      );
      return;
    }
    if (result.type === "success") {
      if(!result.authentication || !result.authentication) return;
      saveToken(result.authentication);
    }
  }, [result]);

  useEffect(()=> {
        handleResult();
  }, [handleResult]);
  /* ... */
}

Decoding the Token to Get Claims

Decoding the token to retrieve claims is like decoding the French menu in a fancy restaurant—necessary to understand what you’re getting:

// token.ts
import * as SecureStore from 'expo-secure-store';
import { jwtDecode, type JwtPayload } from 'jwt-decode';

const AUTH_TOKEN_KEY = 'AUTH_TOKEN_KEY';

export async function saveToken(token: string) {
  await SecureStore.setItemAsync(AUTH_TOKEN_KEY, token);
}

export interface Claims extends JwtPayload {
  name: string;
  preferred_username: string;
  email: string;
  nickname: string;
  groups: string[];
  given_name: string;
}


export const decodeToken = (token: string) => {
  const decoded = jwtDecode<Claims>(token);
  return decoded;
};

But wait jwt-decode relies on atob but react-native doesn't have it so lets fix this. Let's install base-64 and polyfill ourselves.

pnpm add base-64 && pnpm add --save-dev @types/base-64

Let's update our files

// token.ts
import { decode } from "base-64";
import * as SecureStore from 'expo-secure-store';
import { jwtDecode, type JwtPayload } from 'jwt-decode';

const AUTH_TOKEN_KEY = 'AUTH_TOKEN_KEY';

export async function saveToken(token: string) {
  await SecureStore.setItemAsync(AUTH_TOKEN_KEY, token);
}

export interface Claims extends JwtPayload {
  name: string;
  preferred_username: string;
  email: string;
  nickname: string;
  groups: string[];
  given_name: string;
}

export function decodeToken(token: string) {
    const originalAtoB = global.atob;
    global.atob = decode; // Dangerous overload
    const decoded = jwtDecode<Claims>(token);
    global.atob = originalAtoB;
    return decoded;
}

☠️

Always remember that overloading globals yourself is never a good idea. If some other libs rely on the said global, you're cooked. We do this only for science and you should never do this on production. Never ever....
You should maybe call your api and handle the token decode server side

// useAuth.ts
import { useAutoDiscovery, makeRedirectUri, useAuthRequest } from "expo-auth-session";
import { Alert } from "react-native";
import { useCallback, useEffect, useState } from "react";
import { decodeToken, getToken, type Claims, saveToken } from "./token";

const redirectUri = makeRedirectUri();
const AuthentikClientId = 'your-client-id-here';
const AuthentikAppUrl = 'https:/[Your authentik domain]/application/o/[Your authentik app slug]';

export default function useAuth() {
    /* ... */
    const handleResult = useCallback(() => {
    if(!result) return;
    if (result.type === 'error') {
      Alert.alert(
        "Authentication error",
        result.params.error_description || "something went wrong"
      );
      return;
    }
    if (result.type === "success") {
            if(!result.authentication || !result.authentication.idToken) return;
      // Retrieve the JWT token and decode it
      const jwtToken = result.authentication.idToken;
      const decoded = decodeToken(jwtToken);
      setClaims(decoded);
            saveToken(result.authentication);
    }
  }, [result]);

  useEffect(()=> {
        handleResult();
  }, [handleResult]);

  /* ... */

}

Retrieving and Checking the Token

Fetching the token and checking its validity is like checking if the cheese has matured to perfection:

// token.ts
/* ... */
export async function getToken(): Promise<TokenResponse | null> {
    const result = await SecureStore.getItemAsync(AUTH_TOKEN_KEY);
    if (!result) return null;
    return new TokenResponse(JSON.parse(result));
}

export interface Claims extends JwtPayload {
  name: string;
  preferred_username: string;
  email: string;
  nickname: string;
  groups: string[];
  given_name: string;
}

export function decodeToken(token: string) {
    const originalAtoB = global.atob;
    global.atob = decode; // Dangerous overload
    const decoded = jwtDecode<Claims>(token);
  global.atob = originalAtoB;
  return decoded;
}

// useAuth.ts
import { useAutoDiscovery, makeRedirectUri, useAuthRequest } from "expo-auth-session";
import { Alert } from "react-native";
import { useCallback, useEffect, useState } from "react";
import { decodeToken, getToken, type Claims, saveToken } from "./token";

const redirectUri = makeRedirectUri();
const AuthentikClientId = 'your-client-id-here';
const AuthentikAppUrl = 'https:/[Your authentik domain]/application/o/[Your authentik app slug]';

export default function useAuth() {
    /* .... */
    const retrieveTokenOnMount = useCallback(async () => {
        const token = await getToken();
        if (!token || !token.idToken) return;
        if(token.shouldRefresh()){
          // refresh if required
            await token.refreshAsync({
                ...token.getRequestConfig(),
                clientId: AuthentikClientId,
            },
                {
                    tokenEndpoint: discovery?.tokenEndpoint
                }
            );
        }
        const decoded = decodeToken(token.idToken);
        setClaims(decoded);
    }, [discovery]);

    useEffect(() => {
        retrieveTokenOnMount();
    }, [retrieveTokenOnMount]);

    /* .... */
}

Logging Out and Revoking the Token

Finally, logging out and revoking the token should be as dramatic as a French exit—silent but effective:

// useAuth.ts
import { useAutoDiscovery, makeRedirectUri, useAuthRequest, revokeAsync } from "expo-auth-session";
import { Alert } from "react-native";
import { useCallback, useEffect, useState } from "react";
import { decodeToken, getToken, type Claims, saveToken, removeToken } from "./token";
import { openBrowserAsync } from "expo-web-browser";

const redirectUri = makeRedirectUri();
const AuthentikClientId = 'your-client-id-here';
const AuthentikAppUrl = 'https:/[Your authentik domain]/application/o/[Your authentik app slug]';

export default function useAuth() {
    /* ... */
    const revoke = async () => {
        const token = await getToken();
        if(!token) return;
        await revokeAsync(
            {
                ...token.getRequestConfig(),
                token: token.accessToken,
                clientId: AuthentikClientId,
            },
            {
                revocationEndpoint: discovery?.revocationEndpoint,
            }
        );
        setClaims(null);
        await removeToken();
        if(discovery?.endSessionEndpoint) {
            await openBrowserAsync(
                discovery?.endSessionEndpoint
            );
        }
    };

}

Wrap it up

Now write a little app file with ui

// App.tsx
import { Button, StyleSheet, Text, View } from "react-native";
import useAuth from "./useAuth";
import { Claims } from "./token";

export default function App() {
  const { claims,request, promptAsync,revoke } = useAuth();
  return (
    <View style={styles.container}>
      {claims ? (
        <>
          <Text style={styles.title}>You are logged in!</Text>
          <Text style={styles.title}>JWT claims:</Text>
          {Object.keys(claims).map((key) => (
            <Text key={key}>
              {key}: {claims[key as keyof Claims]}
            </Text>
          ))}
          <Button title="Log out" onPress={revoke} />
        </>
      ) : (
        <Button
          disabled={!request}
          title="Log in"
          onPress={() => promptAsync()}
        />
      )}
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: "#fff",
    alignItems: "center",
    justifyContent: "center",
  },
  title: {
    fontSize: 20,
    textAlign: "center",
    marginTop: 40,
  },
});

Conclusion

And there you have it! You've just secured your app with OAuth using Expo, Authentik, and TypeScript, all while maintaining that effortless French chic. Now your app's security is as robust as the French spirit—unyielding and sophisticated. Enjoy coding, and remember, as they say in France, "Plus ça change, plus c'est la même chose" — the more things change, the more they stay the same, especially in coding standards!
The whole source code is available on Gitlab

Initial Setup

Let's set up our environment with TypeScript and the necessary domain-driven design elements. First, we'll define the models and interfaces that represent the domain model, and import the necessary packages like neverthrow and luxon for date handling.

Importing Required Libraries

import { Product } from '@domain/product/Product';
import { InventoryRepositoryInterface } from '@domain/inventory/InventoryRepositoryInterface';
import { Order, OrderDetails } from '@domain/order/Order';
import { OrderRepositoryInterface } from '@domain/order/OrderRepositoryInterface';
import { DateTime } from 'luxon';
import { err, ok, Result } from 'neverthrow';
import { makeTaggedUnion, none, MemberType } from 'safety-match';

Defining Input and Error Types

Next, we define the input for our service and the types of errors that could occur:

export interface PlaceOrderInput {
  productId: string;
  quantity: number;
  orderDate: DateTime;
}

export const PlaceOrderError = makeTaggedUnion({
  ProductNotFound: none,
  InsufficientStock: none,
  OrderSaveFailed: none,
});

export type PlaceOrderError = MemberType<typeof PlaceOrderError>;

In this setup, PlaceOrderInput specifies the information required to place an order, and PlaceOrderError defines possible error scenarios.

Implementing the Service

Now, let's implement the service. We'll use the neverthrow library to manage different outcomes of operations explicitly, ensuring that every function call that might fail is clear in its intent and handling.

export class OrderService {
  constructor(
    private readonly inventoryRepository: InventoryRepositoryInterface,
    private readonly orderRepository: OrderRepositoryInterface
  ) {}

  async placeOrder(input: PlaceOrderInput): Promise<Result<Order, PlaceOrderError>> {
    // Check product availability
    const stockLevel = await this.inventoryRepository.getStockLevel(input.productId);
    if (stockLevel === null) return err(PlaceOrderError.ProductNotFound);
    if (stockLevel < input.quantity) return err(PlaceOrderError.InsufficientStock);

    // Create and save the order
    const orderDetails: OrderDetails = {
      productId: input.productId,
      quantity: input.quantity,
      orderDate: input.orderDate
    };
    const order = new Order(orderDetails);
    const saveResult = await this.orderRepository.saveOrder(order);

    if (!saveResult) return err(PlaceOrderError.OrderSaveFailed);
    return ok(order);
  }
}

Explanation of Service Logic:

1. Check Product Availability: The service first checks if the product is available and in sufficient quantity. It returns early with an appropriate error if not.

2. Place the Order: If the product is available, the service creates an order. It attempts to save this order using the order repository.

3. Error Handling: If saving the order fails, an error is returned. Otherwise, the successfully placed order is returned.

Benefits of This Approach

Using neverthrow provides several advantages:

• Explicit Error Handling: Each function's outcome, whether success or failure, is clearly defined through its return type.

• Type Safety: Errors are part of the type system, forcing developers to handle them explicitly, reducing the chance of unhandled exceptions.

• Improved Maintainability: Having a clear and predictable error handling strategy makes the code easier to maintain and debug.

This method aligns with modern best practices in TypeScript application development, where enhancing clarity, type safety, and robustness are key priorities. By structuring your error handling in this detailed manner, your codebase becomes more predictable and less prone to runtime errors.
To conclude, while this tutorial showcases an approach to structured and type-safe error handling in TypeScript using the neverthrow library, I must credit the initial inspiration to my colleague, Killian. His insights and innovative ideas significantly influenced the development of these error handling techniques, demonstrating the power of collaboration in software development.

Features

When we launched the module, we received a clear and concise specification. From it, we were able to extract the basic functionalities which are the following:

• Display the weather of a city with the weather according to the time, the 5 days forecast, the wind speed and direction, the temperature in celsius and Fahrenheit, the minimum and maximum temperatures as well as the pressure and humidity

• Search for a city

• Save and delete a city

• List cities Beyond these features, we have chosen to implement geolocation and autocompletion when searching for a city.

Why SwiftUI?

Storyboard is very attractive when you start in iOS development because of the interface builder that allows you to design entire interfaces in drag and drop. By searching a little, we could notice very quickly that what often came back is the complexity induced by the use of Storyboard when the project becomes bigger. Having tried the Interface Builder, our first impression was that understanding it is like understanding Photoshop, there are so many tabs and buttons that you get lost. The interaction between the code and the storyboard is complicated. A string match will be used many times to link the code to the storyboard. In case there is a spelling error in the string, the application crashes during execution and not during compilation. Since we are using git, storyboard changes are complicated to track. Since the storyboards are not written in human-readable code, resolving merge conflicts is extremely difficult. After these misadventures with Storyboard, we tried SwiftUI, the first difference is that the interface is declarative so no more need for string matching to link the interface to the code. This implies that we will not be able to try to make a call to a deleted function that was linked by a string. Animations are easier to implement and above all, the application can be cross-platform (on all Apple platforms) because SwiftUI adapts the interface to the platform. Moreover, problems are detected at compile time and not during execution. Nevertheless, we had to make some concessions. SwiftUI is only usable from iOS 13.0. The community around SwiftUI is quite young and it is currently difficult to find help.

Architecture

For the architecture of our project, we chose to start with MVVM (Model View ViewModel) because we all had some basic knowledge of MVC architecture but we wanted to avoid code with interdependencies. We split our code into 4 main parts:

• Models (structs)

• The abstractions of the API calls (TeleportApi and OpenWeatherApi)

• The ViewModels (classes that contain all the logic of the application)

• The Views which are the components defining the interface of the application

The Views retrieve the data from the ViewModels which contain all the logic. The ViewModels execute the abstractions of the API calls to retrieve the data. The models are used to store the data retrieved from the API calls. Moreover, we followed an Apple tutorial where it was recommended to have only one data source to avoid unpacking between different data sources. So we grouped all the functions that allow creating, modification, or deleting a city in a single class that we named CityStore and grouped the functions that allow us to search a city in another class named CitySearchViewModel.

MVVM Pattern illustration - source We store the list of cities in an array except for the city where the user is geolocated. We write this list in a file which is then loaded at the start of the application.

How it works

Since we have a data persistence layer in the application, when we launch it, we check if the data file exists, if it doesn't exist or if there was an error reading it, we continue running the application. At the same time, we ask for authorization to use the geolocation. The home screen of the application is the screen displaying the city at the user's location. From there we slide from one screen to another to display the cities. We have a navigation bar at the bottom of the screen with a button to access the city management screen and another to access a weather map embedded in a WebView. On the city management screen, there is a list of cities, we can delete them and reorganize them. In addition to that, you can change the unit of measurement of the application. We can switch from imperial to metric units. There is a search bar that allows you to search for a city, visualize the weather at this position and add it to the list of saved cities.

Services and libraries used

To retrieve the weather, we used the OpenWeather API which provides data on several days and also hour by hour. On the side of the auto-completion and the search of the city based on latitude and longitude, we used the Teleport API. For animations based on the current weather, we used the Lottie library. Finally, for HTTP requests, we used the Alamofire library.

Demo

Source code

The source code is available on GitLab. To launch the project you have to get an API key from OpenWeather and add it to /Networkings/OpenWeatherApi.swift

I hope this helped you understand how Gryzle is born. If you have any questions, please send me a little message. I will be happy to help you. If you liked this article, please show some love and share it with your friends. Thank you for reading!

What will happen?

All servers, volumes, IPs and DNS records will be deleted on 2023 April 1st. To prevent data loss I sent you an email with:

• All your invoices

• All your SEO reports

• All your case studies (if you have some)

• All your source code and backups of your website or web app

• All your database backups

What's next?

While Snowtrust will be soon gone, there are plenty of web agencies you can reach out to today. To name a few:

• Studio Lumia providing you unbelievable photo-shoots

• Wordpress hosting provided by Cloud Lumia

• Marketing strategy provided by Etre commerçant

• All in one marketing agency Make By Web

In case of any questions feel free to reach out to me

Best, Hermann

A gauge is a view that shows a current level of a value in relation to a specified finite capacity, very much like a fuel gauge in an automobile. Gauge displays are configurable; they can show any combination of the gauge’s current value, the range the gauge can display, and a label describing the purpose of the gauge itself. Apple Developper documentation

Simplest Gauge

The simplest way to use the Gauge view is to pass a value to the init method. In it's most basic form, the value of the gauge is in 0.0 to 1.0 range.

// Most basic usage of the Gauge view
struct ContentView: View {
    var body: some View {
        Gauge(value: 0.5) {
            Text("Gauge")
        }
    }
}

Gauge with a range

You can also make the Gauge view display a value as a percentage of a range. The value must be between the range's minimum and maximum values. The Gauge view will display the value as a percentage of the range.

// Gauge view displaying a value as a percentage of a range
struct ContentView: View {
    var body: some View {
        Gauge(value: 25, in: 0...100) {
            Text("25% Gauge")
        }
    }
}

Gauge styles

You can customize the Gauge view by passing a GaugeStyle to the gaugeStyle modifier. The GaugeStyle protocol defines the appearance of the Gauge view. There are two default styles provided by SwiftUI: LinearGaugeStyle and RadialGaugeStyle. The available gaugeStyles are:

• .accessoryCircularCapacity

• .accessoryCircular

• .accessoryLinearCapacity

• .accessoryLinear

• .linearCapacity

• .automatic

// Gauge view displaying a value as a percentage of a range
    struct ContentView: View {
        var body: some View {
            Gauge(value: 25, in: 0...100) {
                Text("25% Gauge")
            }
        }
    }

Custom Gauge style

You can also create your own custom gauge style by conforming to the GaugeStyle protocol. The GaugeStyle protocol defines the appearance of the Gauge view.

// Custom GaugeStyle
struct CustomGaugeStyle: GaugeStyle {
    func makeBody(configuration: GaugeStyleConfiguration) -> some View {
        ZStack {
            Circle()
                .stroke(Color.gray, lineWidth: 10)
                .frame(width: 100, height: 100)
            Circle()
                .trim(from: 0, to: CGFloat(configuration.value))
                .stroke(Color.blue, lineWidth: 10)
                .frame(width: 100, height: 100)
                .rotationEffect(Angle(degrees: -90))
            Text("\(Int(configuration.value * 100))%")
                .font(.title)
        }
    }
}

// Custom GaugeStyle usage
struct ContentView: View {
    var body: some View {
        Gauge(value: 0.5) {
            Text("Gauge")
        }
        .gaugeStyle(CustomGaugeStyle())
    }
}

Our Temperature Gauge

And finally let's make a nice looking temperature gauge. We will use the accessoryLinear gauge style and a nice gradient tint modifier.

struct TemperatureGaugeView: View {
    private var min: Double = 7.0
    private var max: Double = 22.6
    private var current: Double = 12.6
    var body: some View {
        Gauge(value: current, in: min...max) {
            Text("Tinted Gauge")
        }
        currentValueLabel: {
            Text("\(Int(current))°")
        }
        minimumValueLabel: {
            Text("\(Int(min))°")
        } maximumValueLabel: {
            Text("\(Int(max))°")
        }
            .tint(Gradient(colors: [.green, .yellow, .orange, .red]))
            .gaugeStyle(.accessoryLinear)
    }
}

Conclusion

I hope this tutorial helped you understand how to use the Gauge view in SwiftUI. If you have any questions, please send me a little message, I will be happy to help you. If you liked this tutorial, please share it with your friends. Thank you for reading!