DEV Community: zakaria chahboun

Gaomon Finally Released Full-Featured Linux Drivers for Their Graphic Tablets

zakaria chahboun — Mon, 19 Jan 2026 00:09:31 +0000

For years, using a graphic tablet on Linux usually meant relying on community-driven solutions or partial support. Linux users often had to choose between unofficial drivers, manual configuration, or missing features.

That’s why this update from Gaomon is worth highlighting.

Gaomon has finally released official Linux drivers for their graphic tablets — and they come with full functionality, not just basic pen input.

I recently checked Gaomon’s website (I’ve been using the M10K Pro for years) and noticed that Linux drivers are now officially available. More importantly, they include features that are traditionally missing on Linux.

What’s included

The official Gaomon Linux drivers provide:

Full tablet configuration support
Ring Touch support
Easy installation process
A clean and modern graphical interface
Advanced customization for buttons, pressure, and tablet behavior

The support is not limited to a single device — all Gaomon tablet models, including older ones, are covered.

How this compares to existing Linux solutions

Before this release, Linux users mainly depended on two well-known options:

DIGImend drivers

DIGImend is a kernel-level open-source project that enables support for many drawing tablets on Linux. It provides solid low-level compatibility and is widely respected in the community. However, it usually lacks:

Vendor-specific configuration tools
Advanced features like ring controls
Polished graphical interfaces

DIGImend focuses on making the hardware work, not on user experience.

OpenTabletDriver

OpenTabletDriver is a popular cross-platform, user-space driver with a modern UI and powerful customization options. It works well for many artists and offers:

Extensive button and pressure configuration
Profile management
A clean UI across Linux, Windows, and macOS

That said, device support depends on reverse engineering, and some tablet-specific features may still be missing or incomplete.

Why Gaomon’s official drivers matter

Gaomon’s move brings something Linux users rarely get from hardware vendors:

First-party support
Full access to device-specific features
No need for reverse engineering or workarounds

This makes Gaomon tablets a much stronger option for Linux users working in:

Digital art and illustration
UI/UX design
Video editing
Note-taking and general productivity

Download

Official Gaomon Linux drivers are available here:

https://download.gaomon.net/plus/list.php?cateId=0&type=Driver&system=linux&Keyword=&tid=9#pcb

Final thoughts

Open-source projects like DIGImend and OpenTabletDriver are still essential to the Linux ecosystem, and many devices continue to rely on them.

But seeing a manufacturer like Gaomon ship fully featured, official Linux drivers is a big win. Hopefully, this encourages more hardware vendors to treat Linux as a first-class platform — not an afterthought.

If you’re curious about practical use cases for graphic tablets beyond drawing, I’ve also shared a short video on my channel covering real-world workflows.

Making Retype Docs AI-Ready with llms.txt Automation

zakaria chahboun — Sat, 10 Jan 2026 07:59:32 +0000

Keeping documentation up to date is one thing! helping your team or partners quickly digest changes is another. At my company, we use Retype for our docs, and we wanted a way to make them instantly AI-ready for summarization, search, or internal tooling.

Enter retype_llms: a lightweight GitHub Action and Python tool that generates a llms.txt file directly from your Markdown docs. Instead of manually exporting files or worrying about URLs and images, this tool handles it automatically.

Why `llms.txt`?

If you’ve ever tried feeding docs to AI tools or building search indexes, you know the challenge: multiple Markdown files, relative images, front-matter headers, and custom routes can all break the context.

retype_llms solves this by:

Consolidating all your Markdown into a single, structured file
Removing YAML front-matter that confuses AI
Adding clear section markers with file paths and URLs
Resolving relative image paths to absolute URLs if needed
Preserving your Retype routing logic for accurate links

This means your AI tools, or even scripts that analyze your docs, get clean, structured, ready-to-use content.

How it Fits in Your Workflow

Whether you prefer Python scripts or GitHub Actions, retype_llms fits seamlessly:

Python script: Run locally or in CI to generate llms.txt on demand.
GitHub Action: Automatically generate llms.txt on every push, optionally before Retype builds your site. The file lands in your static/ folder, ready to use.

Example: Using with Retype Build Action

You can integrate retype_llms directly before your Retype build to make sure llms.txt is always up to date:

name: Build Retype Documentation
on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate llms.txt
        uses: zakaria-chahboun/retype_llms@v2.0.0

      - name: Build Retype
        uses: retypeapp/action-build@latest

      - name: Deploy to GitHub Pages
        uses: retypeapp/action-github-pages@latest
        with:
          update-branch: true

It’s designed to require zero changes to your existing Retype setup 😎 just add it to your workflow, and it works.

Behind the Scenes

The tool respects Retype’s logic:

Input detection: Automatically finds the Markdown source folder from retype.yml
Routing: Generates URLs that match Retype’s permalink, route, and index file rules
Slugification: Matches Retype’s lowercase-hyphen URL style
Statistics: Reports number of files, word count, and estimated tokens ✨ handy for AI integration

All of this ensures the llms.txt output mirrors your documentation structure accurately, without any manual cleanup.

Why You’ll Love It

Fully automated: no copying or exporting files
Keeps links and images intact for AI or scripts
Works with GitHub Pages and existing Retype builds
Lightweight and easy to set up

Check it out here and give it a spin: 👉 https://github.com/zakaria-chahboun/retype_llms

This small addition can save hours of manual work and make your docs AI-ready in minutes.

Happy documenting! 🚀

Say Goodbye to WebSockets? Why SSE Might Be Your New Best Friend

zakaria chahboun — Tue, 11 Feb 2025 18:02:29 +0000

Introduction

Hey fellow devs! 👋 Today, let's dive into Server-Sent Events (SSE) and explore why they might be your next favorite tool for real-time communication. If you've been relying on traditional request-response methods or wrestling with WebSocket complexity, SSE might be the simpler solution you've been looking for!

Introduction
What are Server-Sent Events?
Key Benefits
SSE Message Format
Simple Code Examples
SSE vs WebSockets
Best Use Cases
Pro Tips
Conclusion

What are Server-Sent Events?

SSE is a standard that enables servers to push real-time updates to clients over a single HTTP connection. Think of it as a one-way communication channel where your server can send updates whenever it wants, without the client having to ask for them repeatedly.

Key Benefits

1. Low Latency for Real-Time Updates

Imagine you're building a chat app. Instead of your users constantly asking "any new messages?" (polling), the server can instantly push new messages to them.

2. Efficient Resource Usage

No more polling! The server only sends data when there's actually something new to share.

3. Simpler than WebSockets

While WebSockets are powerful, SSE uses standard HTTP and is much simpler to implement.

4. Built-in Reconnection

Lost connection? No worries! SSE automatically handles reconnection for you.

SSE Message Format

Before we jump into the code, let's understand the SSE message format. The server sends messages in this format:

event: myevent    // Optional: name of the event
data: message     // The actual message content
id: 123          // Optional: event ID for resuming connection
retry: 10000     // Optional: reconnection time in milliseconds

Each field must end with a newline (\n), and the message must end with two newlines (\n\n).

Simple Code Examples

Backend (Go)

package main

import (
    "fmt"
    "net/http"
    "time"
)

func sseHandler(w http.ResponseWriter, r *http.Request) {
    // Set headers for SSE
    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("Connection", "keep-alive")

    // Check if the ResponseWriter supports flushing
    flusher, ok := w.(http.Flusher)
    if !ok {
        http.Error(w, "Streaming unsupported", http.StatusInternalServerError)
        return
    }

    // Sending events every second
    for i := 0; i < 10; i++ {
        // Write SSE event format
        fmt.Fprintf(w, "event:welcome\ndata: Message %d\n\n", i)

        // Flush the response to send the event immediately
        flusher.Flush()

        // Simulate a delay
        time.Sleep(time.Second)
    }
}

func main() {
    http.HandleFunc("/events", sseHandler)
    fmt.Println("Server listening on :8080")
    http.ListenAndServe(":8080", nil)
}

Key Points:

w.Header().Set("Content-Type", "text/event-stream"): Ensures the client treats this as an SSE connection.
w.Header().Set("Cache-Control", "no-cache"): Prevents caching of the SSE stream.
w.Header().Set("Connection", "keep-alive"): Keeps the connection open for continuous

Frontend (JavaScript)

// Basic SSE connection
const eventSource = new EventSource('http://localhost:8080/events');

// Handle regular messages
eventSource.onmessage = (event) => {
    console.log('Received message:', event.data);
    document.getElementById('messages').innerHTML += `<p>${event.data}</p>`;
};

// Handle named events
eventSource.addEventListener('welcome', (event) => {
    console.log(event.data);
});

// Handle connection open
eventSource.onopen = () => {
    console.log('Connection opened!');
};

// Handle errors
eventSource.onerror = (error) => {
    console.log('Error occurred:', error);
};

// To close connection when needed
function closeConnection() {
    eventSource.close();
}

SSE vs WebSockets: When to Use What? 🤹

While both SSE and WebSockets are used for real-time communication, here’s a quick comparison:

Feature	SSE	WebSockets
Communication	One-way (server to client)	Two-way (bi-directional)
Setup Complexity	Simpler (works over HTTP)	More complex (requires WebSocket protocol)
Client Support	Well-supported by modern browsers	Supported in most modern browsers
Use Case	Ideal for notifications, live feeds, data updates	Ideal for chat, multiplayer games, full-duplex communication
Reconnection	Automatic reconnection built-in	Must handle reconnection manually

Best Use Cases for SSE 🎯

Live notifications
Real-time dashboards
Stock market updates
Social media feeds
Live sports scores
System monitoring

Pro Tips 💡

Message Types: You can send different types of events:

   // Regular message
   data: Your message here\n\n

   // Named event
   event: userconnected\n
   data: John joined\n\n

   // Multiple data lines
   data: line 1\n
   data: line 2\n\n

Reconnection Control: Set custom retry time:

   retry: 5000\n\n

Event IDs: Track message sequence:

   id: 12345\n
   data: Your message here\n\n

Full Example: All SSE Properties:

   event: notification\n
   data: Payment is successful\n
   retry: 5000\n
   id: transaction-id-12345\n\n

   event: notification\n
   data: Shipping update: Your package has been dispatched\n
   retry: 5000\n
   id: shipping-id-98765\n\n

Conclusion 🎉

SSE is a powerful yet simple tool for real-time updates. It's perfect when you need server-to-client updates without the complexity of WebSockets. The built-in features like automatic reconnection and the simple HTTP-based protocol make it a great choice for many real-time applications.

Have you used SSE in your projects? What has been your experience? Let me know in the comments below! 👇

Happy coding! 🍉

Stop Fighting Go Errors: A Modern Approach to Handling Them

zakaria chahboun — Mon, 10 Feb 2025 15:21:16 +0000

Error handling is the unsung hero of robust software development. In this guide, we'll dive into a comprehensive error handling strategy that keeps your Go applications clean, informative, and maintainable.

Error Handling Strategy Overview
The Error Handling Pyramid: Where and How to Handle Errors
- Utility Layer: Keep It Simple
- Service Layer: Add Context
- HTTP Handler: Log and Protect
When to Define Custom Error Types?
🏆 Conclusion & Rules

Error Handling Strategy Overview

Where?	What to Do?	Why?
Low-level functions (utils, DB calls, API calls, etc.)	Return errors as-is (don't log)	Callers higher up should decide how to handle the error
Business logic (services, middle-layer functions)	Wrap errors using `%w`	Adds context while preserving original error details
HTTP Handlers, CLI commands, or main()	Log errors, return user-friendly messages	Avoid exposing internal details to users

The Error Handling Pyramid: Where and How to Handle Errors

Let's break down error handling across different layers of your application:

1. Utility Layer: Keep It Simple 🛠️

//utils/user.go
package utils

import (
    "errors"
    "fmt"
)

var ErrUserNotFound = errors.New("user not found")

func FetchUserFromDB(userID int) (string, error) {
    if userID <= 0 {
        return "", ErrUserNotFound
    }
    return "John Doe", nil
}

Why not wrap here?

This is a utility function; wrapping it would add unnecessary details.
If every function wraps errors, unwrapping becomes a nightmare.
Return errors as-is. Let higher layers decide how to handle them.

Note 👇:

If your utility function calls another function (e.g., JSON parsing, SQL query execution) that returns an error, you generally still want to return the error as-is in the utility layer.

2. Service Layer: Add Context 🔍

// service/user.go
func GetUserProfile(userID int) (string, error) {
    user, err := utils.FetchUserFromDB(userID)
    if err != nil {
        // Wrap the error with context while preserving the original error 😉
        return "", fmt.Errorf("failed to get user profile: %w", err)
    }
    return user, nil
}

Why wrap here?

Adds context (e.g., "failed to get user profile").
Maintains stack trace for better debugging.
If multiple functions call FetchUserFromDB, each can add its own context.

3. HTTP Handler: Log and Protect 🛡️

// handlers/user.go
var logger = slog.New(slog.NewJSONHandler(os.Stdout, nil))

func UserHandler(w http.ResponseWriter, r *http.Request) {
    user, err := service.GetUserProfile(userID)
    if err != nil {
        // Catch our specific error because we already know it 😎
        if errors.Is(err, utils.ErrUserNotFound) {
            http.Error(w, "User not found", http.StatusNotFound)
            return
        }

        // Log unexpected errors with additional context for debugging
        logger.Error("Failed to process user request",
                     "error", err, "userID", userID)

        // Return a generic internal server error for unknown issues
        http.Error(w, "Internal Server Error",
                   http.StatusInternalServerError)
    }
}

Why log here instead of inside GetUserProfile?

The handler is responsible for logging.
We unwrap and check errors for specific cases (ErrUserNotFound).
Users see a friendly message instead of raw error details.

4. When to Define Custom Error Types?

Use sentinel errors (var ErrX = errors.New()) when errors have clear meaning (e.g., "user not found").
Use custom error types when errors have extra fields (e.g., HTTP status codes, detailed error codes).

type HTTPError struct {
    Code    int
    Message string
}

func (e *HTTPError) Error() string {
    return fmt.Sprintf("%d: %s", e.Code, e.Message)
}

var ErrUnauthorized = &HTTPError{
    Code: 401,
    Message: "Unauthorized"
}

Now will use it in our handler:

// Simulation for authentication
func auth() error {
    return ErrUnauthorized // Simulated error
}

func handler(w http.ResponseWriter, r *http.Request) {
    err := auth()

    // Magic here 🤠 👇
    var httpErr *HTTPError
    if errors.As(err, &httpErr) {
        // If err is of type *HTTPError, extract it and use its status code and message
        http.Error(w, httpErr.Message, httpErr.Code)
        return
    }

    // If error is unknown, return a generic 500 Internal Server Error
    http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}

Hint 💡:

Using errors.As:
Inside the handler function, the errors.As(err, &httpErr) is used to check if the error err (in this case, ErrUnauthorized) is of type *HTTPError. The errors.As function performs a type assertion and, if the error matches the target type (*HTTPError), it assigns the value to the httpErr variable.

🏆 Conclusion & Rules

🚫 Don't log in low-level functions
🧩 Wrap errors in business logic for context
🌟 Log at HTTP/CLI level
🕵️ Use errors.Is() for known errors
🧸 Use errors.As() for custom error types

Happy coding! 🍉

Go Context — TODO() vs Background() No more confusing!

zakaria chahboun — Mon, 09 Sep 2024 16:02:03 +0000

In Go, the context package helps manage request-scoped values, cancellation signals, and deadlines.
Two common ways to start a context are context.TODO() and context.Background().
Though they behave similarly, they serve different purposes.

context.Background()

context.Background() is the default when you don’t need any special handling (like cancellation or deadlines).
It's often used in main, init, or when initializing operations that don't need a more specific context.

Example:

 func main() {
     ctx := context.Background()
     server := http.Server{Addr: ":8080", BaseContext: func(net.Listener) context.Context {
         return ctx
     }}
     log.Fatal(server.ListenAndServe())
 }

In this example, context.Background() is used to establish a base context for the HTTP server.

context.TODO()

context.TODO() is a placeholder context. Use it when you're unsure of what context to provide or when planning to refactor later.

Example:

 func processOrder() {
     ctx := context.TODO() // Placeholder, decision on context pending
     err := db.SaveOrder(ctx, orderData)
     if err != nil {
         log.Println("Failed to save order:", err)
     }
 }

Here, context.TODO() is temporarily used for a database operation until a more specific context is defined.

Key Differences

Both functions return an empty context, but they express different intentions:

context.Background(): Used when you're confident no special context features are needed.
context.TODO(): A temporary placeholder context, signaling future changes.

Conclusion

When to Use context.Background():

When initializing core services like HTTP servers or database connections.
When there's no need for cancellation, deadlines, or values.

When to Use context.TODO():

When refactoring, and you haven’t decided on the context yet.
When implementing early-stage code that requires future improvements.

Using defer in Go: Best Practices and Common Use Cases

zakaria chahboun — Mon, 19 Aug 2024 15:11:53 +0000

In Go, the defer keyword is a powerful tool that helps manage resources and ensure that cleanup actions are performed when a function exits. The deferred functions are executed when the surrounding function returns, whether it returns normally, due to an error, or because of a panic. This ensures that cleanup code runs regardless of how the function exits, making resource management simpler and more reliable.

Key Points about defer:

Execution Timing: Deferred functions are executed in LIFO (Last In, First Out) order when the surrounding function returns, either by completing its execution, encountering a return statement, or due to a panic.
Resource Management: It helps in automatically closing resources like files and network connections, unlocking mutexes, and performing other cleanup tasks.

1. Order of Multiple Defer Statements
2. Resource Cleanup
3. Unlocking Mutexes
4. Releasing Database Connections
5. Restoring State
6. Handling Panics
7. Logging and Timing
8. Flushing Buffers
9. Handling HTTP Request Bodies
10. Risk of Closing a Failed Opening Without defer
11. Risk of Using defer Before Checking if a File Was Opened
12. Conclusion

1. Order of Multiple Defer Statements

In Go, multiple defer statements within a function are executed in reverse order of their appearance. This is useful for managing multiple cleanup tasks, ensuring they are performed in a specific order when the function exits.

func exampleFunction() {
    fmt.Println("Start of function")

    defer fmt.Println("First defer: executed last")
    defer fmt.Println("Second defer: executed second")
    defer fmt.Println("Third defer: executed first")

    fmt.Println("End of function")
}

Output:

Start of function
End of function
Third defer: executed first
Second defer: executed second
First defer: executed last

2. Resource Cleanup

One of the most common uses of defer is to ensure that resources like files are properly closed after they are no longer needed.

func processFile(fileName string) error {
    file, err := os.Open(fileName)
    if err != nil {
        return err // Return the error if opening the file fails
    }
    defer file.Close() // Ensure the file is closed when the function exits

    // Process the file...
    return nil
}

os.File implements io.ReadCloser, so using defer here ensures that the file is closed properly, preventing resource leaks.

3. Unlocking Mutexes

When working with concurrency, it’s crucial to release locks to prevent deadlocks. defer helps manage mutexes effectively.

var mu sync.Mutex

func criticalSection() {
    mu.Lock()
    defer mu.Unlock() // Ensure the mutex is unlocked when the function exits

    // Critical section...
}

By deferring mu.Unlock(), you ensure that the mutex is always released, making the code easier to understand and less error-prone.

4. Releasing Database Connections

Database connections should be closed when they are no longer needed to free up resources.

func queryDatabase() error {
    db, err := sql.Open("driver", "database=example")
    if err != nil {
        return err
    }
    defer db.Close() // Ensure the database connection is closed when the function exits

    // Query the database...
    return nil
}

5. Restoring State

Example: Changing and Restoring Working Directory

When changing the working directory, it’s important to restore it to its original state.

func changeDirectory() error {
    oldDir, err := os.Getwd()
    if err != nil {
        return err
    }
    err = os.Chdir("/tmp")
    if err != nil {
        return err
    }
    defer os.Chdir(oldDir) // Restore the working directory when the function exits

    // Work in /tmp...
    return nil
}

Using defer makes it easy to restore the original directory automatically.

6. Handling Panics

Example: Recovering from Panics

defer can be used to recover from panics and handle errors gracefully.

func safeFunction() {
    defer func() {
        if r := recover(); r != nil {
            log.Println("Recovered from panic:", r)
        }
    }()
    // Code that might panic...
}

By deferring a function that handles panics, you can ensure that your application remains robust even in the face of unexpected errors.

7. Logging and Timing

Example: Timing Function Execution

defer is useful for measuring execution time or logging when a function exits.

func measureTime() {
    start := time.Now()
    defer func() {
        duration := time.Since(start)
        log.Printf("Execution time: %v", duration)
    }()

    // Code to measure...
}

This approach simplifies timing code and ensures that the duration is logged when the function completes.

8. Flushing Buffers

Example: Flushing Buffered I/O

Buffered I/O operations should be flushed to ensure that all data is written out.

func bufferedWrite() {
    buf := bufio.NewWriter(os.Stdout)
    defer buf.Flush() // Ensure the buffer is flushed when the function exits

    buf.WriteString("Hello, World!")
}

Using defer here guarantees that any buffered data is written out before the function completes.

9. Handling HTTP Request Bodies

Example: Closing HTTP Request Body

HTTP request bodies implement io.ReadCloser, so it’s crucial to close them after use to free up resources and avoid leaks.

func handleRequest(req *http.Request) error {
    // Ensure that the request body is closed when the function exits
    defer func() {
        if err := req.Body.Close(); err != nil {
            log.Println("Error closing request body:", err)
        }
    }()

    body, err := io.ReadAll(req.Body)
    if err != nil {
        return err
    }

    // Process the body...
    fmt.Println("Request body:", string(body))

    return nil
}

By deferring the req.Body.Close(), you ensure that the body is closed properly, even if an error occurs while reading or processing it.

10. Risk of Closing a Failed Opening Without defer

When you open a file or other resource in Go, it’s crucial to ensure that the resource is properly closed once it’s no longer needed. However, if you attempt to close a resource after error checking without using defer, you could introduce risks into your code.

Example Without defer

file, err := os.Open(fileName)
if err != nil {
    return err // Handle error
}
// Risk: If something goes wrong before this point, the file might never be closed
// Additional operations here...
file.Close() // Attempt to close the file later

Not using defer to close resources in Go can lead to unintended consequences, such as attempting to close a resource that was never successfully opened, resulting in unexpected behavior or panics. Additionally, if an error occurs before the explicit Close() call, the resource might remain open, causing leaks and exhausting system resources. As the code becomes more complex, ensuring all resources are properly closed becomes increasingly difficult, raising the likelihood of overlooking a close operation.

11. Risk of Using `defer` Before Checking if a File Was Opened

In Go, it's crucial to place a defer statement after verifying that a resource, like a file, was successfully opened.
Placing defer before the error check can introduce several risks and undesirable behavior.

Example of Incorrect Usage

file, err := os.Open(fileName)
defer file.Close() // Incorrect: This should be deferred after the error check
if err != nil {
    return err // Handle error
}
// Additional operations here...

Placing defer file.Close() before checking if os.Open succeeded can cause several issues. If the file wasn't opened and is nil, attempting to close it will lead to a runtime panic since Go executes all deferred functions even when an error occurs. This approach also makes the code misleading, implying that the file was successfully opened when it might not have been, which complicates understanding and maintenance. Furthermore, if a panic does occur, debugging becomes more challenging, especially in complex codebases, as tracing the issue back to the misplaced defer can take additional effort.

12. Conclusion

The defer keyword in Go simplifies resource management and enhances code clarity by ensuring that cleanup actions are performed automatically when a function exits. By using defer in these common scenarios, you can write more robust, maintainable, and error-free code.

A Comprehensive Guide to Type Casting and Conversions in Go

zakaria chahboun — Sun, 18 Aug 2024 01:20:21 +0000

Go, also known as Golang, is a statically typed language. This means that the type of every variable is known at compile time, providing safety and predictability in your code. However, this also requires that any conversion from one type to another is explicit and deliberate. In this article, we’ll explore the various type casting and conversion mechanisms available in Go, from basic numeric conversions to more complex interface and pointer conversions.

1. Basic Type Conversions

Go allows conversion between basic types like integers, floating-point numbers, and strings, but these conversions must be done explicitly.

Numeric Types

Conversions between different numeric types are straightforward but must be explicit:

var i int = 42
var f float64 = float64(i)  // int to float64
var u uint = uint(i)        // int to uint

In this example, we convert an int to a float64 and to a uint. These conversions are explicit because Go does not perform automatic (implicit) type conversions.

String and Byte Slice

Go strings are immutable, but they can be converted to and from byte slices ([]byte), which are mutable:

var s string = "hello"
var b []byte = []byte(s)   // string to []byte
var s2 string = string(b)  // []byte to string

Similarly, you can convert between strings and rune slices ([]rune), where rune is a type alias for int32:

var r []rune = []rune(s)   // string to []rune
var s3 string = string(r)  // []rune to string

2. Custom Type Conversions

In Go, you can define your own types based on existing ones. Conversions between custom types and their underlying types are explicit:

type MyInt int
var i int = 10
var mi MyInt = MyInt(i)   // int to MyInt
var i2 int = int(mi)      // MyInt to int

This explicit conversion is necessary to ensure that the compiler can verify the safety of your code.

3. Pointer Conversions

Pointers in Go reference the memory address of a variable. You can convert between a value and its pointer:

var x int = 42
var p *int = &x     // int to *int (pointer to int)
var y int = *p      // *int to int (dereferencing)

4. Interface Type Conversions

Interfaces in Go are used to define a set of methods. You can convert between concrete types and interfaces:

var a interface{} = 42    // int to interface{}
var b int = a.(int)       // interface{} to int (type assertion)

Type Assertions

A type assertion provides access to an interface's concrete value:

if v, ok := a.(int); ok {
    fmt.Println("a is an int:", v)
}

Type Switch

A type switch allows you to perform different actions based on the dynamic type of an interface:

switch v := a.(type) {
case int:
    fmt.Println("a is an int:", v)
case string:
    fmt.Println("a is a string:", v)
default:
    fmt.Println("a is of unknown type")
}

5. Unsafe Conversions

The unsafe package allows you to bypass Go’s type safety, enabling conversions that would otherwise be illegal:

import "unsafe"

var i int = 42
var p *int = &i
var fp *float64 = (*float64)(unsafe.Pointer(p))  // *int to *float64

Warning: Unsafe conversions should be used sparingly and only when absolutely necessary, as they can lead to undefined behavior.

6. Channel Type Conversions

Channels are a powerful feature in Go, allowing communication between goroutines. You can convert between bidirectional and unidirectional channels:

ch := make(chan int)
var sendOnlyChan chan<- int = ch  // bidirectional to send-only
var recvOnlyChan <-chan int = ch  // bidirectional to receive-only

7. Struct and Array Conversions

Conversions between structs or arrays with identical layouts require explicit casting:

type Point struct {
    X, Y int
}

type Coord struct {
    X, Y int
}

var p Point = Point{1, 2}
var c Coord = Coord(p)  // Convert Point to Coord (same field types)

8. Slice Conversions

Slices are references to arrays, and while you can convert between slices of the same type, converting between different types of slices requires an explicit conversion:

var a []int = []int{1, 2, 3}
var b []int = a[1:]  // Convert a slice to another slice of the same type

9. Nil Interface Conversions

A nil value in Go can be assigned to any interface type:

var x interface{} = nil
var y error = nil

10. Function Type Conversions

Go functions can be converted to different types, provided the signatures are compatible:

type FuncType func(int) int

func square(x int) int {
    return x * x
}

var f FuncType = FuncType(square)  // Convert function to FuncType

11. Array-to-Slice Conversion

You can create a slice from an array, which is essentially a reference to the array:

var arr [5]int = [5]int{1, 2, 3, 4, 5}
var sl []int = arr[:]  // Convert array to slice

Conclusion

Type casting and conversions in Go are explicit by design, making the code safer and easier to understand. By requiring explicit conversions, Go helps prevent subtle bugs that can arise from implicit type coercion, common in some other programming languages. Understanding these conversions and using them correctly is crucial for writing robust and efficient Go programs.

Supabase, Self-hosting with Podman Instead of Docker!

zakaria chahboun — Fri, 23 Sep 2022 07:03:14 +0000

Supabase, Self-hosting with Podman!

Supabase is an open source Firebase alternative providing all the backend features you need to build a product. You can use it completely, or just the features you need. Start a project with the hosted platform or learn how to host Supabase yourself with podman 👇.

Install requirements

You need to install podman, podman-docker and docker-compose

i'm using linux pop_os

sudo apt-get -y install podman podman-docker docker-compose

in your ~./bashrc file add docker as a podman alias (alias docker=podman)

Now. You have to clone the supabase repo:

git clone --depth 1 https://github.com/supabase/supabase

Then:

# Go to the docker folder
cd supabase/docker

# Copy the fake env vars
cp .env.example .env

Now. You have to configure docker hub mirror in /etc/containers/registries.conf :

sudo nano /etc/containers/registries.conf

Add these lines to the end of the file:

unqualified-search-registries = ['docker.io']

[[registry]]
prefix = "docker.io"
location = "docker.io"

[[registry.mirror]]
prefix = "docker.io"
location = "docker.mirrors.ustc.edu.cn"

Save it! Now. You are ready to install supabase studio:

sudo docker-compose up

Finally. visit http://localhost:3000 to start using Supabase Studio.

In case you face this error:

ERROR: for db error preparing container 22e6838a1fd10267d63f69ef400000a84a1a857a5e46718003f8a5f63388bb0f for attach: cannot listen on the TCP port: listen tcp4 :5432: bind: address already in use

Just change the POSTGRES_PORT in .env file.

😊 Enjoy!
🐦 My Twitter

Sapper(svelte) + CodyFrame Ui

zakaria chahboun — Sun, 07 Jun 2020 21:58:11 +0000

Sapper + Codyframe

This project is a template for Sapper if you want to work with CodyFrame framework UI (From Cody House), And you want to compile the SASS files and using it directly with Rollup 👌

Note: You can clone this template directly or you can follow the instructions below 🍵

First things 🤚

After getting the template of sapper for Rollup by:

👉 npx degit "sveltejs/sapper-template#rollup" my-app

You have to install the ordinary dependencies by:

👉 npm install

And try to run it (on http://localhost:3000) by:

👉 npm run dev

Issues could happen 📛

If you have this issue:

UnhandledPromiseRejectionWarning: Error: No valid exports main found for /..node_modules/@rollup/pluginutils

Just remove the rollup package from npm and reinstall a new version of it like "2.13.0".

Also if you don't have Polka install it by:

npm install --save polka

You can use express js 🌱 instead of Polka, learn how to do that from this Youtube video

Dependencies for SASS compiler 🏵️

svelte-preprocess 👈
autoprefixer 👈
node-sass 👈

npm install -D node-sass autoprefixer svelte-preprocess

yarn add -D node-sass autoprefixer svelte-preprocess

Rollup Configurations 🦊

Inside the rollup.config.js file, add these lines outside of export default to be accessible globally:

// for sass (codyframe)
import sveltePreprocess from 'svelte-preprocess';
const preprocess = sveltePreprocess({
  scss: {
    includePaths: ['src'],
  },
  postcss: {
    plugins: [require('autoprefixer')],
  },
});

Also add these lines in both 🤠 Client and Server sections inside of svelte({...}):

svelte({
  ...
  preprocess // Add this line
  ...
}),

Get the CodyFrame 🤦‍♂

Clone the official project from GitHub: Here

We just want the assets folder 🙄, So copy it inside codyframe folder in your src folder (src/codyframe) .

We want the style.scss and util.js later 👌.

Sapper Tepmlate File 🍪

In the top of template.html file in the src folder, We have to add a class="js" attribute to the <html ..> tag:

<html class="js">

Sapper Layout File 🐧

In _layout.svelte file inside of routes folder, We want to be sure that codyframe script run after the DOM is loaded 👧, So for that we have to use onMount from svelte just like this:

<script>
  import { onMount } from "svelte";

  let codyFrameScripts = "";
  onMount(async () => {
    // ---- To mount the CodyFrame scripts ----
    codyFrameScripts = "codyframe/util.js";
  });
</script>

Then we can now add the javascript libraries to the head tag like that:

<!--  cody framework - js libraries -->
<svelte:head>
    <script defer src={codyFrameScripts}></script>
</svelte:head>

And of course we have also to import the scss style 🌻!

<!-- Codyframework Global Scss -->
<style lang="scss" global>
@import "./codyframe/assets/css/style.scss"
</style>

Last Step! 🤗

Don't forget to add util.js inside of codyframe folder in the static folder of your project 👈.

Testing! 👍

In your index.svelte route, Add any code to test codyframe components, Like this Button:

 <div><button class="btn btn--primary btn--md">Zaki Button!</button></div>

One more thing! 👎

The codyhouse doesn't have components for modern JavaScript frameworks like Svelte/Vue/React .., And also his bad JavaScript functionality run one time when the page is loaded 🤦‍♂

So you'll get a lot of troubles when you work with a SPA project (Single Page Application), But there is a solution out of the box from sapper 💕

Each time you have to switch to another route, You have to be sure that the link (for example) <a href="/profile"> has a rel="external" attribute:

<a rel="external" href="/profile">

DEV Community: zakaria chahboun

Gaomon Finally Released Full-Featured Linux Drivers for Their Graphic Tablets

What’s included

How this compares to existing Linux solutions

DIGImend drivers

OpenTabletDriver

Why Gaomon’s official drivers matter

Download

Final thoughts

Making Retype Docs AI-Ready with llms.txt Automation

Why llms.txt?

How it Fits in Your Workflow

Example: Using with Retype Build Action

Behind the Scenes

Why You’ll Love It

Say Goodbye to WebSockets? Why SSE Might Be Your New Best Friend

Introduction

Table of Contents

What are Server-Sent Events?

Key Benefits

1. Low Latency for Real-Time Updates

2. Efficient Resource Usage

3. Simpler than WebSockets

4. Built-in Reconnection

SSE Message Format

Simple Code Examples

Backend (Go)

Frontend (JavaScript)

SSE vs WebSockets: When to Use What? 🤹

Best Use Cases for SSE 🎯

Pro Tips 💡

Conclusion 🎉

Stop Fighting Go Errors: A Modern Approach to Handling Them

Table of Contents

Error Handling Strategy Overview

The Error Handling Pyramid: Where and How to Handle Errors

1. Utility Layer: Keep It Simple 🛠️

2. Service Layer: Add Context 🔍

3. HTTP Handler: Log and Protect 🛡️

4. When to Define Custom Error Types?

🏆 Conclusion & Rules

Go Context — TODO() vs Background() No more confusing!

context.Background()

Example:

context.TODO()

Example:

Key Differences

Conclusion

Using defer in Go: Best Practices and Common Use Cases

Key Points about defer:

Table of Contents

1. Order of Multiple Defer Statements

2. Resource Cleanup

3. Unlocking Mutexes

4. Releasing Database Connections

5. Restoring State

6. Handling Panics

7. Logging and Timing

8. Flushing Buffers

9. Handling HTTP Request Bodies

10. Risk of Closing a Failed Opening Without defer

11. Risk of Using defer Before Checking if a File Was Opened

Example of Incorrect Usage

12. Conclusion

A Comprehensive Guide to Type Casting and Conversions in Go

1. Basic Type Conversions

Numeric Types

String and Byte Slice

2. Custom Type Conversions

3. Pointer Conversions

4. Interface Type Conversions

Type Assertions

Type Switch

5. Unsafe Conversions

6. Channel Type Conversions

7. Struct and Array Conversions

8. Slice Conversions

9. Nil Interface Conversions

10. Function Type Conversions

11. Array-to-Slice Conversion

Why `llms.txt`?

11. Risk of Using `defer` Before Checking if a File Was Opened