Mihamina Rakotomandimby

Taming AI Code Bloat: Adding Line Counts to Nvim-Tree Tools like GitHub Copilot and modern LLMs have dramatically accelerated development velocity. With tab completions, automated boilerplate generation, and rapid prototyping, writing code has never been faster. However, this velocity introduces a subtle software architecture anti-pattern: silent file bloat. Before AI assistance, writing 2,000 lines of code in a single file took deliberate effort and plenty of typing fatigue, giving developers time to pause and say, "This file is getting out of hand; I need to split this into smaller modules." Today, an AI can generate hundreds of lines in seconds. Without visual feedback in our project navigation, a once-compact module can swell to 1,500 or 2,000 lines before anyone notices during a pull request review. To tackle this architectural drift directly at the source, I added a custom decorator to nvim-tree.lua that displays the line count directl...

Switching from Gemini API to Vertex AI Integration I have a Node.js application that formerly used the pure Gemini API. I switched to using the Vertex AI integration. In order to achieve this, you need to set up your environment to use Application Default Credentials (ADC) and specify your Google Cloud project ID. #!/bin/bash export GOOGLE_CLOUD_PROJECT=<my-project-id> bash <(curl -s SL \ https://storage.googleapis.com/cloud-samples-data/adc/setup_adc.sh) Then it stores the service credentials in a file: ${HOME} /.config/g cloud /application_default_credentials.json Which contains: { "account" : "" , "client_id" : "....apps.googleusercontent.com" , "client_secret" : "..." , "quota_project_id" : "gen-lang-client-0123456" , "refresh_token" : "1//OlP1frQqGdZVykkPbFRWzVUBo1s" , "type" : "authorized_user" , "universe_domain" : ...

Running OpenCode with a Remote Ollama Server I recently changed my local AI development setup so that OpenCode no longer runs models on the same machine where I edit code. Instead, OpenCode connects to a remote Ollama server over my local network. This approach lets me keep my development environment lightweight while dedicating another machine to model inference. Why use a remote Ollama server? Running Ollama remotely offers several advantages: The development machine remains responsive while the model generates responses. GPU resources can be centralized on a dedicated machine. Multiple computers can share the same inference server. Updating or changing models only needs to be done on one system. The OpenCode configuration remains simple. As long as the network latency is reasonable, the experience is very close to using a local Ollama instance. My OpenCode configuration OpenCode supports providers compatible with the OpenAI API. Since O...

Supercharging Your Local Ollama Server: Network Access, Permanent Memory, and Extended Context If you run LLMs locally on Linux using Ollama, you know how smooth and lightweight the installation experience is. However, out of the box, Ollama’s default configuration is tailored for a single-user desktop environment—binding strictly to localhost, unloading models from memory after 5 minutes of inactivity, and capping the context length to a standard limit. If you are setting up a dedicated AI server on your local network, running a WebUI on another machine, or building RAG (Retrieval-Augmented Generation) applications, these defaults can get in your way. In this post, we’ll explore how to tweak Ollama's systemd service file on Linux to: 1. Expose the API across your local network. 2. Keep models continuously loaded in memory (zero startup lag). 3. Extend the context window size up to 32,768 tokens. The Customized systemd Service File When installing Ollama on Linux, it r...

Resetting Doctrine Migrations and Generating a Fresh Baseline Sometimes, after months of development, experiments, rebases, or multiple contributors, Doctrine migrations can become difficult to follow. You may end up with: Too many migration files Broken migration history Conflicts between branches Databases that are already in sync but migrations are not Old migrations that no longer represent reality In those situations, one practical solution is to completely reset the migration history and generate a brand new migration representing the current state of your entities. When Should You Do This? This approach is useful when: You are still in active development The project has not yet reached production You want to simplify migration history Your migration chain has become unreliable You want a clean baseline for future migrations Do not do this lightly on production systems with historical environments that depend ...

Remove SQL comments in SQL scripts I often want to provide SQL structure dumps as context for AI assisted development. But most of the dumps tools provide SQL scripts with comments. I do not want to provide them to the AI. So, I need to strip the comments. This is the file I use:   #!/bin/bash # 1. Check if an input file was provided if [ "$#" -lt 1 ]; then echo "Usage: $0 [output_file.sql]" exit 1 fi INPUT_FILE="$1" OUTPUT_FILE="${2:-cleaned_$1}" # 2. Check if input file exists if [ ! -f "$INPUT_FILE" ]; then echo "Error: File '$INPUT_FILE' not found!" exit 1 fi # 3. Create secure temporary files for the intermediate passes PASS1_FILE=$(mktemp) PASS2_FILE=$(mktemp) # Set a trap to automatically delete the temporary files when the script finishes or is aborted trap 'rm -f "$PASS1_FILE" "$PASS2_FILE"' EXIT echo "Starting multi-pass SQL cleanup on '$INPUT_FI...