标签：#Java

I built a calculator for BaZi — Chinese "Four Pillars" birth charts. Whatever you think of the interpretive tradition (and I'll get to that), the input math turned out to be a genuinely deep time-zone problem, and that's what this post is about. If you've ever thought "time zones, how hard can it be" — this is a tour of exactly how hard, with working TypeScript. The problem BaZi divides the day into twelve two-hour "branches", so your birth hour is one of the chart's four pillars. Get the hour wrong and you get a different chart — not slightly different, categorically different. Every calculator I could find feeds the system the wall-clock time from your birth certificate. But the tradition predates time zones by about two thousand years; it obviously means solar time — where the sun actually was over your birthplace. Clock time and solar time differ by more than most people think, and the difference decomposes into exactly three parts: 1. Daylight saving time — and it's historical. You need the DST rules in force on the birth date , not today's. China ran a now-forgotten DST experiment from 1986–91; Harbin kept its own zone before 1949. If you were born in Beijing in July 1988, your certificate is an hour ahead of standard time and no modern-day lookup will tell you that. 2. Longitude. Solar time shifts 4 minutes per degree from your zone's standard meridian. China spans five geographic zones but uses one clock — born in Ürümqi, your clock runs about two hours ahead of the sun. It's not just a China quirk: Vancouver sits at 123°W in a zone whose meridian is 120°W, so that's another 12 minutes, everywhere, always. 3. The equation of time. The sun itself runs up to ±16 minutes fast or slow over the year, thanks to orbital eccentricity and axial tilt. NOAA publishes an approximation that's accurate to under a minute: /** Equation of time (minutes), NOAA approximation */ export function equationOfTimeMinutes ( dayOfYear : number ): number { const b = ( 2 * Math . PI *

GitHub热门项目 | Database manager for MySQL, PostgreSQL, SQL Server, MongoDB, SQLite and others. Runs under Windows, Linux, Mac or as web application | Stars: 7,269 | 6 stars today | 语言: JavaScript

I run a search engine that publishes in twelve languages from one static site on Cloudflare Pages. Last week I audited its machine-readable layer — the part crawlers and answer engines read rather than humans — and found four problems. None of them threw an error. None appeared in logs. Every page rendered perfectly. That is the whole point of this post: the multilingual layer fails in a register where nothing tells you. 1. The homepage was serving the wrong language to everyone abroad The site's primary market speaks Hebrew, so / is Hebrew and /en/ , /ar/ , /de/ and nine others sit alongside it. A middleware rule redirected visitors from one specific region to their language. Everyone else — including every English speaker on earth — landed on Hebrew. My first instinct was to fix it with a broader geo-redirect: detect English-speaking countries, send them to /en/ . This would have been a bad idea, and it is worth saying why. Googlebot crawls predominantly from US IPs. A geo-redirect on / that keys off country would take the crawler off the Hebrew homepage and onto the English one almost every time it visited. You do not want your primary-market homepage to become the page the crawler can never reach. The correct tool is hreflang , and it is what search engines built for exactly this. Checking the page, the tags were already there and already right: <link rel= "alternate" hreflang= "he" href= "https://example.com/" > <link rel= "alternate" hreflang= "en" href= "https://example.com/en/" > <link rel= "alternate" hreflang= "ar" href= "https://example.com/ar/" > <!-- …ten more… --> <link rel= "alternate" hreflang= "x-default" href= "https://example.com/en/" > Two things make this work, and both are easy to get wrong: The set must be reciprocal. Every page in the group lists every other page including itself . If /en/ does not point back at / , search engines are entitled to ignore the whole cluster. x-default is not "the default language" — it is the fallback for users

I spent a while building an icon editor that runs entirely in the browser (icons.jamuny.com, free, no account). Here is what cost me the most time. A presentation attribute loses to any author CSS rule I was scaling handle stroke widths by 1 / zoom and writing the result as an attribute. The value was never used. handle . setAttribute ( ' stroke-width ' , String ( 0.35 / zoom )); .handle { stroke-width: 0.35 } in the stylesheet outranks it, because a presentation attribute sits at the very bottom of the cascade. Measured in Chromium: an attribute of 0.05 computed as 0.35px . Every handle thickened on screen as you zoomed in, for months, with no error anywhere. The fix is a custom property, which is an ordinary declaration and wins where an attribute cannot: layer . style . setProperty ( ' --px ' , String ( 1 / zoom )); /* .handle { stroke-width: calc(0.35 * var(--px)) } */ Geometry attributes like r and width are unaffected. They have no CSS counterpart here, so nothing was ever overriding them. A focused SVG element gets a focus ring measured in user units My canvas is 24 units wide and about 620 pixels. Chrome drew its default focus ring at outline-width: 2.72727px in user units, which is about 24 screen pixels. A fat blue disc appeared around every point you clicked. It was reported to me four times, and four times I thinned something of my own that was not the cause. getComputedStyle ( document . activeElement ). outline That one line found it. My rule only covered :focus-visible , which is the keyboard case, and the keyboard case is the one where I draw a ring of my own. var() does work in a presentation attribute, and I wrote down that it doesn't I needed a segment colour that changes with the theme, so the value is oklch(var(--band-l) var(--band-c) 47) . I applied it through a style and put a comment beside it saying var() is not substituted in presentation attributes. It is. Both forms compute to the same colour, including on an element built detached and ap

I built an OLX scraper for 24 countries — the boring version that actually ships OLX runs classifieds in about two dozen countries. Same brand, different domains, different anti-bot setups. Everyone scraping it does one country at a time. I got tired of forking. So I put 24 countries behind one input. country: "id" or country: "pl" or country: "br" — same schema out. It's live on Apify as primesieve/olx-global-scraper . One file. No browser. Here is the boring part that matters. What it does Input: { "country" : "id" , "keywords" : [ "iphone 13" ], "maxResults" : 50 , "maxPages" : 3 , "proxyConfiguration" : { "useApifyProxy" : true , "apifyProxyGroups" : [ "RESIDENTIAL" ] } } country — two-letter code ( id , pl , in , br , ua , pt , ro , bg , kz , uz , pk , za , ng , ke , eg , lb , ph , co , ar , pe , ec , gt , az , ma ). Default id . keywords — one or more search terms. Each runs sequentially. maxResults / maxPages — caps. Defaults 50 / 3, max 1000 / 30. proxyConfiguration — optional for Indonesia, required for the other 23. Output — same shape every country: { "listingId" : "123456789" , "title" : "iPhone 13 128GB mulus" , "price" : 6500000 , "priceText" : "Rp 6.500.000" , "currency" : "IDR" , "city" : "Jakarta Selatan" , "location" : "Tebet, Jakarta Selatan, DKI Jakarta" , "images" : [ "https://...jpg" ], "thumbnailUrl" : "https://...jpg" , "listingUrl" : "https://www.olx.co.id/item/123456789" , "country" : "id" } Title, price (numeric plus display text), currency, location, images, URL. No seller PII beyond what the listing page shows. No tricks. Try: https://apify.com/primesieve/olx-global-scraper The boring stack // no playwright, no puppeteer // apify + fetch + cheerio. That's it. The scraper is one file. Apify SDK for input, dataset, and pay-per-event. Native fetch for HTTP. cheerio for the HTML path. Undici ProxyAgent when a proxy is configured. Node 20, 512 MB, 600s timeout. I check the endpoint before I write the scraper. Indonesia answered with clean JSO

Most free chess game review gives you one game per day. Chess.com works that way, and so does almost every smaller site offering the feature. I assumed for a long time that this was just a paywall placed where it hurts. It is partly that. But there is a real cost sitting behind the cap, and once I worked out what the cost was, I built my own analysis site differently. The cost of one game review Reviewing a 40 move game means evaluating about 80 positions. Give the engine two seconds on each one and you have spent close to three minutes of CPU. None of it is cacheable, because your game is not anyone else's game. Run that on your own hardware and you pay for every minute. A thousand people reviewing one game a day is roughly 50 CPU hours daily, for a feature you are giving away. The quota is not greed. It is the number that stops the free tier from eating the company. Which raises a more interesting question than "how do I price this". What happens if you delete the cost instead of rationing it? Move the engine to the client Stockfish compiles to WebAssembly. Put it in a Web Worker and the visitor's own processor spends those three minutes. Your server ships static files and never sees a chess position. The whole free tier problem disappears, because there is no per-user cost left to control. Nothing to meter, so nothing to cap. Getting started is unremarkable: const engine = new Worker ( " stockfish.js " ); engine . postMessage ( " uci " ); engine . postMessage ( " isready " ); After that you speak UCI over postMessage . Set a position, ask the engine to think, and read results off the message stream: engine . postMessage ( `position fen ${ fen } ` ); engine . postMessage ( `go depth 15 movetime 2000` ); That is the pitch. Now the parts nobody mentions. The protocol is strings, and it is asynchronous UCI was designed for a pipe between two processes. You get that pipe, faithfully, with all of its ergonomics intact. The engine answers with lines like this: info dept

Cómo solucionar el error “Enable JavaScript and cookies to continue” Este mensaje aparece cuando Cloudflare (u otro proxy de seguridad similar) bloquea la solicitud porque detecta que el cliente no cumple con los requisitos mínimos de seguridad: JavaScript deshabilitado o cookies deshabilitadas/expiradas . 🔍 Causa técnica Cloudflare implementa mecanismos de protección como: JavaScript Challenge : El navegador debe ejecutar un script para demostrar que no es un bot. Cookie de verificación : Tras superar el desafío, Cloudflare emite una cookie ( __cf_bm o cf_clearance ) que valida la sesión. Si el cliente (navegador o cliente HTTP personalizado) no ejecuta JavaScript o no maneja cookies correctamente, la validación falla y se muestra este mensaje. ✅ Solución definitiva (por escenario) 🌐 Si eres un usuario final (navegador) Habilita JavaScript : Chrome: Configuración > Privacidad y seguridad > Sitios web no seguros > Habilitar JavaScript . Firefox: Preferencias > Privacidad y seguridad > Permisos > Habilitar JavaScript . Habilita cookies de terceros (si usas extensiones como uBlock Origin o Privacy Badger): Añade el dominio a la lista blanca. Desactiva temporalmente los bloqueadores para probar. Borra cookies y caché del dominio afectado. Reinicia el navegador y vuelve a cargar la página. 🧪 Si eres desarrollador (automatización / scraping / cliente HTTP) ❌ No uses requests o curl sin soporte JS/cookies → fallarán siempre . ✅ Opción recomendada: Usa un navegador headless con soporte JS y cookies # Ejemplo con Playwright (recomendado) from playwright.sync_api import sync_playwright with sync_playwright () as p : browser = p . chromium . launch ( headless = True ) context = browser . new_context () page = context . new_page () # Navega a la URL (Cloudflare se resolverá automáticamente) page . goto ( " https://ejemplo.com " , wait_until = " networkidle " ) # Si aún falla, fuerza espera tras el desafío try : page . wait_for_selector ( " #challenge-error-text " , timeout = 5

VoidZero has launched the beta of Vite+, a unified web development toolchain. It combines runtime, package management, and essential frontend tools under a single command. Vite+ supports various projects and is open source. The platform enhances workflow through features such as hot-reloading, format checking, and testing. The team emphasizes community feedback for future updates. By Daniel Curtis

A lot of small file jobs still follow the same awkward pattern: choose a file, upload it to someone else's server, wait for processing, download the result. For some tasks, that server round trip is unnecessary. I have been building FileNest Worktools , a browser-based toolkit for repetitive file work, around a simple constraint: If a task can reasonably be done inside the browser, the file contents should stay on the user's device. What currently runs locally The current FileNest tools cover: batch file renaming sequential, reverse, and custom-order renaming JPG / PNG / WebP conversion image resizing and compression image-to-text OCR with editable review PDF merge, split, extract, and images-to-PDF text export to DOCX, PDF, TXT, Markdown, and HTML CSV / TSV / JSON conversion duplicate-file detection For these current browser-local workflows, the file contents are processed on the device rather than being sent to a conversion server. Why local processing matters Privacy is one reason, but it is not the only one. Many file operations do not actually need server-side infrastructure. Renaming a file is mostly about filenames, order, extensions, and conflict checks. Image resizing can be handled with browser APIs. CSV and JSON conversion is essentially local parsing and serialization. Duplicate detection can compare file fingerprints locally. If those jobs can stay inside the browser, there is less network overhead and one less copy of the user's files being created somewhere else. I also wanted the risky parts to stay visible One thing I dislike about many online file tools is the "click and hope" workflow. So I tried to make FileNest show more information before or after processing: renamed files can be previewed before packaging original files are not silently overwritten image compression reports actual output bytes duplicate detection uses content matching rather than filename guesses OCR output can be reviewed and edited the image enhancer does not claim that shar

GitHub热门项目 | A coding-agent skill for multi-phase security audits with independently verified, machine-readable findings | Stars: 3,004 | 29 stars today | 语言: JavaScript

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. When I was...

When merging CSVs in the browser, handling mismatched columns and quoted cells changes everything. Here's how filetools does it. Last week we shipped CSV merge/split/transpose tools for filetools, and the most interesting challenge wasn't CSV parsing - it was handling real-world data without a server. Here's how we handle the hard cases. The Problem: CSV files in the wild are messy. Columns don't always match. A cell value contains a comma and that comma is quoted. Headers are sometimes case-sensitive, sometimes not. When you build on a server, you can run a fast library and stream the result. In the browser, you have to make your merge operation deterministic from first load. Our approach: Column matching: Users specify which columns to merge on (e.g., "id" or "email"). We do a case-insensitive first pass, then check for exact matches. If no match exists, we warn the user and ask them to pick from the detected headers. This upfront clarity saves merge errors later. Quoted cell handling: We follow RFC 4180 strictly - a quote inside a quoted field is escaped as a double quote. Most CSV parsers get this wrong when they're quick. We use the csv-parse library (MIT) vendored into the site, same way we do with PDF and ZIP libraries. Column order: The merge operation respects column order from the first file, then appends any new columns from subsequent files. This is deterministic and reproducible. Why this matters for a browser tool: Server-based CSV tools hide their assumptions - you upload, they merge, you download. If a merge fails, you get an error message and no insight into why. Client-side, the user can see the detected headers, approve or correct them, and re-try immediately. That transparency matters when you're dealing with data that represents real records or transactions. What shipped this week: We added merge, split (by row count or column value), transpose, and comparison tools. The same deterministic, transparent approach applies to each one. Next question

I shipped four browser-only video tools with ffmpeg.wasm: trim, compress, video-to-GIF and MP3 extraction. Files never leave the browser, nothing to install. Trim · Compress · GIF · MP3 (Korean UI, but the buttons are obvious) Getting there, I hit four walls. Every one of them surfaced as a single "conversion failed" line in the UI and nothing in the console . Writing them down for the next person. Stack: Next.js App Router + webpack, @ffmpeg/ffmpeg 0.12, self-hosted core. 1. webpack hijacks the dynamic import inside the worker @ffmpeg/ffmpeg spawns its worker like this: new Worker ( new URL ( " ./worker.js " , import . meta . url ), { type : " module " }); webpack recognises the pattern and bundles the worker. Fine. But it also rewrites the import(coreURL) inside that worker to go through its own module loader. The core URL arrives at runtime as a blob: URL, which webpack's loader has never heard of, so it dies with Cannot find module 'blob:...' . The error is thrown inside the worker, so the main-thread console stays empty. Fix: keep the worker out of the bundle. Copy node_modules/@ffmpeg/ffmpeg/dist/esm/worker.js to public/ffmpeg/<version>/lib/ and pass it via classWorkerURL in load() . Now the untouched worker runs. 2. classWorkerURL needs the origin Passing a path like /ffmpeg/0.12.x/lib/worker.js is not enough. The library resolves it with new URL(classWorkerURL, import.meta.url) , and inside the bundle import.meta.url is a build-time file:///C:/... path. So it goes looking for file:///C:/ffmpeg/... and fails. const BASE = `/ffmpeg/ ${ FFMPEG_VERSION } ` ; await ffmpeg . load ({ coreURL : ` ${ location . origin }${ BASE } /core/ffmpeg-core.js` , wasmURL : ` ${ location . origin }${ BASE } /core/ffmpeg-core.wasm` , classWorkerURL : ` ${ location . origin }${ BASE } /lib/worker.js` , }); Prefix location.origin and it works. 3. You cannot build a GIF palette with -vf For decent GIF quality you run palettegen first and paletteuse second. Doing it in one pass needs

I built a Korean dialect converter that runs entirely in the browser and uses no LLM. Type a standard Korean sentence and it rewrites it the way people speak in Gyeongsang, Jeolla, Chungcheong, Gangwon or Jeju. Paste a dialect sentence and it converts back to standard Korean. Nothing leaves the browser. Try it: https://toolnjoy.com/dialect-converter (Korean UI) The hard part was not producing dialect. It was not breaking standard Korean . Every time I widened a rule, a perfectly normal sentence got mangled somewhere. Here is what I ended up with. Most of it applies to any rule-based text rewriter (honorific converters, profanity filters, spelling normalizers). Shape of the thing Four modules: file job core sentence splitting, sentence-type detection, ending replacement endings per-region ending tables (declarative / interrogative / propositive / imperative × politeness) words per-region vocabulary reverse dialect → standard Forward conversion goes "decide the sentence type, then pick the region's ending". Reverse goes the other way: "look at the ending, infer the sentence type". You cannot just invert the forward table, so reverse has its own table. Each reverse rule carries a type , which removes the detection step entirely. In reverse mode the user does not pick a region. I run all five and keep the one with the highest score (4 points per matching ending + syllable count of matched words). People who paste dialect usually do not know which region it is from. That is why they came. Eight guards, each from a real failure 1. Never reverse a form that appears on the standard side of any table. The Gyeongsang table had 함께 → 같이 (together). Reverse flipped it and rewrote "같이 보게" into "함께 보게", except 같이 is perfectly standard. Fix: anything that ever appears in a standard column anywhere is excluded from reverse candidates. 2. Question endings only count when there is a question mark or a wh-word. Gyeongsang -나 / -노 mark questions. But 하나 ("one") also ends in -나 . Without

We've all been there: a client needs a quick QR code for a print campaign, or a short link for social media. You search Google, click the first result, and realize you need to create an account, verify your email, and potentially pay after 14 days. To solve this friction, we built klick.tools . It's a collection of simple web tools that just work - no signup, no expiration dates, and full GDPR compliance. What's inside? QR code generator: 7 content types (URL, text, WiFi, vCard, email, phone, geo), custom colors and module shapes, automatic WCAG contrast check, and clean export as PNG, SVG or PDF. Rendering happens in the browser, so the payload never leaves the device. URL shortener: shorten a link in seconds, see click stats, and change the target later without reprinting anything. The developer API We didn't want to build just another consumer site, so everything is backed by a REST API. Base URL: https://klick.tools/api/v1 . Responses are always JSON - lists as { data, count } , writes as { message, data } , errors as { error } with a stable machine-readable code . Creating a short link is a single POST, and it works without an account at all (rate-limited per IP): curl -X POST https://klick.tools/api/v1/links \ -H "Content-Type: application/json" \ -d '{"targetUrl": "https://example.com/a-very-long-campaign-url"}' With an API key ( kt_live_... , generated in your account) the link is bound to you, so you get click counts, editing and higher quotas. Pass it as a Bearer token or via x-api-key : const res = await fetch ( " https://klick.tools/api/v1/links " , { method : " POST " , headers : { " Content-Type " : " application/json " , Authorization : `Bearer ${ process . env . KLICK_TOOLS_API_KEY } ` , }, body : JSON . stringify ({ targetUrl : " https://example.com/landing " , title : " Summer campaign " , }), }); const { data } = await res . json (); console . log ( data . shortUrl , data . clickCount ); The same pattern covers QR codes via /api/v1/qr - create, li

Six weeks ago I got cut off mid-debugging session by Claude's rate limit with no warning. Two hours of context gone. I started looking for a tool that would show me how close I was before it happened. Nothing existed that worked across more than one platform without requiring an API key. So I built one. TokenPulse is a Chrome extension (MV3) that injects a live token bar above the input box on Claude, ChatGPT, Gemini, DeepSeek and Grok. It tracks context window usage, rate limits, cost estimates, and daily history — all from your existing browser session, no API key required. Here's how it works technically. Architecture overview Content Scripts (per platform) ↓ Background Service Worker ↓ Chrome Storage API (local) ↓ Popup UI ↓ Desktop Notifications The extension runs a content script on each supported domain. Each script is responsible for: Reading token usage data from that platform Injecting the visual bar above the input box Sending data to the background service worker via chrome.runtime.sendMessage The service worker aggregates data, writes to chrome.storage.local , checks notification thresholds, and serves data to the popup on demand. How Claude's rate limits are read Claude is the only platform that exposes real rate limit data through its internal API. When you use claude.ai, the browser session makes requests to a usage endpoint that returns exact utilization percentages and reset timestamps. The content script intercepts this data by hooking into the platform's network requests using a MutationObserver to detect when Claude updates its state, then reading the cached response. The response looks roughly like: { five_hour : { utilization : 0.82 , reset_at : " 2026-07-15T14:14:00Z " }, seven_day : { utilization : 0.34 , reset_at : " 2026-07-21T21:00:00Z " } } This gives exact percentages — not estimates. The popup shows these directly. Client-side token estimation for other platforms ChatGPT, Gemini, DeepSeek and Grok don't expose usage data the same way.

Originally published on tamiz.pro . The Silent Crisis: Undefined Behavior Across Language Boundaries Recent high-profile security incidents have exposed a growing concern in the software engineering world: undefined behavior (UB) is not just a C/C++ problem anymore. From Rust compilation bugs to JavaScript engine vulnerabilities, developers are witnessing how subtle language design choices can lead to catastrophic failures when code crosses language boundaries or interacts with low-level systems. These incidents aren't isolated — they represent a systemic issue affecting modern software stacks built on heterogeneous language ecosystems. Case Study: The Rust Memory Safety Myth Rust was built with the promise of memory safety without garbage collection. Yet, recent CVEs have revealed that undefined behavior in unsafe Rust blocks can compromise entire systems: The 2024 OpenSSL Rust Port Incident A critical vulnerability was discovered in a Rust port of OpenSSL where unsafe code blocks performed unchecked pointer arithmetic. While the safe Rust layer enforced bounds checking, the unsafe boundary passed raw pointers to the C layer without validation. // Vulnerable pattern discovered in the incident unsafe { let ptr = slice .as_mut_ptr (); // No bounds check - undefined if offset exceeds slice length let unsafe_slice = std :: slice :: from_raw_parts_mut ( ptr , len + offset ); } This wasn't caught by Rust's compiler because it explicitly allows unsafe operations. The UB only manifested during cross-language calls to the underlying C library. The WebAssembly Compilation Bug Another incident involved a Rust-to-Wasm compilation bug where the compiler optimized away what should have been defensive checks, assuming the guarantees of safe Rust would hold at runtime. When these assumptions broke at the Wasm boundary, attackers could trigger heap overflows. JavaScript's Hidden Undefined Behavior While JavaScript is often criticized for loose typing, its recent security incidents

Hey everyone! 👋 Like many developers and sysadmins, I constantly find myself needing to share temporary credentials, API keys, or sensitive text with clients and coworkers. Dropping these straight into Slack, Discord, or standard email always feels like a massive security headache because those chat platforms store everything in plain text in their databases. I looked into popular "one-time secret" web utilities, but I noticed a major flaw: almost all of them handle the encryption and decryption on their servers. That means you have to blindly trust their backend configurations, logging policies, and database security. I wanted something truly zero-knowledge where the server owner physically couldn't read the notes even if they wanted to. So, I built ScorchNote : https://scorchnote.com 🛠️ How it Works (Under the Hood) To achieve absolute zero-knowledge, ScorchNote relies on strict client-side mechanics: Browser-Side Encryption: When you type a secret, the data is encrypted directly in your browser before it ever leaves your network interface. The URL Hash Advantage: The decryption key is generated and stored inside the URL's hash fragment (everything after the # ). Zero Server Footprint: Web browsers never send the hash fragment to the host server during HTTP requests. This means my database only receives a completely scrambled, encrypted payload. The server has no concept of what the key is. Millisecond Burn-on-Read: The moment the recipient visits the link, the encrypted payload is fetched and instantly purged from the server database. 🚀 Try It Out I kept the page entirely lightweight, minimalist, and completely free of bloated tracking scripts. It’s built to do exactly one job, safely and instantly. I would love to hear your thoughts on the architecture, the user experience, or what features you think I should cook up next! Check it out here: ScorchNote

I recently built filetools, a suite of file utilities that run entirely in the browser. No server backend, no file uploads, no data collection. The Problem Existing tools for CSV extraction, PDF manipulation, and table conversion often require uploading files or creating accounts. That creates friction and privacy concerns. But these tasks are fundamentally simple: extracting text from a PDF or parsing a CSV can happen entirely in JavaScript. The Solution filetools is a collection of single-purpose utilities: PDF Tools: Merge, split, rotate PDFs Extract tables from PDFs to CSV Convert bank statements to CSV Data Tools: Extract tables from HTML to CSV or JSON Convert between XLSX, JSON, YAML, and CSV Remove duplicate lines, sort CSV files, merge/compare data files Each tool is its own page, targeting one specific task without bloat. Architecture Why static hosting? Keeps infrastructure simple and costs near zero. Files are built once, served from GitHub Pages. Why client-side only? User files never leave their machine. Processing is fast (no network round-trip). Privacy is the default. Tech stack: vanilla JavaScript using npm libraries (pdfjs-dist, exceljs, js-yaml, pdf-lib) - no framework, no server. Each page is roughly 5-15KB gzipped. Design: Started with demand mining, looking at actual Google search queries and autocomplete suggestions to pick which tools to build first. What's Next Live site: https://usefiletools.com/?utm_source=dev.to&utm_medium=article&utm_campaign=filetools-launch I'm building more tools based on real search demand. If there's a file utility you've always wished existed, especially for data professionals, I'd love to hear about it.

I am building a site to make it easy to find both in-person and online events. It clearly needs a lot of improvements. This is what I got out of it now. 2026-08-20 (online) 🎙️ Metarhia community call 2026-08-20 (in-person) Boston TypeScript Club 2026-08-20 (in-person) Coding Agent con TS && AWS 2026-08-21 (in-person) IKIGAI 2026-08-22 (in-person) React Meetup #107 2026-08-23 (in-person) Code and Tea at Panera 2026-08-25 (in-person) Your Agent is Starving 2026-08-25 (in-person) Isolation: VMs, Containers, Namespaces, Oh my! | DenverScript August 2026 2026-08-26 (in-person) JavaScript Luzern Grill Edition #5 2026-08-26 (online) JavaScriptMN Monthly Event: Open Floor Show/Tell and Discussion 2026-08-27 (in-person) Frontendistim Community August Meetup at Matia! 2026-08-27 (in-person) Paderborn.JS Meetup 2026 2026-08-27 (in-person) Jozi.JS August - Make the code work 2026-08-27 (online) 🎙️ Metarhia community call 2026-08-27 (in-person) Why to choose Ember.js in 2026 2026-08-28 (in-person) Zagreb Developers Drinkup