DEV Community: Usk

flame updates

Usk — Mon, 14 Apr 2025 16:30:00 +0000

I occasionally use Flame for game development in Flutter, and since there have been several recent updates, I took some time to review the changes and note my impressions.

v1.25.0

Release note

FEAT: Add a setter for TextBoxComponent.boxConfig and add a convenience method to skip per-char buildup (#3490).

It appears to have become easier to dynamically adjust text display speed and settings. There's also now a convenient option to instantly display the full text instead of building it up character by character, which should make handling dialogue in games much smoother.

v1.26.0

Release note

Custom Attributes Syntax

FEAT: Support custom attributes syntax to allow for multiple styles in the text rendering pipeline (#3519).

It seems flame-markdown now supports applying multiple text styles. This could make text decoration and emphasis much simpler.

Layout Shrinkwrap

FEAT: Layout shrinkwrap (#3513).

I'm not entirely sure about this yet—perhaps it automatically fills in unused space? This needs further investigation.

Layout Components

FEAT: Layout Components (#3507).

These new components for managing UI layouts intuitively could significantly simplify UI design.

RotateAroundEffect

FEAT: Add RotateAroundEffect (#3499).

This new effect allows for easy rotation around a specific point. It seems visually appealing and useful.

v1.27.0

Release note

Updated lint package

FEAT: Bump to new lint package (#3545).

This is primarily an internal improvement, and we probably won't directly notice it much in daily development.

FunctionEffect

FEAT: The FunctionEffect, run any function as an Effect (#3537).

final functionEffect = FunctionEffect<SpriteAnimationGroupComponent<RobotState>>((target, progress) {
  if (progress > 0.7) {
    target.current = RobotState.idle;
  } else if (progress > 0.3) {
    target.current = RobotState.running;
  }
}, EffectController(duration: 10.0, infinite: true));

This new feature allows executing arbitrary functions based on specific conditions or time progression as effects. It should greatly enhance flexibility in state management and open up new possibilities.

Summary

Since I've only briefly interacted with Flame, there are aspects I still don't fully understand. However, I'd like to keep checking these updates regularly to deepen my understanding.

Once I find effective use cases or deepen my understanding further, I'll definitely share them in future articles.

Experimenting with Using an iPad as Your Main Display

Usk — Tue, 08 Apr 2025 16:00:00 +0000

At home I often need to work on a Mac mini that lives in a different room. There are dedicated gadgets—like wireless‑HDMI transmitters—that could mirror the screen, but I’d rather not buy new hardware. Since I already have an iPad lying around, I wondered if I could turn it into a makeshift secondary display. After some trial and error I managed to get a setup that’s good enough for daily use. Here’s what I did and how it feels.

Prerequisites

The Mac mini and the iPad are in separate rooms.
I don’t want to walk over to the Mac mini every time I start mirroring.
Ideally, the iPad should start mirroring automatically the moment I open the cover (not achieved—yet).
I’m using the Mac mini’s keyboard and trackpad. I’d love to use the iPad’s Magic Keyboard instead, but that’s on hold for now.

Quick summary — Use the “Move to iPad” option on the green maximise button

In macOS, when you hover over a window’s green maximise button, a hidden menu pops up. One of the options is Move to iPad, which mirrors that window to the nearest iPad.

That little option became the core of my workflow.

Automating the click with `cliclick`

Doing the hover‑and‑click dance by hand gets old fast, so I automated it with cliclick, a command‑line tool that moves the mouse cursor.

brew install cliclick

A sample command:

cliclick m:55,45

That moves the cursor to the area around the green button, makes the hidden menu appear, and from there we can automate the click on Move to iPad. In my setup I use the Visual Studio Code window as the anchor, but any app would work.

Putting it all together with AppleScript

I wrapped the whole sequence in AppleScript so one shortcut triggers everything.

tell application "System Events"
    -- Activate VS Code so we know where the window is
    tell application "Visual Studio Code" to activate
    delay 0.5

    -- Move the cursor (tweak coordinates for your screen)
    do shell script "/opt/homebrew/bin/cliclick m:55,45"
    delay 1 -- wait for the menu to appear

    -- Click the “Move to iPad” item
    do shell script "/opt/homebrew/bin/cliclick c:55,160"

    -- Beep so I know it ran (I can’t see the Mac mini’s screen)
    keystroke (ASCII character 7)
end tell

Assigning a keyboard shortcut

Save the AppleScript as a Quick Action in Automator and then bind it to any key:

System Settings → Keyboard → Keyboard Shortcuts → Services → General

From then on, one key press fires the script.

Real‑world impressions & quirks

Sometimes the Move to iPad menu item doesn’t appear. Running the script a couple of times usually fixes it.
I rely on the final beep to confirm the script executed, because I can’t see the Mac mini’s display.
I can check whether the iPad is recognised by looking for the shared‑screen icon that pops up in the Dock when I open a browser.

Current pain points

macOS occasionally asks for a password instead of Touch ID; the mirroring doesn’t start on that screen. I try to guess whether it’s the password prompt by listening for the Alt+Tab beep and then—fingers crossed—type the password blindly. (Yeah, scary.)
After mirroring starts I still need the Mac mini’s keyboard and trackpad on the desk. My dream setup would let me keep using the iPad’s Magic Keyboard once the screen is mirrored.

Things that didn’t work

Below are experiments that turned out to be unstable but might help someone else.

Driving System Settings directly

I first tried toggling displays via System Settings with AppleScript, but the UI element hierarchy was unreliable. For reference, here’s the script:

do shell script "open x-apple.systempreferences:com.apple.preference.displays"
delay 5

tell application "System Events"
    tell application process "System Settings"
        get every UI element of group 1 of group 2 of splitter group 1 of group 1 of window "Display" of application process "System Settings" of application "System Events"
        click pop up button "Add" of group 1 of group 2 of splitter group 1 of group 1 of window "Display" of application process "System Settings" of application "System Events"
        get every UI element of menu "Add" of pop up button "Add" of group 1 of group 2 of splitter group 1 of group 1 of window "Display" of application process "System Settings" of application "System Events"
        click menu item "{iPadName}" of menu "Add" of pop up button "Add" of group 1 of group 2 of splitter group 1 of group 1 of window "Display" of application process "System Settings" of application "System Events"
    end tell
end tell

Using the Control Center from the keyboard

After enabling Full Keyboard Access, I tried to start mirroring from the Control Center that pops up with fn + C, but I couldn’t find any way to reproduce that keystroke.

Wrapping up

For now, the cliclick approach is good enough to live with. I still have some gripes, but they’re within tolerance. I might eventually buy a tiny wireless display or a wireless‑HDMI kit, but that’s a future project.

If you’ve found a cleaner way—especially one that lets me keep using the iPad’s Magic Keyboard after mirroring—please let me know!

Cheers 👋

TIL Weekly #3

Usk — Mon, 10 Feb 2025 16:00:00 +0000

Learning/Researching

Go (Golang)
- Posted: Concurrency and Goroutines in Go: A Deep Dive into sync.Mutex

Upcoming Learning Goals

Deepen my understanding of the context package.
Distinguish between data races and race conditions.
Explore the various methods in the sync package.

Conclusion

I now feel that I have a basic understanding of goroutines, so I am shifting my focus to studying the context package. The more I learn, the more I realize how many terms and concepts I need to master. For example, I recently discovered that data races and race conditions are distinct concepts, which underscores the importance of fully grasping concurrency issues. Overall, it seems that I can finally begin investigating the context package — my original goal — so I consider this a meaningful progress update. I plan to continue pushing forward and delve even deeper into these topics.

Concurrency and Goroutines in Go: A Deep Dive into sync.Mutex

Usk — Thu, 06 Feb 2025 16:00:00 +0000

Previous post. This time, I explored sync.Mutex to deepen my understanding of how mutex work in Go.

Overview

Using sync.Mutex prevents data races that can cause problems, such as updates not being applied correctly or unexpected behaviors. Specifically, by placing Lock and Unlock calls around accesses to shared resources, you can avoid inconsistencies between multiple goroutines.

You can also use the -race option to detect data races in your program. Applying this option during development or testing helps catch bugs at an early stage.

About sync.Mutex

https://pkg.go.dev/sync#Mutex

Starting from Go 1.18, TryLock was added, so now the mutex has three methods:

func (m *Mutex) Lock()
func (m *Mutex) TryLock() bool
func (m *Mutex) Unlock()

Typically, Lock and Unlock are sufficient. TryLock immediately returns false if it fails to acquire the lock, but as stated in Go’s official documentation, its use case is rare. If your design is appropriate, just Lock and Unlock will handle most scenarios.

Example Using Mutex

Below is a sample demonstrating a “docker pull-like progress display” while testing for potential data races. This time, you can specify via command-line argument whether to use a mutex or not.

When the mutex is used, the shared variable is correctly incremented the specified number of times. However, if you disable the mutex, the process might finish with a count below the intended number due to goroutine conflicts (increasing the first command-line argument often makes this easier to observe).

package main

import (
    "fmt"
    "math/rand"
    "os"
    "strconv"
    "sync"
    "time"
)

func main() {
    // set concurrency count
    if len(os.Args) < 3 {
        fmt.Println("Usage: go run main.go [number] [useMutex]")
        return
    }
    maxLoopCount, err := strconv.Atoi(os.Args[1])
    if err != nil || maxLoopCount <= 0 {
        fmt.Println("Invalid number. Please provide a positive integer.")
        return
    }

    useMutex, err := strconv.ParseBool(os.Args[2])
    if err != nil {
        fmt.Println("Invalid string. Please provide a true or false.")
        return
    }

    // A mutex to prevent conflicts during progress updates.
    var mu sync.Mutex

    // WaitGroup for waiting until each goroutine has completed
    var wg sync.WaitGroup

    loopCount := 0
    for i := 0; i < maxLoopCount; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            time.Sleep(time.Duration(rand.Intn(400)+100) * time.Millisecond)
            if useMutex {
                mu.Lock()
                loopCount++
                mu.Unlock()
            } else {
                loopCount++
            }
        }()
    }

    // A channel to signal that all goroutines have finished
    done := make(chan struct{})
    go func() {
        wg.Wait()
        done <- struct{}{}
    }()

    // Periodically draw the progress status on the screen
    ticker := time.NewTicker(10 * time.Millisecond)
    defer ticker.Stop()

    for {
        select {
        case <-ticker.C:
            // Clear the screen and redraw
            printProgress(maxLoopCount, loopCount, &mu)
        case <-done:
            // Display the final state and exit
            printProgress(maxLoopCount, loopCount, &mu)
            return
        }
    }
}

// printProgress is a function that displays the progress of each indicator
// Prevent concurrent access to progress data using a mutex
func printProgress(maxLoopCount int, loopCount int, mu *sync.Mutex) {
    mu.Lock()
    defer mu.Unlock()

    // Clear the screen using ANSI escape sequences
    // \033[H : Move the cursor to the home position
    // \033[2J : Clear the screen
    fmt.Print("\033[H\033[2J")
    fmt.Printf("max loop count: %d\n", maxLoopCount)
    fmt.Printf("current loop count: %d\n", loopCount)

    // Set the total width of the progress bar to 50 characters
    width := 50
    progress := int((float64(loopCount) / float64(maxLoopCount)) * 100)

    // Number of "*" characters based on progress percentage
    stars := progress * width / 100
    spaces := width - stars
    fmt.Printf("%d.[%s%s] %d%%\n", 1, repeat("*", stars), repeat(" ", spaces), progress)
}

// repeat: Returns concatenated string by repeating string "s" "count" times
func repeat(s string, count int) string {
    result := ""
    for i := 0; i < count; i++ {
        result += s
    }
    return result
}

As shown, whether or not you use the mutex can significantly affect the result. If multiple goroutines write to shared data without synchronization, data races are highly likely to occur.

The Race Option

Data Race Detector

Data races are among the most common and hardest to debug types of bugs in concurrent systems. A data race occurs when two goroutines access the same variable concurrently and at least one of the accesses is a write.

To help diagnose such bugs, Go includes a built-in data race detector. To use it, add the -race flag to the go command:

For instance, if you run go run -race main.go 100000 false on the sample program above, you might see an output like the following if a race condition exists:

==================
WARNING: DATA RACE
Read at 0x00c000126048 by goroutine 417:
  main.main.func1()
      /path/to/main.go:47 +0xe8

Previous write at 0x00c000126048 by goroutine 23:
  main.main.func1()
      /path/to/main.go:47 +0xf8

Goroutine 417 (running) created at:
  main.main()
      /path/to/main.go:39 +0x440

Goroutine 23 (finished) created at:
  main.main()
      /path/to/main.go:39 +0x440
==================

You can also use the -race option with go test or go build. If your code uses many goroutines, keeping the race detector on during development or testing can help find data races early.

About TryLock

As noted earlier, sync.Mutex in Go 1.18 and later includes the TryLock method. If the lock cannot be acquired, TryLock returns false immediately rather than blocking, unlike Lock. However, the official documentation mentions that use cases for this feature are rare. As shown in the example below, misusing TryLock can lead to unnecessarily complex logic, so caution is advised.

package main

import (
    "fmt"
    "sync"
)

func main() {
    var mu sync.Mutex

    fmt.Println("Start: Lock - Unlock")
    mu.Lock()
    mu.Unlock()
    fmt.Println("End: Lock - Unlock")
    fmt.Println("---")

    fmt.Println("Start: TryLock - Unlock")
    b := mu.TryLock()
    fmt.Printf("TryLock() result is %v\n", b)
    mu.Unlock()
    fmt.Println("End: TryLock - Unlock")
    fmt.Println("---")

    fmt.Println("Start: Lock - TryLock - Unlock")
    mu.Lock()
    b = mu.TryLock()
    fmt.Printf("TryLock() result is %v\n", b)
    mu.Unlock()
    fmt.Println("End: Lock - TryLock - Unlock")
    fmt.Println("---")

    fmt.Println("Start: TryLock - TryLock - Unlock")
    b = mu.TryLock()
    fmt.Printf("TryLock()1 result is %v\n", b)
    b = mu.TryLock()
    fmt.Printf("TryLock()2 result is %v\n", b)
    mu.Unlock()
    fmt.Println("End: TryLock - TryLock - Unlock")
    fmt.Println("---")

    fmt.Println("Start: Lock - Lock - Unlock")
    mu.Lock()
    mu.Lock() // This causes a deadlock
    mu.Unlock()
    fmt.Println("End: Lock - Lock - Unlock")

    fmt.Println("Done.")
}

Running this program gives:

$ go run trylock.go
Start: Lock - Unlock
End: Lock - Unlock
---
Start: TryLock - Unlock
TryLock() result is true
End: TryLock - Unlock
---
Start: Lock - TryLock - Unlock
TryLock() result is false
End: Lock - TryLock - Unlock
---
Start: TryLock - TryLock - Unlock
TryLock()1 result is true
TryLock()2 result is false
End: TryLock - TryLock - Unlock
---
Start: Lock - Lock - Unlock
fatal error: all goroutines are asleep - deadlock!

While calling Lock again inside a locked section causes a deadlock, TryLock does not block and returns false instead, thus avoiding a deadlock. You should carefully consider where this behavior is actually needed.

Conclusion

Use mutexes to avoid data races
- Data races are more likely if multiple goroutines simultaneously access shared data without synchronization.
- Race conditions can also occur in other scenarios, such as sharing data via channels.
Use the -race option to detect data races
- During development and testing, it helps discover issues early.
TryLock is rarely needed; Lock/Unlock is generally sufficient
- In most cases, proper design can be handled solely with Lock/Unlock.

That covers the basics of using sync.Mutex and detecting race conditions. By leveraging these techniques, you can increase the safety of your concurrent programs.

TIL Weekly #2

Usk — Tue, 04 Feb 2025 16:00:00 +0000

This Week: What I Learned, Read, and Did.

Learning/Researching

Go (Golang)
- Posted: Concurrency, Goroutines, and Channels in Go: A Study
- Currently learning about mutex and working on a post about them.

Reading

The Rules of Programming: How to Write Better Code
Several other Japanese books

Conclusion

I posted an article about Go goroutine, and I'm now studying mutex and writing a new article about them. Fully understanding the context package still feels a bit far off.

I also plan to tackle the pile of unread books I've accumulated. I've just started reading The Rules of Programming, so I don't have much of an impression yet.

Lastly, I cut down the number of podcast channels and Rss feeds I follow. Instead of those feeds and channels, I started a trial subscription with Audible. I hope this will reduce the constant urge to check for "new information" and help me focus on what's most important.

Concurrency, Goroutines, and Channels in Go: A Study

Usk — Wed, 29 Jan 2025 16:00:00 +0000

Abstract

This article explores the fundamental concepts of concurrency in Go, focusing on Goroutines and Channels.

Concurrency: The ability to handle multiple tasks in overlapping time periods. It does not imply that tasks are executed simultaneously, but rather that they are managed in a way that allows progress on multiple tasks within a given timeframe.
Goroutine: The smallest unit of execution in Go, enabling concurrent operations. Goroutines are lightweight threads managed by the Go runtime and can be created using the go keyword.
Channel: A conduit for communication and synchronization between Goroutines. Channels allow Goroutines to send and receive values of a specified type.
- Send: Sending a value to a channel using the syntax ch <- value.
- Receive: Receiving a value from a channel using the syntax value := <-ch.

Implementing a Simple Example Similar to Docker Pull

package main

import (
    "fmt"
    "math/rand"
    "os"
    "strconv"
    "sync"
    "time"
)


func main() {
    // Create random seed
    rand.Seed(time.Now().UnixNano())

    // Set concurrency count
    if len(os.Args) < 2 {
        fmt.Println("Usage: go run main.go [number]")
        return
    }
    n, err := strconv.Atoi(os.Args[1])
    if err != nil || n <= 0 {
        fmt.Println("Invalid number. Please provide a positive integer.")
        return
    }

    // A slice use to track the progress of each goroutine. (1 - 100)
    progress := make([]int, n)

    // A mutex to prevent conflicts during progress updates.
    var mu sync.Mutex

    // WaitGroup for waiting until each goroutine has completed
    var wg sync.WaitGroup
    wg.Add(n)

    // Create n goroutine
    for i := 0; i < n; i++ {
        go func(idx int) {
            defer wg.Done()
            // Each goroutine will update its progress until it reaches 100%
            for {
                // The loop breaks if progress reaches 100%
                mu.Lock()
                if progress[idx] >= 100 {
                    mu.Unlock()
                    break
                }
                // Add a random progress value (1-10%)
                inc := rand.Intn(10) + 1
                progress[idx] += inc
                if progress[idx] > 100 {
                    progress[idx] = 100
                }
                mu.Unlock()

                // Sleep for a random duration between 100 and 500 milliseconds
                time.Sleep(time.Duration(rand.Intn(400)+100) * time.Millisecond)
            }
        }(i)
    }

    // A channel to signal that all goroutines have finished
    // The channel uses struct{} as a signal. The actual data type is irrelevant since only the signal is needed.
    done := make(chan struct{})
    go func() {
        wg.Wait() // Wait until all wg(WaitGroup) are done.
        done <- struct{}{} // And send data to done channel. This channel is referenced by select statement below.
    }()

    // Periodically draw the progress status on the screen
    ticker := time.NewTicker(100 * time.Millisecond)
    defer ticker.Stop()

    for {
        select {
        case <-ticker.C:
            // Clear the screen and redraw
            printProgress(progress, &mu)
        case <-done:
            // Display the final state and exit
            printProgress(progress, &mu)
            return
        }
    }
}

// printProgress is a function that displays the progress of each indicator
// Prevent concurrent access to progress data using a mutex
func printProgress(progress []int, mu *sync.Mutex) {
    mu.Lock()
    defer mu.Unlock()

    // Clear the screen using ANSI escape sequences
    // \033[H : Move the cursor to the home position
    // \033[2J : Clear the screen
    fmt.Print("\033[H\033[2J")
    for i, p := range progress {
        // Set the total width of the progress bar to 50 characters
        width := 50
        // Number of "*" characters based on progress percentage
        stars := p * width / 100
        spaces := width - stars
        fmt.Printf("%d.[%s%s] %d%%\n", i+1, repeat("*", stars), repeat(" ", spaces), p)
    }
}

// repeat: Returns concatenated string by repeating string "s" "count" times
func repeat(s string, count int) string {
    result := ""
    for i := 0; i < count; i++ {
        result += s
    }
    return result
}

The program functions as follows:

What I Learned

Using Goroutines with the go Keyword: The go keyword allows the creation of goroutines, enabling concurrent execution of functions.
Concurrency with Goroutines: Goroutines facilitate concurrent processing, as demonstrated by managing the progress of multiple indicators simultaneously in this example.

Questions and Future Investigations

WaitGroup:
- Understanding that wg.Add increments the counter and wg.Done decrements it, and wg.Wait blocks until the counter reaches zero.
- Investigate additional functionalities and use cases of WaitGroup.
Mutex:
- Understanding that mutexes prevent race conditions by ensuring exclusive access to shared resources during updates.
- Curious about the specific issues that arise when mutexes are not used, such as inconsistent variable states.
- Interested in intentionally creating race conditions to observe and understand their effects.
Testing Methods:
- Learned about the go test -race flag for detecting race conditions.
- Plan to explore this testing method further to ensure code safety and reliability.

TIL Weekly 1

Usk — Thu, 23 Jan 2025 16:00:00 +0000

This Week: What I Learned, Read, and Did.

Learning/Researching

Go (Golang): Learning more about concurrency, goroutines, and channels.
AppleScript: Researching how to use my iPad as the main display for my Mac mini. ## Reading
The Toaster Project
Team Topologies
Several other Japanese books

Conclusion

I’ve started diving deeper into areas I’m interested in. In Go, I’m focusing on concurrency by studying goroutines and channels. My goal is to gain a solid grasp of them and then move on to the context package, which I see mentioned often but don’t fully understand yet.

I use a Mac mini as my primary computer, but I’d like more flexibility and mobility around the house. That’s w hy I’m looking into AppleScript to see if I can make my iPad function as the main display. I believe I’ve figured out most of the steps, and I’m close to achieving what I want.

I also read The Toaster Project, which was fascinating. Then I started reading Team Topologies, which had been sitting in my “read later” list. Although it might not be exactly what I need right now, it’s helpful for learning about team management strategies I might use in the future.

Finally, I’ve been reevaluating all the RSS feeds, podcasts, and YouTube channels I follow. While I love discovering new information, passively scrolling through massive amounts of content without proper reflection doesn’t actually help me learn. I also find it overwhelming to keep up with so many sources. Cutting down is a bit scary, but there’s no point in subscribing to more content than I can absorb. So this year, I plan to reduce my feeds and be more intentional about what I follow. If you have any recommendations, please let me know — thanks!

My First Post and Introduction

Usk — Wed, 15 Jan 2025 16:00:00 +0000

Hello there!

I’m a freelance web engineer, primarily working with Go and Vue. I also dabble in Flutter, and my ultimate goal is to one day make a living solely through my own indie development projects.

I love taking ideas I find exciting, turning them into something tangible, and having people actually use them. Eventually, I’d like to earn an income from those creations alone. That’s the dream I’m steadily working toward every day.

In this blog, I plan to write about the things I learn through my day-to-day work and the various technologies I look into for personal interest. I’ve noticed that I tend to focus more on consuming information than producing it, so I’m hoping this space will help me strike a better balance between input and output.

Specifically, I intend to post about:

• Insights and lessons from my everyday work

• Technologies I’ve been curious about or recently started exploring (e.g., testing, Rust, React, Flutter) and what I learn from them

• Dev logs from my personal development projects

There are so many things I’ve been meaning to learn “someday,” but I’ve never gotten around to them. Through this blog, I plan to tackle them one by one. I hope it can also be a source of inspiration or a point of connection for anyone else interested in freelancing or indie development.

Please feel free to leave comments or feedback—it really motivates me to keep going. I’ll be posting more articles as I continue to learn and stumble along the way, and I’d love to grow alongside you through sharing ideas. Let’s do our best together! Thanks for reading, and I look forward to connecting with you here!

DEV Community: Usk

flame updates

v1.25.0

v1.26.0

Custom Attributes Syntax

Layout Shrinkwrap

Layout Components

RotateAroundEffect

v1.27.0

Updated lint package

FunctionEffect

Summary

Experimenting with Using an iPad as Your Main Display

Prerequisites

Quick summary — Use the “Move to iPad” option on the green maximise button

Automating the click with cliclick

Putting it all together with AppleScript

Assigning a keyboard shortcut

Real‑world impressions & quirks

Current pain points

Things that didn’t work

Driving System Settings directly

Using the Control Center from the keyboard

Wrapping up

TIL Weekly #3

Learning/Researching

Upcoming Learning Goals

Conclusion

Concurrency and Goroutines in Go: A Deep Dive into sync.Mutex

Overview

About sync.Mutex

Example Using Mutex

The Race Option

About TryLock

Conclusion

TIL Weekly #2

Learning/Researching

Reading

Other Topics

Conclusion

Concurrency, Goroutines, and Channels in Go: A Study

Abstract

Implementing a Simple Example Similar to Docker Pull

What I Learned

Questions and Future Investigations

TIL Weekly 1

Learning/Researching

Other Topics

Conclusion

My First Post and Introduction

Automating the click with `cliclick`