<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Projects on Cesar Gimenes</title><link>https://crg.eti.br/projects/</link><description>Recent content in Projects on Cesar Gimenes</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>crg@crg.eti.br (Cesar Gimenes)</managingEditor><webMaster>crg@crg.eti.br (Cesar Gimenes)</webMaster><lastBuildDate>Sat, 11 Apr 2026 12:00:00 -0300</lastBuildDate><atom:link href="https://crg.eti.br/projects/index.xml" rel="self" type="application/rss+xml"/><item><title>LQS</title><link>https://crg.eti.br/projects/lqs/</link><pubDate>Sat, 11 Apr 2026 12:00:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/lqs/</guid><description>&lt;p>&lt;code>lqs&lt;/code> is a small Go CLI for testing and debugging SQL commands with embedded metadata and, optionally, Lua scripts.&lt;/p>
&lt;p>The idea came from a concrete annoyance: every time I wanted to validate a query in PostgreSQL or SQLite, I&amp;rsquo;d open &lt;code>psql&lt;/code> or &lt;code>sqlite3&lt;/code>, copy, paste, test, tweak, copy again. With parameterized queries it got worse, because each client handles &lt;code>$1&lt;/code>, &lt;code>?&lt;/code>, and &lt;code>:name&lt;/code> differently.&lt;/p>
&lt;p>The fix was to treat the &lt;code>.sql&lt;/code> file as a small executable script. At the top of the file you put metadata in comments:&lt;/p></description></item><item><title>GoScope</title><link>https://crg.eti.br/projects/goscope/</link><pubDate>Sat, 11 Apr 2026 12:00:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/goscope/</guid><description>&lt;p>GoScope (&lt;code>goscope&lt;/code>) is a CLI that scans a Go project starting from the current directory and lists every declared function, variable, constant, type, and function call, with file and line number. No configuration, no flags. You run it, it spits out the list.&lt;/p>
&lt;p>&lt;code>rgs&lt;/code> is the companion script. It takes the &lt;code>goscope&lt;/code> output, pipes it into &lt;a href="https://github.com/junegunn/fzf">fzf&lt;/a>, and opens the file in your editor (&lt;code>$EDITOR&lt;/code>) at the exact line of the chosen item. If you have &lt;a href="https://github.com/sharkdp/bat">bat&lt;/a> installed, the fzf preview is colorized.&lt;/p></description></item><item><title>nvim-bookmarks</title><link>https://crg.eti.br/projects/nvim-bookmarks/</link><pubDate>Sat, 11 Apr 2026 12:00:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/nvim-bookmarks/</guid><description>&lt;p>nvim-bookmarks is a small bookmark system for Neovim, in Lua. Not a formal plugin &amp;ndash; it&amp;rsquo;s a single &lt;code>bookmark.lua&lt;/code> file that you load from your &lt;code>init.lua&lt;/code>.&lt;/p>
&lt;p>I built it because, day to day, I keep going back to the same files and lines to debug and test something. Opening those files directly at the right line, without navigating, makes a real difference when you&amp;rsquo;re chasing a bug.&lt;/p>
&lt;p>The marks file format is deliberately simple: full file path, space, &lt;code>+&lt;/code>, line number. One mark per line. I use the same format in other scripts outside Neovim, so everything talks to itself.&lt;/p></description></item><item><title>nvim-sort</title><link>https://crg.eti.br/projects/nvim-sort/</link><pubDate>Sat, 11 Apr 2026 12:00:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/nvim-sort/</guid><description>&lt;p>nvim-sort is a pair of Lua functions for sorting and removing duplicate lines in Neovim selections.&lt;/p>
&lt;p>I built it because what I wanted to do dozens of times a day was exactly that: mark a block of lines, sort, drop duplicates, close. Neovim already has &lt;code>:sort&lt;/code> and &lt;code>:sort u&lt;/code>, but I wanted something mapped to a single key, with no &lt;code>:&lt;/code>, no confirmation, no thinking.&lt;/p>
&lt;p>Not a formal plugin and not aiming to become one. It&amp;rsquo;s a Lua file, you load it from your &lt;code>init.lua&lt;/code>, and move on.&lt;/p></description></item><item><title>DOOMFire</title><link>https://crg.eti.br/projects/doomfire/</link><pubDate>Sat, 11 Apr 2026 10:00:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/doomfire/</guid><description>&lt;p>I reimplemented the DOOM fire effect in Go, in a transparent window, using &lt;a href="https://ebitengine.org">Ebitengine&lt;/a>.&lt;/p>
&lt;p>The original formula is from 1993 and fits in a handful of lines: every pixel of the bottom row is a seed, the fire rises by propagating intensity to the row above, with a random horizontal offset and a color palette. It still hypnotizes.&lt;/p>
&lt;p>The difference from most reimplementations is the transparent window: the fire rises over the desktop, the terminal, the open code &amp;ndash; whatever happens to be in the way.&lt;/p></description></item><item><title>Kutta</title><link>https://crg.eti.br/projects/kutta/</link><pubDate>Wed, 08 Jul 2026 00:30:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/kutta/</guid><description>&lt;p>Kutta is a small 2D wind tunnel. It streams a flow past an airfoil and makes it visible: the speed field, vorticity, a pressure-like field, smoke streaklines, and the lift and drag vectors, all reacting live as you change the angle of attack.&lt;/p>
&lt;p>It is written in Go and rendered with &lt;a href="https://ebitengine.org">Ebitengine&lt;/a>, and ships as a single desktop application.&lt;/p>
&lt;p>The point is intuition, not engineering. Kutta runs in lattice units, not physical ones: it gets the shape of the flow right (stagnation at the nose, the wake, suction over the top, separation as the angle climbs) and the numbers wrong on purpose. It is for teaching, aeromodeling curiosity, and demos that look good on a projector, not for sizing a real wing. Skin friction is ignored, so drag reads low; a known limitation, not a hidden bug.&lt;/p></description></item><item><title>Glaze</title><link>https://crg.eti.br/projects/glaze/</link><pubDate>Sat, 11 Apr 2026 10:10:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/glaze/</guid><description>&lt;p>Glaze is a Go binding for desktop WebViews. It&amp;rsquo;s a pure-Go port of &lt;a href="https://github.com/webview/webview">webview/webview&lt;/a> on top of &lt;a href="https://github.com/ebitengine/purego">purego&lt;/a>, with no cgo and no native library bundled in.&lt;/p>
&lt;p>The project started as a fork of &lt;code>go-webview&lt;/code> but has diverged enough to live as a separate codebase with its own goals.&lt;/p>
&lt;p>The reason for avoiding cgo: dragging a C toolchain into a Go project just to open a window with HTML breaks too much of what I like about the Go ecosystem &amp;ndash; easy cross-compilation, reproducible builds, &lt;code>go install&lt;/code> that works for whoever clones the repo. The old version embedded the compiled C++ webview library and extracted it to disk at runtime. Now each backend calls, through purego, the WebView the operating system already ships: WKWebView on macOS, WebKitGTK on Linux, WebView2 (COM) on Windows. No native library in the binary.&lt;/p></description></item><item><title>Go Study Group</title><link>https://crg.eti.br/projects/grupo-estudos-golang/</link><pubDate>Sat, 11 Apr 2026 10:30:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/grupo-estudos-golang/</guid><description>&lt;p>I&amp;rsquo;ve been running the Go Study Group since 2016. Live sessions on Saturdays at 2 PM (BRT), free and open.&lt;/p>
&lt;p>The focus is studying Go seriously, in Brazilian Portuguese, from the basics to advanced topics, with the material organized so you can join from wherever you are. Beginners and experienced people share the same group. That works because each topic has a clear baseline and all the material lives in the repository, ready to be read outside of meeting hours.&lt;/p></description></item><item><title>shutdown</title><link>https://crg.eti.br/projects/shutdown/</link><pubDate>Sat, 11 Apr 2026 10:40:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/shutdown/</guid><description>&lt;p>A tiny 16-bit C utility that shuts down or reboots MS-DOS via APM 1.2.&lt;/p>
&lt;p>I made it to use with DOS running in VirtualBox. The VM kept burning CPU because there was no clean way to tell the virtual machine to power off from inside the guest. No ceremony: the program is minuscule, talks to APM directly, and exits.&lt;/p>
&lt;p>APM 1.2 (Advanced Power Management) is the power management interface found in older systems &amp;ndash; a predecessor to ACPI, exposed through BIOS interrupts. It works on any machine, real or virtual, with APM 1.2 capability.&lt;/p></description></item><item><title>Compterm</title><link>https://crg.eti.br/projects/compterm/</link><pubDate>Sat, 11 Apr 2026 10:50:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/compterm/</guid><description>&lt;p>I built Compterm to solve a concrete problem from the Go Study Group: showing the terminal live during a class without relying on screen sharing. Screen sharing eats bandwidth, requires specific software on the viewer&amp;rsquo;s side, and almost always feels heavy for people on bad connections.&lt;/p>
&lt;p>The fix is simpler than it sounds. Compterm only streams the terminal over the network, and the client is the browser, over WebSocket. Viewers install nothing. The presenter runs a binary.&lt;/p></description></item><item><title>Filo</title><link>https://crg.eti.br/projects/filo/</link><pubDate>Sat, 11 Apr 2026 11:00:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/filo/</guid><description>&lt;p>I built Filo for a problem that comes up every time I try to give end users scripting power without destroying the server.&lt;/p>
&lt;p>The obvious paths are bad: the embedded language is either too weak to be useful, or too powerful to be safe. I wanted the third option &amp;ndash; small enough that an ordinary user can write short rules (validations, expressions, field logic), and closed enough that nothing can go down because of it.&lt;/p></description></item><item><title>Neko</title><link>https://crg.eti.br/projects/neko/</link><pubDate>Sat, 11 Apr 2026 09:00:00 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/projects/neko/</guid><description>&lt;p>&lt;a href="https://en.wikipedia.org/wiki/Neko_%28software%29">Neko&lt;/a> is the cat that chases your cursor across the desktop. The original is from 1989, by Masayuki Koba, and got ported to so many platforms that it&amp;rsquo;s part of the cultural memory of anyone who used a Mac or X11.&lt;/p>
&lt;p>I reimplemented it in Go with &lt;a href="https://ebitengine.org">Ebitengine&lt;/a>. I used nothing from the original code &amp;ndash; only the sprites and sounds, which I reused directly. The rest is a rewrite from scratch, with no commitment to matching the exact behavior of the old version.&lt;/p></description></item></channel></rss>