I recently got back to working on my collection of online tools :D
\nI needed some hashes for files.
\nSearching for cli tools, and remembering them can be annoying. And the exisiting online hashing tools look either almost too barebone, or maybe scammy. Also I'm dubious about giving random websites access to those files.\nI get the hypocrisy, but with my own stuff I know what's going on :D
\nThe tool allows loading files, and typing text. It then gives you sha-1, sha-256, and md5 hashes.
\nThe sha hashes use the built in browser apis. For md5 I found @smithy/md5-js, which seems reasonably popular.
\nYou can check it out at tools.thisotherthing.co/hash
\nI started working through my planned tasks there (but also started adding to the list again).
\nYou now have:
\nmap, clamp, min, max<, >, ==, <=, >=\n0 or 11billionYou can try the updates at tools.thisotherthing.co/calc
\nI also added more color themes. I didn't expect it, but I really like the gameboy colors XD
\n","date_published":"Sat, 13 Dec 2025 00:00:00 GMT"},{"id":"https://log.thisotherthing.co/posts/2025/service-workers-for-offline-web-apps/","url":"https://log.thisotherthing.co/posts/2025/service-workers-for-offline-web-apps/","title":"Service Workers for offline web apps","content_html":"I recently worked on getting my web tools to also work offline.
\nWhile there are tools like Workbox and also a wrapper for Workbox for vite, those feel quite "big", and config heavy.
\nMy tools mostly don't feel like a PWA to me, that you would install on your phone.
\nSo I wanted to try it myself, and learn about service workers.
\nAbout the code:
\nimport { createHash } from "node:crypto";\nimport { existsSync, mkdirSync, writeFileSync } from "node:fs";\nimport { join } from "node:path";\n\nimport { type Plugin } from "vite";\n\nconst getServiceWorkerCode = (\n cacheName: string,\n fileToCache: string[],\n): string => {\n const builder: string[] = [];\n\n builder.push(`const cacheName = "${cacheName}";`);\n builder.push(`self.addEventListener('install', (e) => {\n console.info('[Service Worker] Install');\n e.waitUntil((async () => {\n const cache = await caches.open(cacheName);\n console.info('[Service Worker] Caching all: app shell and content');\n await cache.addAll(${JSON.stringify(fileToCache)});\n })());\n});`);\n\n builder.push(`self.addEventListener('fetch', (e) => {\n // Cache http and https only, skip unsupported chrome-extension:// and file://...\n if (!(\n e.request.url.startsWith('http:') || e.request.url.startsWith('https:')\n )) {\n return;\n }\n\n e.respondWith((async () => {\n const r = await caches.match(e.request);\n console.info(\\`[Service Worker] Fetching resource: \\${e.request.url}\\`);\n if (r) return r;\n const response = await fetch(e.request);\n const cache = await caches.open(cacheName);\n console.info(\\`[Service Worker] Caching new resource: \\${e.request.url}\\`);\n cache.put(e.request, response.clone());\n return response;\n })());\n});`);\n\n return builder.join("\\n");\n};\n\nexport const OfflineServiceWorkerPlugin = (\n options: { projectName: string },\n): Plugin => {\n return {\n name: "offline-service-worker-plugin", // this name will show up in logs and errors\n enforce: "post",\n apply: "build",\n transformIndexHtml: {\n order: "post",\n handler: () => {\n return [{\n tag: "script",\n children: `if ("serviceWorker" in navigator) {\n\t\t\tnavigator.serviceWorker.register("/sw-${options.projectName}.js", {scope: "/${options.projectName}"});\n\t\t}`,\n injectTo: "body-prepend",\n }];\n },\n },\n generateBundle: (bundleOptions, bundle) => {\n // const project = options.dir.split("/").at(-1);\n\n const files = Object.keys(bundle);\n\n const buildHash = createHash("md5").update(files.join(",")).digest(\n "hex",\n ).slice(0, 8);\n\n if (!existsSync(bundleOptions.dir)) {\n mkdirSync(bundleOptions.dir, { recursive: true });\n }\n\n writeFileSync(\n join(bundleOptions.dir, "../", `sw-${options.projectName}.js`),\n getServiceWorkerCode(\n buildHash,\n files,\n ),\n );\n },\n };\n};\nAdd this to your repo, and your vite app's config in plugins. Then it should also work for your projects
\nSome things I learned:
\nindex.html was in the same folder as the service worker, this didn't work, when the page url ended up being /tool, rather than /tool/. Since /tool/sw.js is then deeper than /toolindex.htmlYou can try the result with all my tools, for instance here with the comic reader.
\n(I mostly wanted offline support for this one :D To read comics in trains, which sometimes don't have internet)
\n","date_published":"Fri, 21 Nov 2025 00:00:00 GMT"},{"id":"https://log.thisotherthing.co/posts/2025/folder-sizes/","url":"https://log.thisotherthing.co/posts/2025/folder-sizes/","title":"new tool folder-sizes","content_html":"New tool alert :D
\nYou can get more info on the\nproject's page on my portfolio.
\n\n\n
I've been a bit lazy about updating the portfolio, but finally was motivated to do so.
\nIt now has pages for my eInk home dashboard display/device, deborahburgstaller.com, my large cargo strap backpack, the comic-reader, and bike toke backpack.
\nI think I'll add nicer images to the bike toke backpack, but for now I just wanted to get it onto the page.
\n\nI made a new tool. It's for reading comics :D
\nLink to project documentation\nLink to comic-reader
\nI started a new tool. It's for doing ffmpeg stuff in the browser.
\nI moved the ui from the spritesheet tool, into a shared library. Also started adding a foldable folder, and file inputs.
\nSo far it can generate a video from images, and generate a poster image from a video.
\nAdding more tools here should be easy (as long as the inputs are already supported in my ui library).
\nI also want a more generic tool, where you can add any file, run any command, and get the results downloaded.
\n\nKeeping up with cycling events in/around Vienna can be bothersome.
\n\nThere's a bunch of events, but so far I couldn't find a combined shared calendar or rss/json feed.\nThere's a facebook group, but I couldn't find a way to get the events outside of facebook (and the dom looks like a mess).
\nSo I made a custom feed for myself.
\nI found a couple sites with events. If I find more, I'll add them as well.
\n\nIt's a deno script, that returns a json feed.
\nThe script loads the first page of the sources, finds the events in the dom, and adds them to the list of feed items. Each item has the event page's url as its id.
\nAll sites are different, and have different implementations, but finding the relevant data was quick with a few querySelectorAll thanks to deno dom.
For almost all sources, it just loads just one page (for Fahrrad Wien it also loads a second page, to get the events for the following month).\nThis hopefully shouldn't put stress on the servers.\nThe links also always point back to the event pages there.
\nIf there's nice dom available for the event on the main page, then it gets put in the body of the feed items. Worst case it's just the link with a title.
\nI used json feed, since I didn't want to bother with xml, and it seems to be well supported in rss readers now. It's also really easy to generate, especially if you're doing it with typescript :D
\nRight now, the script always fetches the pages, extracts the data, and returns the feed.
\nThis could be improved by fetching the pages with a cron job and putting the data into some kinda database. This could then also generate a json file, that can be served statically.
\nThe most obvious improvement would be getting more info on the events, and putting them in a common format.
\nBut that would probably mean loading each events page (therefore putting more strain on the pages, and running for longer). And doing more involved extraction of the data from the dom.
\nSome pages also have no structured data, so it would likely need some natural language processing, which I'd rather skip for this project.
\nFor now I think just getting the links to events is enough. I'll click the link, and add it to my calendar by hand.
\nCreate an .ics file for each event, and add it to the feed item's body. This would be really nice, but would require getting more structed data, as listed before. So this seems out of scope.
\nThe alternative would be creating a shared calendar, but this again needs more data to automate.\nAdding entries by hand is something I'd rather not do, especially if it's just for myself.
\n","date_published":"Sat, 28 Dec 2024 00:00:00 GMT"},{"id":"https://log.thisotherthing.co/posts/2024/hosting-updates/","url":"https://log.thisotherthing.co/posts/2024/hosting-updates/","title":"hosting updates","content_html":"I've been moving my online stuff to new places.
\n\nThings that only need static hosting (like this blog), are now served by bunny.net.
\nI wanted to switch to an EU based provider, and prefer paying a fair price, rather than depending fully on US based free options.
\nBefore I was using Cloudflare Pages and before that AWS S3 with Cloudflare.
\nTo upload stuff, I wrote my own package to handle syncing the build output folders to the online storage, and purging CDN caches. It's available on jsr.io.
\nIf I can, I like writing serverless functions, to gather data from multiple APIs or generate json feeds etc.
\nDeno is really nice for that, given that I'm quite comfortable with typescript, and you can also easily run things using deno deploy.\nBut it still has issues with deno workspaces, and once again, I disliked the thought of being dependent on the free option.
\nBunny.net recently started offering running serverless functions. So I started to switch to that.\nIt can only handle a single script file thought, so I take the script entrypoint and bundle it into a single file, using the bundle function from @deno/emit.
So for now "serious" scripts can be run with bunny.net, and for other quick stuff I use deno deploy.
\nI also have some apps and scripts in the opsCanvas monorepo, that generate images for me. Since this involves wasm files and a workspace, deno deploy stopped working for me there. And bunny.net's single file doesn't work with the wasm files.
\nSo a couple months ago I decided to try running that stuff on a small server. Initially on Vultr and now Hetzner. It's run using pm2, so that when I push changes to github, the changes are pushed to the server, and apps get restarted. If an app crashes, it should also get automatically restarted.\nIt's then served through caddy, since that seemed easier to setup than nginx.
\nBefore I was too afraid to run servers. I was worried about getting hacked, the cost, and having to to server administration etc.
\nThe final push was Deno Deploy still not supporting workspaces, even after a couple months.
\nI then saw a couple tutorials for doing basic hosting and it seemed quite doable to get a basic setup running. Having a couple years of experience with using cli tools and terminals, also helped my confidence there.
\nThe servers can be rented for relatively cheap, so worst case I loose a little, and maybe have to set up a new server. After doing that 3 times, I feel like I'm kinda confident in doing that for myself :D\n(and I have written instructions for myself, that I mostly can just copy paste into the terminal )
\n","date_published":"Mon, 23 Dec 2024 00:00:00 GMT"},{"id":"https://log.thisotherthing.co/posts/2024/diff-updates/","url":"https://log.thisotherthing.co/posts/2024/diff-updates/","title":"diff tool updates","content_html":"Continued on the diff tool.
\nIt's been complicated making things work nicer, and the diffing libraries seem more focused on diffing for version control systems/unit tests, where the focus is more that a line changed. Rather than what gives a nice visual diff.
\nI also struggled a lot, with detecting added/removed lines.
\nFor now I view this still as work in progress. Let's see when I feel up to working on it again :D
\n","date_published":"Mon, 23 Dec 2024 00:00:00 GMT"},{"id":"https://log.thisotherthing.co/posts/2024/diff-tool-start/","url":"https://log.thisotherthing.co/posts/2024/diff-tool-start/","title":"started text diffing tool","content_html":"Well, that went fast :D
\nI've started on the text diffing tool. I got a basic unified and split differences view working.
\n\nIt's inspired by Diffchecker, but it will run fully locally in the browser, and without any tracking etc
\nIt's once again using a rust crate, this time the similar crate. With some extra splitting, to make line based diffs for the split diff work.
\nThe wasm calls js functions directly, to insert the text into the targets in the dom.
\nThis makes unit testing a bit harder, so I added e2e testing with playwright to the repo.
\nI'm not sure how I'll handle the unified diff testing yet (I'll guess very manually). But for the split view, I could check, that the results have the same text as the inputs, and then extra checks, that the diffs are also showing up correctly.
\nI want to make the split diffing look way nicer, and maybe add options?\nStarting with nicer looking line numbers, and spacers for removed/added lines, so related lines are also closer together.
\nFollowed by an optimization pass, as soon as the functionality is there.
\nOnce I'm happy with how it looks and works, it'll be listed in the tools index page.
\n","date_published":"Fri, 20 Dec 2024 00:00:00 GMT"}]}