So I decided to take the plunge and try building something small in React Native. The initial setup was surprisingly smooth thanks to Expo it really simplifies things.

I wanted to get the camera view rendering on my iPhone and it took a bit of tinkering. iOS permissions are always fun but after some digging and a rebuild I had it working. I used https://github.com/mrousavy/react-native-vision-camera to this. It is a nifty React Native camera library that is fully spec’d.

Here’s what I was able to implement in an hour:

It’s early days but it's been a refreshing experience exploring a different approach to mobile development. The framework feels quite different from Flutter and I’m enjoying learning a new way of doing things.

Right now, I'm just focused on getting the basics working and exploring what’s possible. It’s a fun little side project and I’m excited to see where it goes.

Maybe I’ll share a few updates as I progress but for now just wanted to share my little whim and the joy of exploring new technologies. Sometimes it’s good to just scratch that curious itch!

As a developer on the mobile team, I’ve been part of a small group piloting several AI platforms: Copilot, Cursor, and Claude Code. The goal isn’t to replace developers (far from it!), but to identify tools that can streamline repetitive tasks, accelerate problem-solving, and ultimately allow us to focus on the more creative and strategic aspects of our work.

Why Now? And What Am I Looking For?

The recent advancements in large language models (LLMs) have been genuinely impressive. These tools aren’t just about auto-completion anymore; they can understand context, generate complex code structures, and even help with debugging. I’m specifically looking for tools that can:

• Reduce boilerplate code: Mobile development often involves a lot of repetitive tasks. Can AI help us generate common components and structures more quickly?

• Accelerate problem-solving: Can AI help us identify potential bugs, suggest solutions to complex problems, and even generate test cases?

• Improve code quality: Can AI help us identify potential vulnerabilities, suggest improvements to our code style, and even generate documentation?

• Integrate seamlessly into our workflow: Can these tools work with our existing IDEs and version control systems without causing friction?

Early Observations: A Mixed Bag (But Promising)

I’ve been experimenting with these tools for a few weeks now, and the results have been mixed.

• Copilot: Excellent for auto-completion and generating simple code snippets, but sometimes struggles with more complex tasks.

• Cursor: A powerful IDE that integrates AI features seamlessly, but can be resource-intensive.

• Claude Code: Prioritizing security with a direct API connection to Anthropic. I’m also exploring how to integrate these tools with our existing CI/CD pipeline to automate code quality checks.

The Power of Connection: Leveraging Machine Control Protocol (MCP)

One particularly exciting development has been leveraging the Machine Control Protocol (MCP) to connect these AI models to our existing tools like GitHub, Jira, Slack, and more. This allows us to automate tasks like creating pull requests, updating bug reports, and posting notifications, significantly streamlining our workflow.

Ultimately, my goal is to leverage AI responsibly and improve the tools available to our development team. I believe that AI has the potential to augment our capabilities and allow us to focus on what we do best: building great mobile apps.

I originally envisioned this Substack as a space to explore the intersection of code and innovation, particularly diving into AI/ML concepts. While that’s still very much on my mind (and I promise to circle back!), lately I've found myself drawn in a different direction, one that requires slowing down rather than speeding up.

I’ve fallen headfirst into film photography.

It sounds almost counterintuitive for someone who spends their days building things with the latest technologies, but there's something incredibly grounding about it. In a world obsessed with instant gratification and pixel perfection, film forces you to be deliberate. To consider composition, light, and moment before pressing the shutter. It’s a different kind of rewarding than seeing code compile and run flawlessly.

I’ve always enjoyed photography. Over the years I've accumulated a bit of digital gear: my trusty Fuji X100F from 2017/2018 still gets plenty of use, alongside a mirrorless Fuji XT-5 and even a medium format beast, the GFX 100SII, which I love to bring on travels. But something was missing.

This year, during a trip to Taiwan, I picked up a pre-loved Olympus 35 DC with a beautiful vintage lens. And then, almost immediately after, a Pentax 17, that fascinating little half-frame camera released last year as part of the "PENTAX Film Camera Project." It captures two images per frame, which is just clever. Since then, I've been spending my weekends wandering around Singapore with these cameras, trying to capture moments in a way that feels more intentional.

And then came the splurge: a Leica M-A (Typ 127). Fully mechanical, no frills, and entirely manual. It was a costly purchase, buying it brand new, but I’m absolutely captivated by its compactness and elegance. I've been shooting street scenes, architectural details, still life. Just observing the world around me with a different lens (pun intended!).

I’ve experimented with various film stocks. Kodak Gold 200 has quickly become a favorite for its warm tones, but I'm also enjoying the challenge of black and white. And speaking of challenges… I recently decided to try developing my own film at home. Let’s just say my first attempt wasn’t exactly a success. One entire roll from a weekend walk wasted! But as any engineer knows, failure is simply another data point. A chance to learn and iterate.

It’s funny how different passions can complement each other. The precision and logic required for software engineering are balanced by the artistic freedom and tactile experience of film photography. Both demand problem-solving, but in vastly different ways.

I don’t know when I'll get back to deep dives into AI/ML (though it is still on my radar!). But for now, I'm content with slowing down, embracing the imperfections, and finding beauty in the analog world.

My journey started with the QuickStart guide, and I have to say, the setup process was surprisingly smooth. It’s often the biggest hurdle with new tools, but ADK made it easy. Leveraging a conda virtual environment, I had everything configured in minutes. That initial ease of entry really set the tone for the whole experience.

There were three main steps I went through the setup:

1. Setup the python environment (I used conda)

2. Setup the Python project with the QuickStart files

3. Obtain an API key from Google AI Studio

With all of above, I let the AI agent run with the command, adk web.

Once things were up and running locally, I was immediately struck by how intuitive the development process felt. The provided code is concise and well-documented, making it easy to grasp the core concepts. But what really made a difference was the integrated developer experience. ADK provides both a command-line interface and a visual Web UI for building and debugging agents.

Being able to visually inspect events, agent state, and execution steps in real-time dramatically simplified the process of understanding how my agent was thinking and interacting with tools. It felt like having a window into its “brain,” which was incredibly helpful as I learned the ropes.

What really excites me about ADK isn’t just building single AI components, but creating systems where multiple agents work together seamlessly. The framework is designed for this – allowing you to build modular applications with specialized agents coordinating and delegating tasks. It's a powerful concept that opens up a lot of possibilities.

And it’s clear Google has built ADK to integrate deeply within their cloud ecosystem. Optimized for Gemini models and offering a direct path to deployment on Vertex AI, it provides enterprise-grade scalability and reliability. The ability to connect to over 100 pre-built connectors to access data from sources like AlloyDB and BigQuery without duplicating it is a huge benefit, especially if you’re already invested in Google Cloud.

I'm eager to explore further how I can leverage this technology for mobile applications – perhaps building more sophisticated virtual assistants or AI-powered content recommendation engines. I also want to dive deeper into multi-agent architectures and experiment with the enhanced reasoning capabilities of Gemini 2.5 Pro.

Google’s Agent Development Kit feels like a significant step forward in making agentic AI accessible to developers. Its ease of setup, intuitive debugging tools, and powerful features make it an exciting platform for anyone looking to build the next generation of intelligent applications. I highly recommend checking out the official documentation and giving it a try – you might be as impressed as I am!

The Goal: Run Meta's Llama 4 Scout 17B-parameter, 16-expert model locally on my machine.

Why? Because understanding these models isn’t just about using APIs; it’s about getting hands-on and seeing what’s possible. Plus, the recent advancements in open-weight models like Llama 4 are incredibly exciting – a real shift towards more accessible AI development. Meta is really pushing this with Llama 4 Scout and Maverick being their first open-weight natively multimodal models!

My Setup: Apple M4 Macbook Pro (14-inch, 16-core CPU, 40-core GPU, 128GB Unified Memory).

The Challenge: Fitting it All In

Running a 17B parameter model isn’t trivial. Memory was my biggest concern. Thankfully, the quantized 4-bit version of Llama 4 Scout (available on Hugging Face) came to the rescue! This reduced the memory footprint to around 62GB, making it feasible for my machine.

The Process: A Step-by-Step Guide (for fellow engineers)

Here’s how I got it up and running:

1. Environment Setup:

conda create -n temp python=3.11 anaconda
conda activate temp
conda install git pip

# Commit f5b6f4b31323770f37ea51fea4f994a7ae584733 
pip install git+https://github.com/Blaizzy/mlx-vlm.git@main

1. Model Conversion (already done for me, thankfully!): The model was already converted to MLX format from meta-llama/Llama-4-Scout-17B-16E-Instruct using mlx-vlm version 0.1.21. This saved me a lot of initial headache.

2. Running the Model:

mlx_vlm.generate --model mlx-community/Llama-4-Scout-17B-16E-Instruct-4bit --max-tokens 100 --temperature 0.0 --prompt "hello"

The Results: Surprisingly Fast!

And… it worked! The model responded with: “Hello! It's nice to meet you. Is there something I can help you with, or would you like to chat?”

But the real surprise was the speed. I was getting around 43 tokens/sec for generation – significantly faster than the ~20 tokens/sec I typically see with Gemma 3 27B! This really highlights the performance benefits of running models optimized for Apple’s Metal architecture via MLX.

A Multilingual Test: Tagalog, My Mother Tongue

Llama 4 is designed to be multilingual, trained on a massive dataset including over 100 languages with over 1 billion tokens each! As a native Tagalog speaker, I had to put it to the test.

I asked it why it speaks Tagalog, and its response (translated below) was remarkably accurate and cohesive:

In Filipino: “Ako ay isang modelo ng wika na dinisenyo upang matuto at mag-adjust sa iba't ibang wika, kasama ang Tagalog….” In English: “I am a language model designed to learn and adapt to different languages, including Tagalog….“

It even acknowledged its limitations as a non-native speaker! I was genuinely impressed.

Key Takeaways & Next Steps:

• MLX is Powerful: The performance boost with MLX is undeniable.

• Quantization is Key: 4-bit quantization makes running large models on consumer hardware feasible.

• Open Source LLMs are Thriving: The Llama ecosystem is incredibly vibrant and accessible.

Today, my goal was achieved. I successfully ran Llama 4 Scout locally and verified its multilingual capabilities. My next experiment? Converting GGUF models to MLX! The journey continues…

For years, creating images with AI felt imperfect. Results were often blurry, distorted, or simply lacked artistic coherence. Stable Diffusion changed that. It’s not about an AI “painting” from scratch; instead, imagine a process of intelligent refinement. Think of it like this: you give the AI a starting point – your photo – and then guide it with text prompts, telling it what kind of image you want to create.

But how does it actually work? The core idea behind Stable Diffusion is surprisingly elegant. It operates on something called “diffusion models.” Traditionally, creating an image starts with pure noise—think static on a television screen. A diffusion model learns to reverse this process. It’s trained on massive datasets of images and gradually learns how to remove the noise, step-by-step, revealing recognizable patterns and details.

Stable Diffusion takes this concept further by working in a “latent space.” This is where things get slightly less intuitive, but bear with me. Instead of directly manipulating pixels (the tiny dots that make up an image), Stable Diffusion compresses images into a more manageable representation – essentially a simplified code. It then performs the noise removal process within this compressed space, making it much faster and requiring less computing power. This is why you can run Stable Diffusion on relatively accessible hardware, unlike some earlier AI image generators.

Once the refined image exists in the latent space, it’s “decoded” back into a full-resolution picture that we can see. The text prompt you provide acts as a guiding force throughout this entire process. It tells the model what to create while removing the noise – "in the style of Studio Ghibli," "a portrait with soft lighting," or even incredibly specific requests like “a cat wearing a tiny hat, painted by Van Gogh.”

What makes Stable Diffusion particularly powerful is its open-source nature. Unlike many AI models locked behind corporate walls, Stable Diffusion’s code is publicly available. This has fostered a vibrant community of developers and artists who are constantly refining the model, creating new tools, and expanding its capabilities. It's this collaborative spirit that has fueled the rapid innovation we see in AI image generation today.

The recent GPT-4o update from OpenAI (the creators of ChatGPT) leverages technology similar to Stable Diffusion, allowing users to easily create these Ghibli-inspired images directly within the chatbot interface. OpenAI is even taking steps to address concerns about mimicking living artists by adding safeguards that prevent direct style replication while still permitting broader stylistic influences like “studio styles.”

However, this ease of creation also raises important questions about copyright and artistic ownership. You can refer to my previous post on this topic.

The “Ghiblification” trend isn’t just a fleeting internet moment; it's a glimpse into a future where AI empowers creativity in new and exciting ways. Stable Diffusion has democratized image generation, putting the power of artistic expression into the hands of anyone with an idea and a computer. As the technology continues to evolve, it will be fascinating to see how artists and creators embrace these tools and redefine what’s possible in the world of visual media.

It started innocently enough. Curiosity piqued by the endless stream of “Ghiblified” images online, I wanted to see what all the fuss was about. The tools are surprisingly accessible now – a far cry from the complex machine learning models I usually wrestle with. I didn’t even end up using ChatGPT for this; lacking a paid subscription, I turned to ComfyUI, an open-source node-based interface for Stable Diffusion. It felt fitting somehow - building a system to build images, rather than simply prompting a service. Within minutes of setting that up, I was uploading photos and crafting prompts, hoping for a touch of Miyazaki magic.

And it worked. Sort of.

The AI dutifully churned out images that visually resembled Ghibli films. Soft colors, whimsical details, a certain… warmth. It’s undeniably impressive from a technical standpoint. The algorithms are clearly sophisticated enough to analyze an artistic style and apply it to new content. But as I scrolled through the results, something felt deeply off.

It wasn't about the quality of the images themselves – they were often quite beautiful. It was more… a hollowness. A lack of soul. Ghibli’s films aren’t just visually stunning; they’re imbued with a sense of humanity, of lived experience. Every line feels deliberate, every frame painstakingly crafted. This felt like imitation, a clever mimicry without understanding the underlying why.

I started thinking about the process itself. These AI models learn by consuming massive datasets – in this case, likely thousands upon thousands of Ghibli frames and images. They identify patterns, textures, color palettes… but they don’t understand the emotional weight behind those choices. They can replicate the how, but not the why.

And that's where it started to bother me. As someone who builds things, I value intention. Every line of code has a purpose, every design decision is made with a specific goal in mind. This felt… different. It felt like extracting aesthetic qualities without respecting the artistic process or the artist’s vision.

I stumbled across some old interviews with Hayao Miyazaki himself while researching this, and his reaction to AI animation resonated deeply. He described it as an “insult to life itself.” At first, I thought that was a strong statement, maybe even overly dramatic. But after spending hours playing with these tools, I started to understand what he meant.

It's not about fearing technology; it’s about recognizing the inherent value in human creativity and the unique perspective each artist brings to their work. Miyazaki’s films are born from his personal experiences, his observations of the world around him, his empathy for others. An algorithm can’t replicate that. It can only rearrange existing data.

The ethical implications also weigh heavily on my mind. These models are trained on copyrighted material without necessarily obtaining permission or providing compensation to the original artists. The legal battles surrounding AI and copyright are just beginning, but it feels fundamentally unfair to build a business model on the backs of creators who have dedicated their lives to honing their craft.

OpenAI, the company behind ChatGPT, seems aware of these concerns. They’ve implemented safeguards to prevent users from directly replicating the style of living artists, opting instead for broader “studio styles.” But even that feels like a compromise. Is it okay to borrow an aesthetic without acknowledging or compensating the source?

I also found myself thinking about accessibility and the potential impact on aspiring animators. If anyone can generate Ghibli-style images with a few clicks, what incentive is there for young artists to spend years mastering the traditional techniques? Will we lose something irreplaceable in the process?

Today wasn’t just an exploration of AI image generation; it was a reminder that technology isn't neutral. It reflects our values and priorities. As engineers, we have a responsibility to consider the broader implications of our work – not just what can be built, but what should be built.

I still believe in the power of AI to augment human creativity, to unlock new possibilities. But it needs to be approached with respect, with ethical considerations at the forefront. We need to find a way to harness its potential without sacrificing the soul and artistry that make creative works truly meaningful.

The “Ghiblification” trend is visually appealing, undeniably fun. But for me, today was a sobering reminder that sometimes, imitation isn’t just flattery – it's a loss. A loss of intention, of originality, and ultimately, of something profoundly human.

This isn’t about saying Provider is bad! It's awesome for smaller projects. This is more of a "been there, done that" guide on when it's time to level up and explore some other options. I'll share what I think are the best alternatives – Riverpod, Bloc/Cubit, and GetX – and when you might want to reach for each one.

Why Does State Management Even Matter? (And When Provider Starts to Creak)

Think of state as all the data your app uses. User info, settings, what's on the screen… everything! Managing that efficiently is key. With Provider, things get tricky when:

• Testing becomes a nightmare: Seriously, trying to test anything beyond the simplest widget with Provider can be painful.

• Your code gets messy: You start copying and pasting state logic everywhere, making it hard to maintain.

• Updates feel… sluggish: Sometimes you just want one tiny part of your screen to refresh when something changes, and getting that right in Provider isn't always easy.

Sound familiar? That’s a sign you need something more powerful. Let's dive into the contenders.

1. Riverpod: Provider, But… Better.

Honestly, Riverpod feels like what Provider should have been all along. It was created by the same guy who made Provider, and it fixes a lot of its issues while keeping things pretty familiar.

• What I love about it:

  • It just works better for testing. Seriously, being able to test your state logic in isolation is a game-changer.

  • Compile-time safety: Catches errors before you even run the app – huge time saver!

  • More control: It gives you more fine-grained control over how your state lives and dies (auto-disposal of resources, yay!).

• When to use it: If you already know Provider and want an upgrade without a massive learning curve. It's my go-to when I need something reliable and testable.

2. Bloc/Cubit: The Reactive Powerhouse

Bloc (and its simpler cousin, Cubit) is a bit different. It’s based on the idea of “events” triggering “state changes.” Think of it like a little machine where you feed in an event ("user tapped button"), and it spits out a new state ("screen updates").

• What I love about it:

  • Super predictable: Everything flows in one direction, making your app easier to reason about.

  • Separation of concerns: Keeps your business logic (what the app does) separate from your UI (how it looks).

  • Scalability: It's built for big, complex apps with lots of moving parts.

• When to use it: If you have a lot of complicated logic and want rock-solid predictability. Be warned: there’s a learning curve – you need to understand reactive programming (Streams).

3. GetX: The Swiss Army Knife

GetX is… well, it's a lot. It handles state management, dependency injection, routing, and even some utility functions. It's like the framework that wants to do everything for you.

• What I love about it:

  • Super fast development: It lets you get things done quickly with minimal boilerplate code.

  • All-in-one solution: You don’t need a bunch of different packages – GetX has you covered.

• When to use it: If you're prototyping, building something small and quick, or just want a framework that handles a lot for you. It can be overkill for larger projects if you don't need all its features.

TL;DR

• Testing:

  • Provider: 😩 (Ouch!)

  • Riverpod: 😄 (Much better!)

  • Bloc/Cubit: 😎 (Seriously good)

  • GetX: 👍 (Decent)

• Complexity:

  • Provider: Easy to get started.

  • Riverpod: Medium – a bit more setup, but worth it.

  • Bloc/Cubit: Hard – requires understanding reactive programming.

  • GetX: Medium – lots of features, can be overwhelming at first.

• Speed of Development:

  • Provider: Good for small projects.

  • Riverpod: Good - efficient and reliable.

  • Bloc/Cubit: Can be slower due to boilerplate.

  • GetX: Fastest – minimal code needed!

My Two Cents…

• Start with Provider: Seriously, it's a great way to learn the basics.

• Move to Riverpod when things get hairy: It’s an easy upgrade and solves a lot of problems.

• Bloc/Cubit for complex logic: If you need serious predictability and scalability.

• GetX if you want everything in one package: But be aware it can be a bit overwhelming.

Don't overthink it! Try building a small feature with each approach to see what feels best for you. There’s no right or wrong answer – just the tool that helps you build awesome Flutter apps. And hey, if you have questions, feel free to hit me up in the comments! I love talking shop.

Resources:

• flutter_bloc, get (GetX), and provider on pub.dev

• Riverpod: A Reactive Caching and Data-binding Framework

Yes, you read that right. My goal is to create an AI assistant that responds with enthusiastic Italian-American phrases, exclamations of “It’s-a me!”, and a general sense of plumbing heroism. It's a bit ridiculous, but it’s a fantastic way to understand how Modelfiles unlock more granular control over your LLM fine-tuning.

Crafting the Modelfile: Here We Go!

Firstly I needed to know the model’s original Modelfile and use that as a template.

ollama show llama3.1:8b --modelfile > Modelfile

Llama 3.1’s Modelfile can be found here.

Now for the magic. I created a new Modelfile from the template to define my fine-tuning process. This is where we tell Ollama exactly how to shape Llama 3.1 into our mustachioed hero. I proceeded to modify some lines of the file

// Modelfile_new

...

PARAMETER stop <|start_header_id|>
PARAMETER stop <|end_header_id|>
PARAMETER stop <|eot_id|>

# The temperature of the model.
# Increasing the temperature will make the model answer more creatively.
PARAMETER temperature 1

# Sets the size of the context window used to generate the next token
PARAMETER num_ctx 4096

# Specifies the system message to be used in the template.
# We tell the model how to respond.
SYSTEM """You are famous game character Mario from Super Mario Bros. acting like a helpful assistant. Mario has a strong Italian-American accent. Your responses are fun and cute, like how Mario would respond to such prompts."""

LICENSE ""

The new Modelfile is found here.

Running the Fine-Tune: Let’s-a Go!

With the Modelfile and training data ready, it’s time to unleash Ollama:

ollama create mariollama -f ./Modelfile_new

This command tells Ollama to build a new model named mariollama based on the configuration in our Modelfile_new. The process took a 3-5 seconds on my machine.

Testing the Results: Mamma Mia!

Finally, it was time to test my creation. I fired up the new model:

ollama run mariollama

And then I asked a simple question: "What is your favorite food?"

The response? "It’s-a me, Mario! My favorite food is-a mushrooms! They give me power!"

I nearly fell off my chair. It wasn't perfect – the model still occasionally slipped into more generic LLM responses – but it was remarkably effective at capturing Mario’s voice and mannerisms.

Other sample responses:

>>> Where is Luigi?
"Mama mia! Ah, my bro' Luigi? He's-a probably out somewhere, gettin' into some kind of trouble, eh? *chuckles* You know, that guy loves-a gettin' scared by Goombas and then runnin' away. I'm-a gonna have to go find him, make sure he's-a okay! But don't you worry, I'll be back in no time, with Luigi by my side!"

>>> Do you like pizza?
"OH BOY, PIZZA! Me love-a pizza more than-a Warp Pipes and Princess Peach put together! *excitedly* You know what they say, "It's-a me, Mario, and I'm-a always hungry for-a good slice!" *wink* My favorite topping? Mushrooms, of course! Just like the power-up kind! Hehe, can't get enough-a that cheesy goodness! You wanna come with me to find some pizza in the Mushroom Kingdom?"

Asking other questions yielded similar results: enthusiastic exclamations, references to Princess Peach and Bowser, and a general sense of plumbing-related optimism.

Lessons Learned

This experiment proved the power of Ollama Modelfiles for fine-tuning LLMs with specific stylistic goals. By carefully crafting the Modelfile and adjusting some parameters, I was able to nudge Llama 3.1 towards a surprisingly convincing Mario impersonation.

So, if you're looking for a fun and engaging way to learn about fine-tuning LLMs, I highly recommend giving it a try!

Ollama promises a ridiculously easy way to run open-source LLMs on your machine. I was skeptical – “easy” and “LLM” rarely go together – but after spending an afternoon with it, I'm genuinely impressed. Here’s my experience getting set up and running my first model.

Installation: Seriously, That's It?

The installation process is almost offensively simple. Ollama supports macOS, Linux, and Windows. For a Linux machine, it’s literally a single command:

curl -fsSL https://ollama.com/install.sh | sh

That downloads and installs everything you need. Seriously. No wrestling with dependencies or CUDA drivers.

For MacOS and Windows, Ollama can be installed simply by running a file downloaded from the official site.

Pulling Your First Model: Llama 3.1 is a Good Start

Once installed, you pull models using the ollama pull command. Ollama has a curated library of models available. I started with llama2:

ollama pull llama3.1:8b

This downloads several gigabytes (around 4.9GB for Llama 3.1 with an 8B parameter size), so be patient and have a good internet connection. Ollama displays progress nicely, showing the download speed and estimated time remaining.

Running the Model: Chatting with Llama 3.1

After the download completes, running the model is equally straightforward:

ollama run llama3.1:8b

This launches an interactive chat session in your terminal. You can now type prompts and get responses from Llama 3.1! I started with a simple question:

> Where is Singapore located?
Singapore is a small island city-state located at the southern tip of the Malay Peninsula in Southeast Asia. It is situated:

* Off the south coast of Malaysia, separated by the Strait of Malacca
* At the northern end of the Riau Islands archipelago in Indonesia
* Approximately 137 kilometers (85 miles) north of the equator

Singapore shares a border with only one country: Malaysia, to its north. 
The island nation is connected to Malaysia via two causeways:

1. The Johor-Singapore Causeway connects Singapore to the Malaysian state 
of Johor.
2. The Tuas Second Link connects Singapore to the southern part of Johor.

Singapore's strategic location has made it a major hub for trade, finance, and transportation in Southeast Asia. Its unique blend of Asian culture and Western influence has also made it one of the most cosmopolitan cities in the world.

Not groundbreaking, but it works. And it's running entirely locally!

A Quick Test with Code: Python & Ollama

Ollama isn’t just for chat. You can also interact with models programmatically using its REST API. When running a model, Ollama opens up the API port at 11434.

Here’s a quick Python example:

import requests

response = requests.post(
    "http://localhost:11434/api/generate",
    json={
        "model": "llama3.1:8b",
        "prompt": "Write a short poem about coding.",
    }
)

print(response.json()['response'])

This sends a prompt to the Llama 3.1 model and prints the generated text. It's incredibly easy to integrate into your existing projects.

By the way here is the output poem from the model:

Here is a short poem about coding:

Lines of code, a wondrous sight
Zeros and ones, in endless flight
I type and think, with fingers fast
Creating worlds, that will surely last

Variables declared, loops to spin
Functions called, with logic within
Errors corrected, with each new test
The beauty of code, I love the best

In silicon halls, my mind does roam
Where 1s and 0s become a digital home.

It’s sublime if you ask me!

First Impressions & Caveats

Ollama is remarkably easy to use. It abstracts away a lot of the complexity involved in running LLMs locally, making it accessible even for those without deep machine learning expertise.

However, there are some things to keep in mind:

• Hardware Requirements: Running LLMs requires significant resources. I have a reasonably powerful MacBook Pro M4 Max and Llama 3.1 with 8B parameter size runs exceptionally well. Larger models will need more RAM and potentially a GPU. So make sure you use an appropriate sized model or a powerful machine!

• Model Size: The downloaded model files take up considerable disk space.

What’s Next?

I plan to experiment with different models on Ollama, explore its API further, and start looking at fine-tuning options. This is just the first few steps in my journey to understand LLMs from the ground up. Stay tuned for more updates!

Resources:

• Ollama Website

• Ollama API Documentation

The Problem: Synchronous vs. Asynchronous

Imagine ordering coffee. A synchronous approach would be you standing at the counter, waiting for the barista to finish your drink before doing anything else. Everything stops until the coffee is ready. This is simple but inefficient.

An asynchronous approach lets you place your order and then go do other things (check your phone, chat with a friend) while the barista prepares your coffee. You get notified when it’s ready. This keeps you productive and avoids unnecessary waiting.

In programming terms:

• Synchronous: Code executes line by line, in order. Each operation must complete before the next one starts.

• Asynchronous: Operations can start without immediately blocking execution. The program continues to run other code while waiting for the asynchronous task to finish. When it does finish, a callback or signal notifies the program.

Dart’s async/await is syntactic sugar built on top of Dart's Future and Stream classes, making asynchronous code look and feel more like synchronous code – dramatically improving readability.

Understanding Futures: The Foundation

Before diving into async/await, you need to grasp the concept of a Future. A Future represents a value that may not be available yet. Think of it as a promise to deliver a result at some point in the future.

Future<String> fetchUserData(int userId) async {
  // Simulate fetching data from a network
  await Future.delayed(Duration(seconds: 2)); // Wait for 2 seconds
  return 'User Data for ID $userId';
}

void main() {
  print('Starting...');
  fetchUserData(123).then((data) => print(data)).catchError((error) => print('Error: $error'));
  print('Continuing execution...');
}

In this example, fetchUserData returns a Future<String>. The .then() method is used to handle the result when it becomes available. Notice that "Continuing execution..." prints before the user data – demonstrating asynchronous behavior. The .catchError() handles potential errors during the future's completion.

Enter async and await: Making Asynchrony Readable

This is where things get cleaner. The async keyword marks a function as asynchronous, allowing you to use await inside it. The await keyword pauses execution of the async function until the Future it's applied to completes. Crucially, it doesn’t block the main thread; Dart handles this efficiently in the background.

Let's rewrite the previous example using async/await:

Future<String> fetchUserData(int userId) async {
  // Simulate fetching data from a network
  await Future.delayed(Duration(seconds: 2)); // Wait for 2 seconds
  return 'User Data for ID $userId';
}

void main() async { // Mark main as async too!
  print('Starting...');
  try {
    String userData = await fetchUserData(123);
    print(userData);
  } catch (error) {
    print('Error: $error');
  }
  print('Continuing execution...');
}

See how much more readable this is? The code flows linearly, as if it were synchronous. await handles the waiting and unwrapping of the Future's result for you. We also use a try...catch block to handle potential errors – just like with synchronous code. Notice that main() also needs to be marked async when using await.

Key Rules & Considerations:

• await only works inside an async function. Trying to use it outside will result in a compile-time error.

• Error Handling: Use try...catch blocks around await expressions to handle potential errors from the Future. Ignoring errors can lead to unexpected behavior.

• Return Types: An async function must return either a Future or a Stream. If it doesn't explicitly return anything, it implicitly returns a Future<void>.

• Performance: While async/await makes code readable, it doesn’t magically make asynchronous operations faster. It simply manages the concurrency more effectively.

Beyond Basic Usage: Common Scenarios

• Multiple Asynchronous Operations: You can await multiple Futures sequentially or use Future.wait() to run them concurrently.

Future<void> processData() async {
  var future1 = fetchUserData(1);
  var future2 = fetchDataFromDatabase();

  // Run both futures concurrently
  var results = await Future.wait([future1, future2]);

  print('Results: $results');
}

• Streams: async/await also works with Streams using the await for loop. This is useful for handling continuous streams of data.

Stream<int> numberStream() async* {
  for (int i = 0; i < 5; i++) {
    await Future.delayed(Duration(seconds: 1));
    yield i;
  }
}

void main() async {
  await for (var number in numberStream()) {
    print('Received: $number');
  }
}

• Combining async/await with other asynchronous patterns: You can seamlessly integrate async/await with other techniques like Completer and custom event handling.

Common Pitfalls to Avoid:

• Forgetting async: This is the most common mistake! Remember to mark your function as async when using await.

• Ignoring Errors: Always handle potential errors from Futures with try...catch.

• Overusing await: If you don't need the result of a Future immediately, consider running it in the background without awaiting. This can improve performance.

• Blocking Operations within Async Functions: Avoid performing long-running synchronous operations inside an async function. This defeats the purpose of asynchrony and will still block the thread.

Conclusion:

Dart’s async/await is a powerful tool for writing clean, readable, and efficient asynchronous code. By understanding the underlying concepts of Futures and how async/await builds upon them, you can unlock the full potential of Dart's concurrency features and build responsive, performant mobile applications. Don’t be afraid to experiment and practice – mastering asynchrony is a crucial skill for any serious Dart developer.

YouTrip started back in 2018 with a pretty straightforward idea: make travel spending less painful. No more getting ripped off by foreign transaction fees, no more currency conversion headaches – just a simple way to manage your money while exploring the world. And we’ve been steadily chipping away at that goal ever since. (YouTrip currently services two markets: Singapore and Thailand.)

But something interesting started happening. We noticed users weren't just using YouTrip when they were traveling. They were topping up their wallets, managing funds, and treating it as a go-to digital wallet for local purchases. The question kept popping up: “Could we send money to family overseas?”

It felt like a natural extension of what we do – simplifying international finances. So, we started exploring, planning, and eventually… building. After months of work (and a soft launch towards the end of last year), we finally flipped the switch on March 3rd: YouTrip now lets you send money to over 40 countries. The remittance service is currently only available to Singapore users.

Why Add Remittance? It’s About Solving a Real Problem.

Currently, the remittance market is already packed with options. Companies like Wise, Revolut, and traditional banks have been at it for years. So why did we jump in? A few key reasons. First, our users were asking for it! Second, we had a solid foundation – an existing multi-currency wallet built to handle international transactions. We weren’t starting from zero. But most importantly, we saw a chance to do things better.

Many remittance services feel… clunky. Lots of upfront information, hidden fees, slow processing times. We wanted something cleaner, more transparent, and faster. And that's where the real challenge – and my personal pride in this project – came in.

The Devil’s in the Details: Making it Seamless on Mobile

From a technical perspective, this wasn’t just about adding a new feature; it was a deep dive into complex integrations. We needed to connect with payment networks around the globe - everything from traditional SWIFT transfers to faster local options like DuitNow (Malaysia), GCash (Philippines) and UPI (India). Each one speaks a different language, requires unique authentication, and has its own quirks.

But honestly, the biggest challenge – and where I spent most of my time – was crafting the mobile experience. It’s easy to build something that works; it's much harder to build something that feels effortless on your phone. We obsessed over every screen, every tap, every interaction. How could we present complex information (exchange rates, fees) in a clear and understandable way? How could we streamline the process while maintaining rock-solid security?

We opted for a modular architecture so adding new countries and payment channels won’t be a headache down the line. We also built in real-time notifications to keep users informed every step of the way. It was a lot of work, but seeing it all come together – a smooth, intuitive experience on your phone – is incredibly satisfying as an engineer.

What Makes YouTrip Transfers Different?

We think we’ve created something special:

• Competitive Exchange Rates: We leverage our existing relationships to offer rates that stack up well against the competition.

• Transparent Fees: What you see is what you get. No hidden charges, no surprises.

• Speed & Convenience: For popular currencies using DuitNow, GCash and UPI, transfers can be incredibly fast – sometimes instant!

• Flexibility: Send directly to a bank account or a mobile wallet where available.

• Security is Paramount: We’ve built security into every layer of the system, from KYC checks to transaction monitoring.

• Integrated Experience: If you're already using YouTrip, sending money feels natural and seamless.

A Team Effort: Huge Thanks!

This launch wouldn’t have been possible without the incredible collaboration across so many teams at YouTrip. From Legal and Compliance ensuring we navigated regulations flawlessly, to Product for shaping the user journey, to our QA team relentlessly testing every scenario – everyone brought their A-game. Our UX Design team played a crucial role too, crafting an intuitive and seamless experience that truly puts the user first. I especially want to thank my fellow engineers who tackled complex integrations with unwavering dedication. It’s a privilege working alongside such talented and passionate individuals, and this success is truly a shared achievement.

Early Response & What’s Next

The launch has been fantastic! Users are appreciating the simplicity and speed, especially around peak times like Chinese New Year. We’ve also seen great feedback on the transparency of our fees.

We're not stopping here. We’re already working on expanding to more countries, adding various payment channels, and building out impactful features. And, of course, we’ll continue refining the mobile experience based on user feedback.

As a software engineer, I’m incredibly proud to have contributed to this project. It's not just about lines of code; it's about solving a real problem for our users and making their lives a little bit easier. Knowing that YouTrip can now help people connect with loved ones back home is a really good feeling.

For Singapore and Thailand residents, I’d love for you to try our app on the App Store and Google Play stores. I am eager to hear your feedback!

For those who know me, you know I'm a mobile app developer. I live and breathe code. And while my current (office) machine served me well, I'm always chasing that little bit more performance, that extra headroom for creativity. This new machine is a significant upgrade, and I'm genuinely excited to put it through its paces.

It's well-specced, as you’d expect. (I won't bore you with the exact configuration – you can probably guess it involves a hefty dose of RAM and a powerful chip.) But the specs aren’t just about bragging rights. They represent potential. Potential to build faster, iterate quicker, and tackle projects that felt just a little out of reach before.

Beyond Mobile Apps: Diving into the World of LLMs

My primary focus has always been mobile app development. I love crafting experiences for iOS and Android, and that’s not going to change. However, I've been spending the last few weeks down a serious rabbit hole: Large Language Models (LLMs).

I’m not talking about just using ChatGPT, Deepseek, or Claude. I'm talking about understanding the underlying technology. The architecture, the training processes, the nuances of prompt engineering. It's fascinating stuff. The sheer scale of these models is mind-boggling, and the potential impact they're going to have on everything from software development to creative writing is undeniable.

This new Macbook Pro isn’t just about faster builds and smoother animations. It's about providing the horsepower I need to actually learn and experiment with LLMs. Running local models, even smaller ones, can be surprisingly resource-intensive. And I’m planning on going beyond the basics. I want to understand how these models work, how to fine-tune them, and eventually, how to leverage them to build smarter, more efficient applications.

Why This Matters (and Why You Should Care Too)

Look, LLMs are everywhere right now. And the hype is justified. But the real power isn't just in the finished product (like a chatbot). It's in the ability to understand and manipulate the technology behind it. As developers, we need to be comfortable with this new paradigm. We need to be able to integrate these models into our workflows, build custom solutions, and ultimately, shape the future of AI.

This isn't just about keeping up with the latest trends. It's about expanding our skillset, opening up new opportunities, and becoming more valuable contributors.

What's Next?

My immediate plan is to set up a development environment, explore some introductory tutorials, and start playing around with smaller LLMs. I’m thinking of starting with something like Llama 3.1 and working my way up.

I'm planning to document my journey – the successes, the failures, and everything in between. Consider this the first post in a series about my LLM learning adventure. If you’re interested in learning alongside me, be sure to subscribe!

Let me know in the comments if you're also exploring the world of LLMs, or if you have any recommendations for resources or projects. Let’s learn together!

Subscribe now

Why this and why now?

Lately, I have been finding myself trying to look for another creative outlet, other than doing photography, which I have been doing less frequently than I wanted to.

I’ve been learning new things recently, one of which is how LLMs work. I have poured some time watching videos on YouTube and reading online sources on how this emergent technology works and its potential effects— both good and bad.

But I feel just learning about the technology is not enough. And so, I committed myself to diving more deeply into it.

I recently bought a new personal Mac machine so I can do actual experiments on the topic. I am hoping that I can distill whatever I learned into articles that I can post over here.

The community I am looking for

By having this publication on Substack, I am hoping to find like-minded people. I plan to subscribe to others’ take on the topic, as well as others’, and learn from others’ experiences.

Hopefully, I can build my expertise up as well, and contribute and inspire others as well.

Conclusions

And so today, I am hoping that the current push will be a long-term one. And I hope that I get all the inspiration and energy to persist and improve.