Mihamina Rakotomandimby

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...

  Rebuilding NVIDIA Drivers on Fedora After Updates If you’re running Fedora with NVIDIA proprietary drivers, you’ve probably run into this situation: screen does not work properly. The fix is simple, but easy to forget. This post is here so future-you (and others) don’t waste time rediscovering it. The Command You’re Looking For sudo akmods --rebuild --force That’s it. This command forces a rebuild of kernel modules managed by akmods , including NVIDIA drivers. When Should You Run It? Typically, you’ll need this after: A kernel upgrade An update of one of these packages: akmod-nvidia xorg-x11-drv-nvidia-cuda Why? Because NVIDIA drivers are built as kernel modules, and they must match your currently running kernel. When Fedora updates the kernel, the modules may not yet be compiled for it — or something may have gone wrong during automatic build. What’s Happening Under the Hood Fedora uses akmods (Automatic Kernel Module Build Service) to compile kernel mod...