programming

    Vibing a wardriving visualizer

    A while ago someone was showing off their LEGO creation in my social media feed: a brick-built QR-code containing the credentials to their WiFi network. People rushed to tell them that they shouldn’t share this info publicly, but they appeared unconcerned, for who would actually even know where their network was physically located, right? Can’t do any harm to it if you can’t find it. But could you? Surely there are databases of networks available online?

    It turns out there are indeed services like WiGLE that catalogue WiFi access points, Bluetooth devices, and cellphone towers around the world. It relies on people using their Android app and submitting the found networks to the site’s database. Out of curiosity I installed the app and did a bike ride of some 25 km around the city, and much to my surprise logged a whopping 5000 WiFi networks and some 10000 Bluetooth devices! It was a revealing moment when I stopped on a bridge over a highway and looked at the app, and it showed Bluetooth devices with names like Audi, BMW, and Toyota. Almost all new cars can be seen as Bluetooth devices!

    Now, I had collected some sample of networks, but how would I view it? The WiGLE app itself does not provide a map view, so I did what anyone would do these days and vibe-coded my own app. I started by typing a stream of thoughts to ChatGPT: I want it to be a web page, not an app you need to install, and I want it to work fully in the user’s browser, not uploading the data to any servers. The app should provide a map with my route and the network observations, along with some playback controls, etc. Chad then turned all this into a proper requirements document that I handed out to the ChatGPT Codex coding agent after creating an empty GitHub repository for the project. Codex crunched the assignment for five minutes and burped out a pull request. I then set GitHub up to automatically publish the project in GitHub Pages and merged the PR, and lo and behold, it actually worked immediately! After exporting my observations out of the WiGLE app I could follow my route and see all the observations on the map.

    Read More →

    Random Things Sunday #15: Vibe coding

    This week’s main topic is vibe coding, but there’s an aasinsilta,, “donkey’s bridge” as we say in Finnish, to it first:

    • Vincent Ritter put together neat API documentation for Micro.blog at microblog.dev. I’ve been working on my own client so this came in at a very good time. I’ll report on my new client some time in the future.
    • The new client I’ve been working on has been vibe-coded, which brings me to this new site for the Outcome Engineering Manifesto. It lays down some very sensible ground rules for deliberate coding with agents, emphasizing techniques such as measuring, prioritizing, and risk management.
    • Matt Web calls for better discoverability of vibe-coded apps which may be hyper-specific to the creators' needs. I think that’s a great point, for I certainly wouldn’t have started creating my own blog client without agents, but now I can customize my writing experience just the way I want. It would indeed also be just nice to get a picture of what people are building, by following a single source.
    • Finally, the comic relief: OpenAI reports how their models became overly fascinated with goblins. 👺

    Random Things Sunday #13

    Technically it isn’t Sunday yet where I am, but it’s already Sunday somewhere on Earth, and who’s going to stop me anyway? It’s been a while since the previous Random Things Sunday, so let’s get to it. I have a couple of recent articles, one timeless web site, and an interesting YouTube video about movies.

    Read More →

    Bluesky bot to report speeding buses

    The people in my neighborhood Facebook group are often worried about cars speeding on the main road that goes through the area. While I can’t do much about that, I realized that I can at least monitor how fast the buses are going and make that visible, thanks to a realtime high-frequency positioning API provided by HSL that runs the public transport system here. This was around June 2020. I implemented a simple Java application to monitor those buses on the street, but the MQTT library I used proved unreliable, so I put the project to slow backburner. My idea was to eventually make it into a Twitter bot, but I never got that far back then.

    Fast forward a couple of years to September 2022, two months before ChatGPT was launched. TypeScript was all the rage back then but I had not had the opportunity to use it at work yet, so it clicked to me that I could retry my old bus speed tracker with TypeScript.

    Read More →

    Using AI at work

    Someone young not in the software business recently asked me if I use AI in my work. My knee-jerk reaction was “no”: I don’t trust the AI agents running amok in my codebase. I’ve tried it, and it often feels like herding cats, unless your prompt is perfect and you managed to take everything into account, which isn’t possible. But then I started backing off, as there are of course nuances to this: it’s not all-in or nothing.

    Read More →

    Random Things Sunday #10

    Some random findings from the internets, this time catering to programmer-minded people:

    • My former colleague Robert turned out to be quite a penman. He wrote a cool short sci-fi story called Null and void and published it in his blog. Check it out!
    • Darwin Awards collects events where people have removed themselves from the gene pool by doing something stupid. The history of the site goes back to the 1990s, so you may have heard about it already, but this year they’ve got a new category for AI Darwin Awards. This new category honours the visionaries who looked at AI and thought “You know what this needs? Less safety testing and more venture capital!".
    • Finally, you thought you knew what an email address looks like? The E-mail.wtf quiz is here to prove you wrong! I scored 14/21…

    A light exercise in vibe coding

    A few months ago I tried vibe coding an ant colony simulator, but in the end it didn’t work out. I did mention that I had had successes in vibe coding, and lately I had one of those again.

    For my previous post I needed to embed several YouTube videos. That, however, is very cumbersome when you’re blogging with your phone, as the mobile version of YouTube does not have the option to easily just copy the embed code, unlike the desktop version, so it was about to turn into an exercise in frustration.

    But lo and behold, ChatGPT to the rescue. I gave it this prompt:

    Read More →

    Elevator Saga game

    What should happen if you’re on the tenth floor of a building and push the button to call an elevator? Obviously, the elevator should come to you. But what if it’s going up at the 11th floor at the moment, as someone told it to take them to the 15th floor? Well, do that first, then get to the tenth floor. But what if, meanwhile, someone calls it to the 14th floor, wanting to go down? Maybe pass that floor when going up, but stop there on the way down to the tenth floor. But what if you, on the tenth floor, want to get to the 16th floor? Maybe pass the person waiting the 14th floor after all. And what if there are multiple elevators in the lobby, which one should be dispatched and where?

    Read More →

    Robot Battle, an old Windows game

    In the 1990s and early 2000s I played this great game called Robot Battle by Brad Schick. It’s an open-ended programming game where you use a programming language called Robot Scripting Language (RSL) to program battle bots to shoot at each other. The bots look like tanks, consisting of a tracked body, turret, and radar. The arena is viewed from top-down and, in addition to the robots, would also contain mines that you would want your robots to avoid, and cookies that give you more energy. The game relied heavily on its community, initially connected via the Robot Battle Mailing List (RBML), later via the Robot Battle Registry web forum.

    Read More →

    Random Things Sunday #8

    A bit of Star Wars and some programming this week:

    • SC 38 Reimagined is a fan-made remake of the Obi-Wan vs Darth Vader fight in Star Wars Episode IV: A New Hope. The film is short but it has high production values. It makes the original Alec Guinness vs David Prowse battle look rather geriatric, following Vader’s aggressive fighting style seen in the prequel films and TV shows. This fan-film even has a Wikipedia article.
    • Google may have profiled me after my previous Random Things Sunday post, as that list contained a reference to a piece of game-making software, and then YouTube’s algorithm recommended me the Make tiny games video by Juniper Dev. The video is about retro game engines, such as PICO-8, that force you to be creative by limiting the resources you have at your disposal, but that can also be fully mastered due to their limited size. If one wants to make games, start small, and nothing is smaller than these engines!
    • Finally, Joshua Barretto did a great write-up Writing Toy Software Is A Joy, which I think is a good follow-up to the previous point about tiny games. The point of the post is that if you’re a programmer, you should have hobby projects too. You cannot know how, but they’ll pay you back when you’ll acquire knowledge you didn’t know you’d need. And it’s also just more fun to program 20% the work for 80% the results, rather than trying to account for every exceptional case like you’d do if you were writing production quality software, where the first 90% of functionality takes 90% of effort and the final 10% of polish takes the other 90% of work.

    Saalo's Law of Software Development

    When you’ve been long enough in the software development business you start to notice patterns. One of those patterns recently surfaced again when someone in my team floated the idea that our system should be able to read or write Excel files. I’ve seen and implemented this particular request so many times that I got inspired to write it down as an adage. I’ve dubbed it Saalo’s Law of Software Development and it goes as follows:

    Every piece of enterprise software eventually evolves into either reading or writing Excel files.

    I originally posted this just to the company Slack where my peers unanimously agreed that yes, this is exactly what happens. There’s something about spreadsheets that makes them the universal translator of the business world – no matter how sophisticated your system, someone always needs that Excel import or export function.

    So there you have my humble observation on how enterprise software works. My law may not be as well known (yet!) as Hofstadter’s, Brooks', or Parkinson’s laws, but maybe one day. 😁