World of Warcraft stores its textures in a proprietary format called BLP.\nBlizzard introduced it in Warcraft III around 2002, and it's been baked into\nevery WoW patch ever shipped since. If you've ever modded WoW or extracted game\nassets, you've run into these files. I built\n@pinta365/blp to read, parse, and convert\nthem in TypeScript — and blp-toolkit as a\nbrowser-based tool for anyone who just needs to convert a file.
The short answer is GPU efficiency. Standard image formats like PNG or JPEG are\noptimized for storage and transmission — they compress well and decode fast on a\nCPU. But a GPU doesn't want PNG. It wants textures in a format it can load\ndirectly into VRAM and sample from without any further decompression.
\nBlizzard needed a format that could:
\nBLP is the result. It's a container format that wraps one of several internal\ncompression schemes depending on what the texture contains.
\nBLP2 (the version used in WoW) supports three compression types:
\nDXT (also called S3TC) is the interesting one. It's a block-based\ncompression scheme designed specifically for GPU hardware. The image is divided\ninto 4×4 pixel blocks, and each block is encoded as a pair of endpoint colors\nplus a 2-bit index per pixel that interpolates between them. The result is a\nfixed compression ratio regardless of image content — 4:1 for DXT1, 2:1 for\nDXT3 and DXT5 — and crucially, GPUs can decompress it on the fly in hardware\nwhile sampling.
\nThree variants handle different alpha needs:
\nRAW1 (palettized) is the legacy format, used heavily in Warcraft III and\nearly WoW content. It stores 256 colors in a palette and one byte per pixel\npointing into it — the same approach as GIF. Compact for textures with limited\ncolor ranges, but not GPU-native.
\nRAW3 is uncompressed RGBA — no tricks, just raw pixel data. Largest files,\nfastest conversion.
\nimport { decodeBlpData, encodeToBLP } from "@pinta365/blp";\n\n// Read a BLP file and get raw RGBA pixel data\nconst blpBytes = await Deno.readFile("texture.blp");\nconst { width, height, rgba } = await decodeBlpData(blpBytes);\n\n// Convert a PNG back to BLP (DXT5 with alpha)\nconst pngBytes = await Deno.readFile("texture.png");\nconst blpOutput = await encodeToBLP(pngBytes, { compression: "dxt5" });\nawait Deno.writeFile("texture_new.blp", blpOutput);\nEvery BLP file bundles a mipmap chain — pre-computed half-resolution copies of\nthe texture, all the way down to 1×1. So a 512×512 texture ships with versions\nat 256×256, 128×128, 64×64, and so on, all inside the same file.
\nThe GPU uses these automatically. When a texture is rendered small (far away,\nsmall on screen), the engine samples from a smaller mipmap instead of\ndownscaling the full texture at runtime. This reduces aliasing and is far\ncheaper to compute.
\nThe library gives you access to all mipmap levels, which matters if you're doing\ntexture processing pipelines or want to inspect what the engine is actually\nusing.
\nBLP (like most GPU texture formats) requires image dimensions to be powers of\ntwo: 64, 128, 256, 512, 1024, and so on. This constraint goes back to how\ngraphics hardware addresses texture memory.
\nIf you try to convert a 300×200 PNG to BLP, something has to give. The library\nhandles this automatically with configurable padding modes that preserve the\nentire image — no cropping, no distortion. The padding approach matters\nespecially for texture atlases, where the actual content might not fill a\npower-of-2 canvas but all of it needs to survive the round-trip.
\nWhen encoding to BLP, picking the right compression variant isn't always\nobvious. The library analyzes the source image and recommends a format:
\nYou can override this, but the auto-detection handles the common cases correctly\nwithout requiring knowledge of the compression internals.
\nAll of the above is available at blp.pinta.land\nwithout installing anything. Upload a BLP file to get a PNG preview with full\nmetadata inspection — compression type, dimensions, mipmap count, all of it.\nOr upload a PNG and convert it to BLP with control over the target compression\nformat and padding mode.
\nEverything runs client-side. Your files never leave the browser.
\nIt's built in TypeScript with @pinta365/blp as the engine, so the same\nparsing and conversion logic that runs in your Deno or Node.js pipeline works\nidentically in the browser.
# Deno\ndeno add @pinta365/blp\n\n# Node.js / Bun\nnpx jsr add @pinta365/blp\nSource for both projects is on GitHub:\nblp and\nblp-toolkit.
\nPrimarily WoW modders and addon developers who work with game assets — either\nextracting textures from the client to reference in UI work, or creating custom\ntextures to ship with an addon. But it's also useful for anyone building tooling\naround Blizzard game data more broadly: map editors, model viewers, asset\npipelines.
\nThe BLP format isn't going anywhere. Two decades of game content means two\ndecades of BLP files out there, and the modding community still actively creates\nand converts them. Having a modern, cross-runtime TypeScript library for it felt\nlike a gap worth filling.
\n","date_published":"Thu, 26 Feb 2026 00:00:00 GMT"},{"id":"https://posts.pinta.land/posts/steganography/","url":"https://posts.pinta.land/posts/steganography/","title":"Hiding Secrets in Plain Sight","content_html":"What if you could send a secret message inside a perfectly ordinary photo of\nyour cat? No encryption warnings, no suspicious-looking ciphertext — just a\nJPEG that also happens to contain hidden data. That's steganography, and it's\nwhat I've been building with\n@pinta365/steganography and its\ncompanion web app UnderByte.
Cryptography hides the meaning of a message. Steganography hides the fact\nthat a message exists at all. Instead of encrypting "meet me at noon" into an\nunreadable blob, you embed it invisibly into a cover medium — an image, a\ndocument, or even plain text — and the result looks completely normal to anyone\nwho doesn't know to look.
\nThe word comes from Greek: steganos (covered) + graphia (writing). The\npractice goes back centuries, from invisible ink to microdots in wartime\nespionage. Today it shows up in digital watermarking, copyright protection, and\n— for our purposes — hiding messages inside image files.
\nThe most common technique for image steganography is Least Significant Bit\n(LSB) encoding. To understand why it works, consider how a PNG stores color.
\nEach pixel has red, green, blue, and alpha channels, each an 8-bit value from 0\nto 255. The most significant bits carry most of the visual information. The\nleast significant bit contributes almost nothing — flipping it changes a channel\nvalue by 1 out of 255, a difference no human eye can detect.
\nThat means you can overwrite the LSB of each channel with your own data without\nvisibly changing the image. A 1000×1000 PNG has 1,000,000 pixels × 4 channels\n= 4,000,000 bits available — enough to hide roughly 500 KB of data.
\nimport { embedTextInImage, extractTextFromImage } from "@pinta365/steganography";\n\n// Hide a message in a PNG\nconst encoded = await embedTextInImage(imageBytes, "Hello, world!");\n\n// Retrieve it later\nconst message = await extractTextFromImage(encoded);\n// → "Hello, world!"\nThe library also supports adjustable bit depth: instead of using just 1 bit per\nchannel, you can use 2, 3, or 4. More bits means more capacity, but also more\nvisible distortion — a trade-off you tune depending on how sensitive the image\nis and how much data you need to hide.
\nLSB works great for lossless formats: PNG, WebP, BMP, GIF. But send that\nimage through JPEG compression and the hidden data is destroyed — because JPEG\ndoesn't preserve exact pixel values.
\nJPEG compression works by dividing an image into 8×8 pixel blocks, applying the\nDiscrete Cosine Transform (DCT) to convert each block into frequency\ncomponents, and then quantizing (rounding) those components to discard detail\nthe eye won't miss. That rounding step is exactly what kills LSB-encoded data.
\nTo survive JPEG compression, you need to embed data in the DCT coefficients\nthemselves — before quantization is applied. The library does this by making\nsmall, deliberate modifications to the DCT coefficients in a way that survives a\nre-encode at the target quality level. The result is a JPEG that retains your\nhidden data even after it's been re-saved.
\nThis is significantly more robust than pixel-domain embedding, which is why it's\nused in real-world watermarking systems.
\nHere's the one that genuinely surprises people: you can hide data in plain text,\nwith no images involved.
\nUnicode includes a set of zero-width characters — code points that render as\nnothing visible. Characters like U+200B (zero-width space), U+200C\n(zero-width non-joiner), and U+200D (zero-width joiner) are completely\ninvisible in any rendered text. But they're still there in the raw string.
The library uses sequences of these characters to encode binary data and\ndistributes them throughout normal text. Copy-paste the result anywhere text is\naccepted — a tweet, a comment, a document — and the hidden message travels with\nit, invisible to readers but extractable by anyone with the right tool.
\nimport { encodeText, decodeText } from "@pinta365/steganography";\n\nconst cover = "Nothing to see here.";\nconst stego = await encodeText(cover, "secret payload", { encrypt: true, password: "hunter2" });\n\n// stego looks identical to cover when rendered\nconst decoded = await decodeText(stego, "hunter2");\n// → "secret payload"\nText steganography optionally layers AES-256-CTR encryption on top, so even if\nsomeone knows to look for hidden data, they can't read it without the password.
\nAll of the above is available through a browser at\nunderbyte.pinta.land. Upload an image, type your\nmessage, optionally set a password, download the result. The app shows you\nreal-time capacity statistics and lets you tune the bit depth — useful for\ngetting a feel for the LSB trade-offs without writing any code.
\nIt's built on Deno with the Fresh framework, using @pinta365/steganography as\nthe underlying engine.
The steganography library is runtime-agnostic and available on JSR and npm:
\nThe full source for both projects is on GitHub:\nsteganography and\nUnderByte.
\nSteganography has legitimate practical uses beyond the obvious "secret messages"\nscenario:
\nIt's also just a genuinely interesting space to build in. The gap between "this\nlooks like any other image" and "this image contains a hidden document" is\nsurprisingly narrow — a few bit flips per pixel is all it takes.
\n","date_published":"Sun, 22 Feb 2026 00:00:00 GMT"},{"id":"https://posts.pinta.land/posts/getting-started-with-ai-coding/","url":"https://posts.pinta.land/posts/getting-started-with-ai-coding/","title":"Getting Started with AI-Powered Development","content_html":"The way we write software is changing. AI coding agents like Claude Code,\nCursor, and GitHub Copilot have moved beyond simple autocomplete into tools that\ncan read your codebase, run commands, and implement features alongside you. If\nyou've been curious about integrating AI into your development workflow but\naren't sure where to begin, this guide will help you take those first steps.
\n\nBefore we dive in, let's clarify what makes these tools different from the\nchatbots you might have used before. A traditional AI chat can answer questions\nabout code and generate snippets you copy-paste into your editor. An agentic\ncoding tool goes further — it can browse your project files, execute terminal\ncommands, create and edit files, and reason across your entire codebase to\nimplement changes autonomously.
\nThree major players right now are:
\nGetting started is surprisingly straightforward. Each tool has its own setup\nflow, but the general pattern is similar: install the tool, authenticate, and\nlet it analyze your project.
\nClaude Code runs in your terminal. After installing it, you simply navigate to\nyour project directory and run the claude command. The first time you do this,\nit opens your browser for authentication — no need to manually manage API keys.\nOnce authenticated, run /init and the agent will crawl your project, identify\nyour tech stack from marker files like package.json or deno.json, and\ngenerate a CLAUDE.md file that serves as its persistent memory about your\nproject.
Cursor is a standalone IDE. After installation, you can open your project and\naccess Agent Mode through the Composer interface. To get the most out of it,\nactivate Plan Mode (Shift+Tab) which forces the agent to research your\ncodebase and present an implementation plan before making changes. Configuration\nlives in .cursor/rules/ as .mdc files where you can scope rules to specific\nfile patterns.
If you're already using VS Code, Copilot integrates directly into your editor.\nThe /init command generates a .github/copilot-instructions.md file for your\nrepository. On GitHub.com, you can assign issues directly to Copilot, and it\nwill create pull requests for you to review — great for routine tasks like\ndocumentation updates or minor fixes.
Here's where things get interesting. The single most impactful thing you can do\nto improve your AI coding experience is to maintain good instruction files.\nThese are markdown files that tell the agent how your project works.
\nThink of it this way: when a new developer joins your team, they need to learn\nthe build commands, the coding conventions, the project structure, and the\nworkflow rules. An AI agent needs the same onboarding, and instruction files are\nhow you provide it.
\n| Tool | \nPrimary File | \nPurpose | \n
|---|---|---|
| Claude Code | \nCLAUDE.md | \nProject memory, loaded at every session start | \n
| Cursor | \n.cursor/rules/*.mdc | \nScoped rules with glob pattern matching | \n
| GitHub Copilot | \n.github/copilot-instructions.md | \nRepository-wide AI guidance | \n
| Cross-tool | \nAGENTS.md | \nUniversal standard for any agentic tool | \n
A good instruction file should include:
\nKeep it concise. The agent reads this file every session, and a bloated\ninstruction file wastes the agent's context window — the limited memory it has\navailable for each conversation.
\nLet's walk through a practical workflow. Say you want to add a new feature to\nyour project.
\nDescribe what you want. Be specific. Instead of "add authentication," try\n"add a login endpoint using JWT tokens that validates against the users\ntable." The more precise your prompt, the better the result.
\nLet the agent plan. In Cursor, use Plan Mode. In Claude Code, describe\nthe feature and ask it to outline an approach before implementing. Review the\nplan — does it match your expectations? Are the right files being modified?
\nWatch and redirect. As the agent works, keep an eye on the changes. If it\nstarts heading in the wrong direction, interrupt and correct course. You're\nthe architect; the agent is the builder.
\nVerify the result. Run your tests. Review the diffs. Don't blindly trust\nthe output — treat it like a pull request from a junior developer who writes\ndecent code but occasionally misses edge cases.
\nAs you start incorporating AI agents into your workflow, watch out for these\ncommon traps:
\nOver-trusting the output. AI-generated code can look perfectly reasonable\nwhile being subtly wrong. Always review diffs and run your test suite. The agent\nis a powerful assistant, not an infallible oracle.
\nVague prompts. "Make it better" or "fix the bugs" gives the agent very\nlittle to work with. Specific, contextual prompts produce dramatically better\nresults. Reference specific files, error messages, or behaviors you want to\nchange.
\nIgnoring the context window. Every message, file read, and command output\nconsumes space in the agent's working memory. In long sessions, the agent may\nstart "forgetting" earlier instructions. Use features like /compact in Claude\nCode to compress the conversation, or start a fresh session for new tasks.
Skipping the instruction file. Many developers install the tool and start\nprompting without setting up a CLAUDE.md or equivalent. This is like\nonboarding a new team member without telling them anything about the project.\nSpend the time upfront — it pays for itself immediately.
Working effectively with AI coding agents requires a subtle shift in how you\nthink about development. You're moving from writing every line yourself to\ndirecting behavior. This means thinking at a higher level — about\narchitecture, requirements, and constraints — while delegating the\nimplementation details.
\nThis doesn't mean you stop understanding the code. Quite the opposite. You need\nto understand it well enough to review what the agent produces, catch mistakes,\nand steer it in the right direction. The developers who get the most out of\nthese tools are the ones who combine strong fundamentals with clear\ncommunication.
\nOnce you're comfortable with the basics, there's a lot more to explore:
\nThe landscape of AI-assisted development is evolving rapidly, but the\nfundamentals stay the same: give the agent clear context, review its work\ncarefully, and think of it as a capable collaborator rather than a magic\nsolution. Start small, build confidence, and gradually expand how you use these\ntools in your daily workflow.
\nHappy coding with your new AI partner!
\n","date_published":"Tue, 17 Feb 2026 00:00:00 GMT"},{"id":"https://posts.pinta.land/posts/boxframe-intro/","url":"https://posts.pinta.land/posts/boxframe-intro/","title":"BoxFrame - DataFrames for JavaScript with WebAssembly Options","content_html":"Ready to work with structured data in JavaScript but tired of the limitations of\nbasic arrays and objects? BoxFrame brings DataFrames to JavaScript/TypeScript,\nwith WebAssembly acceleration for improved performance.\nThis implementation provides a\npandas-inspired API that works across all JavaScript environments.
\n\nBoxFrame is a DataFrame library for JavaScript/TypeScript, built with\nWebAssembly (WASM) compiled from Rust. It provides an intuitive API for data\nmanipulation, analysis, and processing that works across different JavaScript\nenvironments - from browsers to Node.js to Deno.
\nInspired by Python's pandas library, BoxFrame brings structured data\nmanipulation to the JavaScript ecosystem with native performance.
\nBoxFrame is a DataFrame implementation for JavaScript. The library uses\nWebAssembly compiled from Rust for core operations, which provides better\nperformance than pure JavaScript implementations. When WebAssembly is not\navailable, it automatically falls back to pure JavaScript implementations. It\nworks in multiple JavaScript environments including Deno, Node.js, Bun, and\nbrowsers.
\nThe library automatically infers data types and supports int32, float64,\nstrings, booleans, and dates. It provides a fluent API with method chaining for\ndata transformations, along with operations like GroupBy, aggregation,\nfiltering, and sorting. Data can be imported from CSV files, JSON, and Google\nSheets.
\n# For Deno\ndeno add jsr:@pinta365/boxframe\n\n# For Node.js\nnpx jsr add @pinta365/boxframe\n\n# For Bun\nbunx jsr add @pinta365/boxframe\n\n# For browsers (ESM)\nimport { DataFrame } from "https://esm.sh/jsr/@pinta365/boxframe@0.0.1";\nimport { DataFrame } from "@pinta365/boxframe";\n\n// Create a DataFrame from an object\nconst sales = new DataFrame({\n product: ["Laptop", "Phone", "Tablet", "Laptop", "Phone"],\n price: [999, 699, 399, 1099, 799],\n region: ["North", "South", "North", "South", "West"],\n quantity: [5, 12, 8, 5, 15],\n});\n\nconsole.log(sales.toString());\n// Find best selling products by region\nconst topProducts = sales\n .groupBy("region")\n .agg({\n price: "mean",\n quantity: "sum",\n })\n .sortValues("quantity_sum", false);\n\nconsole.log(topProducts.toString());\n/*\nDataFrame\nshape: [3, 2]\n\n price_mean quantity_sum\nSouth 899 17\nWest 799 15\nNorth 699 13\n*/\nBoxFrame's fluent API makes complex data transformations readable:
\nconst result = sales\n .query("price > 700") // Filter expensive items\n .groupBy("region") // Group by region\n .agg({ quantity: "sum" }) // Sum quantities\n .sortValues("quantity_sum", false) // Sort by total quantity\n .head(2); // Get top 2 regions\n\nconsole.log(result);\nRead data from various sources:
\n// Read CSV file\nconst df = await BoxFrame.readCsv("data.csv");\n\n// Parse CSV content\nconst df2 = BoxFrame.parseCsv("name,age\\nAlice,25\\nBob,30");\n\n// Read from Google Sheets\nconst df3 = await BoxFrame.readGoogleSheet("your-sheet-id");\n\n// Create from array of objects\nconst df4 = BoxFrame.fromObjects([\n { name: "Alice", age: 25, city: "New York" },\n { name: "Bob", age: 30, city: "London" },\n]);\nBoxFrame automatically uses WebAssembly for performance-critical operations:
\n// Check if WASM engine is enabled\nconsole.log(BoxFrame.isWasmEngineEnabled()); // true\n\nconst largeData = new DataFrame({\n values: Array.from({ length: 100000 }, () => Math.random()),\n});\n\n// This operation uses WASM for better performance\nconst sorted = largeData.sortValues("values");\nExperience BoxFrame in your browser:\nJSFiddle Demo
\nThe demo showcases:
\nBoxFrame works everywhere Modern JavaScript runs:
\n<script type="module">\n import { DataFrame } from "https://esm.sh/jsr/@pinta365/boxframe@0.0.1";\n // Use DataFrame in your browser app\n</script>\nimport { DataFrame } from "@pinta365/boxframe";\n// Full Node.js support with file system operations\nimport { DataFrame } from "@pinta365/boxframe";\n// Native Deno support with modern JavaScript features\nBoxFrame makes data analysis accessible in JavaScript. Whether you're building\ndata visualization tools, analytics dashboards, or processing large datasets,\nBoxFrame provides the tools you need.
\nReady to get started? Check out the\ncomplete documentation with API reference,\nexamples, and guides.
\nYou can find the library source code on\nGitHub and install it from\nJSR.
\nLet us know if you have any questions or feedback!
\n","date_published":"Sun, 26 Oct 2025 00:00:00 GMT"},{"id":"https://posts.pinta.land/posts/oura-sandbox/","url":"https://posts.pinta.land/posts/oura-sandbox/","title":"Oura API Sandbox - Develop Without an Oura Account","content_html":"Ready to build applications with Oura Ring data but don't have an Oura account\nor access token? No problem! The Oura API now includes a sandbox environment,\nallowing you to develop and test your integrations without needing real user\ndata. This implementation got support\nfor accessing the sandbox routes.
\n\nThe Oura API sandbox is a simulated environment that provides you with sample\nOura Ring data. This lets you experiment with the API, build prototypes, and\nthoroughly test your application's logic before going live. All this without\nneeding an Oura user account or access token.
\nTo access the Oura sandbox with\n@pinta365/oura-api is as simple as\ncreating a new Oura client with the useSandbox option set to true:
# For Deno\ndeno add @pinta365/oura-api\n\n# For Bun\nbunx jsr add @pinta365/oura-api\n\n# For Node.js\nnpx jsr add @pinta365/oura-api\nimport { Oura } from "@pinta365/oura-api";\n\nconst sandboxClient = new Oura({ useSandbox: true });\nThat's it! You can now start making API calls using the sandboxClient object,\njust like you would with a regular client. Explore the\nJSR documentation for possible\nmethods.
Example:
\ntry {\n const dailyActivityData = await sandboxClient.getDailyActivityDocuments(\n "2024-01-01",\n "2024-01-10",\n );\n console.log(dailyActivityData);\n} catch (error) {\n console.error("Error fetching data:", error);\n}\nImportant Note:
\nThe Oura API library with its sandbox environment makes Oura Ring data\nintegration accessible to everyone. Start experimenting, testing, and building\nyour next great application today!
\nYou can also try the sandbox in the browser via this simple\nDeno playground.
\nYou can find the library source code on\nGitHub.
\nLet us know if you have any questions or feedback!
\n","date_published":"Mon, 05 Aug 2024 00:00:00 GMT"},{"id":"https://posts.pinta.land/posts/js-freeze-seal-object/","url":"https://posts.pinta.land/posts/js-freeze-seal-object/","title":"Freezing or Sealing? Understanding JavaScript Object Immutability","content_html":"JavaScript, like many dynamic languages, offers flexibility in how you handle\nobjects. But sometimes, you need to ensure certain objects remain unchanged.\nThat's where Object.freeze() and Object.seal() come into play. They're your\ntools for creating immutable or partially immutable objects, respectively. Let's\ndive in!
In programming, immutability means an object's state cannot be changed after\nit's created. This can help prevent accidental modifications and make your code\nmore predictable. JavaScript provides a few ways to achieve this, with\nfreeze() and seal() being two prominent methods.
Object.freeze() takes your object and encases it in an unbreakable shell.\nHere's what happens:
Example: Frozen Settings
\nconst appConfig = Object.freeze({\n theme: "dark",\n version: "1.0.0",\n maxItems: 100,\n});\n\nappConfig.theme = "light"; // Fails silently\nappConfig.language = "en"; // Fails silently\ndelete appConfig.version; // Fails silently\nHere, appConfig is like a locked-down configuration file. Even trying to\nchange its properties directly has no effect.
Object.seal() offers a slightly less restrictive form of immutability. Here's\nhow it differs from freeze():
freeze(), you cannot add new properties.Example: Modifiable Data Record
\nconst userProfile = Object.seal({\n name: "Alice",\n email: "alice@example.com",\n isAdmin: false,\n});\n\nuserProfile.email = "newalice@example.com"; // Succeeds\nuserProfile.age = 30; // Fails silently\ndelete userProfile.isAdmin; // Fails silently\nHere, userProfile is like a sealed record where you can update the information\nbut not add new fields or remove existing ones.
freeze() or seal()?Object.freeze(): Use when you need absolute immutability for values that\nshould never change under any circumstances. Think of configuration settings,\nmathematical constants, or any data you want to protect from accidental\nmodifications.
Object.seal(): Use when you want a fixed structure for your object but\nneed the flexibility to update the values of existing properties. This is\nsuitable for data records, entities, or objects where the shape is fixed, but\nthe data it holds might evolve over time.
Shallow vs. Deep Immutability: Both freeze() and seal() provide\nshallow immutability. If your object has nested objects or arrays, those\nnested structures are not automatically made immutable. You'd need to\nrecursively apply freeze() or seal() to achieve deep immutability.
Object.isFrozen() and Object.isSealed(): You can use these functions to\ncheck if an object has been frozen or sealed.
\nObject.isFrozen(appConfig); // true\nObject.isSealed(userProfile); // true\nImmutability is a powerful concept in JavaScript, and Object.freeze() and\nObject.seal() are valuable tools to help you enforce it. Choose the right one\nbased on your specific needs, and remember to handle nested structures for deep\nimmutability. By embracing immutability, you can make your code more robust,\npredictable, and easier to reason about.
Unlock the power of your Oura Ring data with our streamlined Oura API library!\nSeamlessly integrate sleep, activity, and readiness insights into your\napplications, whether you're building on Deno, Bun, or Node.js.\nOur library handles the requests to the\nOura API, so you can focus on creating meaningful experiences.
\n\nThe Oura API Library is a cross-platform solution designed to make Oura Ring\ndata integration a breeze. Source code available at\nGitHub.
\nKey Features
\n# For Deno\ndeno add @pinta365/oura-api\n\n# For Bun\nbunx jsr add @pinta365/oura-api\n\n# For Node.js\nnpx jsr add @pinta365/oura-api\nimport { Oura } from "@pinta365/oura-api";\n\nconst accessToken = "YOUR_ACCESS_TOKEN";\nconst ouraClient = new Oura(accessToken); // Or use options object for sandbox\n\ntry {\n const dailyActivityData = await ouraClient.getDailyActivityDocuments(\n "2023-01-01",\n "2023-01-10",\n );\n console.log(dailyActivityData);\n} catch (error) {\n console.error("Error fetching data:", error);\n}\nYou can use the sandbox without user account or access token, perfect for\ndevelopment and testing.
\nconst ouraSandboxClient = new Oura({ useSandbox: true }); // No access token needed for sandbox\nYou can try the sandbox in the browser via this simple\nDeno playground.
\nNote: Not all Oura API endpoints are available in the sandbox environment.\nRefer to the Oura documentation for details.
\nSee documentation for more examples and explainations
\nComplete library documentation and examples can be found at the\nJSR documentation page.
\nStart building amazing applications with Oura Ring data. We can't wait to see\nwhat you create!
\n\nLet us know if you have any questions or need further assistance!
\n","date_published":"Fri, 10 May 2024 00:00:00 GMT"},{"id":"https://posts.pinta.land/posts/cross-jwt/","url":"https://posts.pinta.land/posts/cross-jwt/","title":"Secure Data Exchange with JWTs and the @cross/jwt Library","content_html":"JSON Web Tokens (JWTs) provide a secure and standardized way to transmit\ninformation between parties. They are widely used for authentication, but their\nability to carry arbitrary data makes them valuable for a variety of secure data\nexchange scenarios. If you work with Deno, Bun, or Node.js, managing JWT\nworkflows across these different runtimes can introduce inconsistencies and\npotential security risks. Lets take a look at\nthis runtime agnostic library to enable one\ndependency across all major runtimes.
\n\nIntroducing @cross/jwt, a cross-platform JWT library designed to bring secure,\nconsistent, and easy-to-use JWT handling to your projects. Source code available\nat GitHub.
Key Features for Robust Security
\n@cross/jwt supports a range of industry-standard\nsigning algorithms, including HMAC, RSA, RSA-PSS, and ECDSA, ensuring the\nintegrity and authenticity of your tokens.@cross/jwt provides the same\nrobust functionality everywhere.JWTOptions.# For Deno\ndeno add @cross/jwt\n\n# For Bun\nbunx jsr add @cross/jwt\n\n# For Node.js\nnpx jsr add @cross/jwt\nSee detailed documentation on https://jsr.io\nfor the complete API, but here's a quick look with a simple HMAC Example:
\nimport { signJWT, validateJWT } from "@cross/jwt";\n\n// A base64-encoded secret.\nconst secret = "y69uNvF9lbHE2disEqeYCBYOUmzJvr75txhxbUL5W0k=";\n// Generate and sign the JWT.\nconst token = await signJWT({ userId: 123 }, secret);\n// Verify and validate it.\nconst data = await validateJWT(token, secret);\nimport { Application } from "jsr:@oak/oak/application";\nimport { signJWT, validateJWT } from "@cross/jwt";\nimport type { JWTPayload } from "@cross/jwt";\n\nconst app = new Application();\n// Replace with a secure secret\nconst secret = "y69uNvF9lbHE2disEqeYCBYOUmzJvr75txhxbUL5W0k=";\n\n// ... Your routes and other logic ...\n1. Login Route
\napp.use(async (ctx, next) => {\n if (ctx.request.url.pathname === '/login' && ctx.request.method === 'POST') {\n // ... your login validation logic ...\n \n const payload: JWTPayload = {\n userId: 123, \n role: "user" \n };\n const jwt = await signJWT(payload, secret);\n ctx.response.body = { token: jwt };\n } else {\n await next();\n }\n});\n2. Authentication Middleware
\nconst authMiddleware = async (ctx: any, next: any) => {\n const authHeader = ctx.request.headers.get('Authorization');\n if (!authHeader) {\n ctx.response.status = 401; // Unauthorized\n return; \n }\n\n const token = authHeader.split(' ')[1]; // Assuming 'Bearer token' format\n try {\n const payload = await validateJWT(token, secret) as JWTPayload; \n\n // Attach user data to the context for downstream routes/logic\n ctx.state.user = { \n id: payload.userId,\n role: payload.role\n }; \n\n await next();\n } catch (error) {\n ctx.response.status = 401; // Unauthorized\n }\n};\n3. Protected Route
\napp.use(authMiddleware);\n\napp.use((ctx) => {\n if (ctx.request.url.pathname === "/protected") {\n // Access user info\n const userId = ctx.state.user.id;\n const userRole = ctx.state.user.role;\n\n // ... logic using the authenticated user data ...\n }\n});\n\nconsole.log("Server running on port 8000");\nawait app.listen({ port: 8000 });\nExplanation
\nauthMiddleware now require a valid\nJWT to access.Important Notes:
\n![\"An](\"https://posts.pinta.land/images/jsgenerators.webp\" "\\"Programmer\\"")
\nIn the world of JavaScript, functions are our workhorses. They take input,\nperform some magic, and (usually) return an output. But what if you need a\nfunction to pause execution mid-way, and then pick up right where it left off,\npotentially multiple times? That's where generators step in.
*).return keyword, they use yield to pause execution and\nreturn a value.next() method is called, it resumes from where it\nleft off, until it's finished.Efficiently Handling Large or On-Demand Data: Generators excel at\nhandling infinitely generated sequences or processing data in chunks without\nneeding to store entire datasets in memory. This is perfect for scenarios\nwith massive files, real-time data streams, or computationally intensive\nvalue generation.
\nResource Management and Control: Unlike regular functions, generators\nenable fine-grained control over when computations happen and when resources\nare released. This can help optimize pipelines where you need to manage\nintermediate results without sacrificing memory efficiency.
\nCleaner Iterations in Special Cases: While generators are iterable, their\ntrue power lies in custom iterators where you want logic inside the iteration\nitself, rather than iterating over a pre-existing collection. This is\nparticularly useful for building recursive structures or complex sequences.
\nCreating Coroutines (Advanced): Generators provide a foundation for\nimplementing coroutines. Coroutines are like functions that can pause, yield\ncontrol to each other, and resume seamlessly. This enables cooperative\nmultitasking – switching between tasks without the complexity of full-blown\nthreads.
\nfunction* numberGenerator() {\n yield 1;\n yield 2;\n yield 3;\n}\n\nconst generator = numberGenerator();\n\nconsole.log(generator.next().value); // Output: 1\nconsole.log(generator.next().value); // Output: 2\nconsole.log(generator.next().value); // Output: 3\nconsole.log(generator.next().value); // Output: undefined (generator is done)\nImagine fetching posts from a social media API. Instead of trying to load all\nthe posts at once, a generator could:
\nyield them.yield those.If you've grasped the basics of JavaScript generators (if not, consider\nrevisiting the idea of yield and next()), it's time to level up! In this\npost, we'll explore how generators can supercharge your programming with\nadvanced patterns:
yieldyield doesn't only output values. You can send values back\ninto a running generator using generator.next(value).Example:
\nfunction* questionGenerator() {\n const name = yield "What's your name?";\n const quest = yield `Hi ${name}, what is your quest?`;\n yield `To seek the ${quest}!`;\n}\n\nconst generator = questionGenerator();\n\nconsole.log(generator.next().value); // "What's your name?"\nconsole.log(generator.next("Arthur").value); // "Hi Arthur, what is your quest?"\nconsole.log(generator.next("Holy Grail").value); // "To seek the Holy Grail!"\nyield*yield* lets you delegate control to another generator (or iterable).Example:
\nfunction* numberGenerator() {\n yield 1;\n yield 2;\n}\n\nfunction* alphabetGenerator() {\n yield "a";\n yield "b";\n}\n\nfunction* combinedGenerator() {\n yield* numberGenerator();\n yield* alphabetGenerator();\n}\n\nfor (const value of combinedGenerator()) {\n console.log(value); // Output: 1, 2, 'a', 'b'\n}\nGenerators offer flexibility when it comes to error handling. You can use both\ntraditional try...catch blocks and carefully control error propagation using\nyield and generator.throw():
A. Inside the Generator: try...catch
try...catch block just as you\nwould in regular functions.function* riskyGenerator() {\n try {\n const someData = yield fetchData(); // Assume fetchData() could throw an error\n // Proceed with more logic if no error\n } catch (error) {\n yield `An error occurred: ${error.message}`;\n }\n}\nB. Outside the Generator: generator.throw()
generator.throw(error).yield\ninside the generator.const generator = riskyGenerator();\nlet result = generator.next();\n\nif (!result.value.isValid()) {\n generator.throw(new Error("Invalid data received"));\n}\nC. Choosing Between yield and throw
Illustrative Example:
\nfunction* processFile(filename) {\n // ... file opening and setup ...\n try {\n for await (const line of file) {\n if (isInvalidLine(line)) {\n yield { error: "Invalid Line", lineNumber };\n } else {\n yield processValidLine(line);\n }\n }\n } catch (error) {\n generator.throw(new Error(`Critical file error: ${error.message}`));\n }\n}\nExplanation: The example above uses a mix:
\nyield-ed, allowing the caller to filter/log\nthem while proceeding.throw-n, as the\ngenerator cannot continue.Generators give you fine-grained control over how your code responds to errors.\nChoose the technique that aligns with the desired error handling strategy for\nyour specific use case.
\nasync and await provide a beautifully clear way to work with promises and\ngenerators:
async Functions: When you mark a function as async, it automatically\nreturns a promise. Inside an async function, you can use the await\nkeyword.await Magic: The await keyword pauses the execution of the async\nfunction until a promise resolves. It then unwraps the resolved value and\nlets your code continue as if it were dealing with synchronous code.Example: Fetching API Data
\nLet's see how this works with a simplified API fetching example:
\nasync function* fetchPostsPage(pageNumber) {\n const response = await fetch(\n `https://api.example.com/posts?page=${pageNumber}`,\n );\n const data = await response.json();\n yield data;\n}\n\nasync function displayPosts() {\n let currentPage = 1;\n\n while (true) {\n const generator = fetchPostsPage(currentPage);\n const result = await generator.next();\n const posts = result.value;\n\n if (posts.length === 0) {\n // No more posts\n break;\n }\n\n // Process and display the fetched posts\n for (const post of posts) {\n // ... display post logic here ...\n }\n\n currentPage++;\n }\n}\nNotice how the code within displayPosts reads almost like synchronous code,\neven though it's dealing with asynchronous operations under the hood!
Error Handling
\nError handling within async functions and generators works smoothly with\ntry...catch blocks:
async function* riskyDataFetch() {\n try {\n const response = await fetch("https://nonexistent-api.example.com/data"); // Forced error\n const data = await response.json();\n yield data;\n } catch (error) {\n yield error;\n }\n}\n\nasync function handleFetch() {\n const generator = riskyDataFetch();\n const result = await generator.next();\n\n if (result.done) {\n console.error("An error occurred:", result.value);\n } else {\n console.log("Data:", result.value);\n }\n}\n![\"An](\"https://posts.pinta.land/images/debugdilemma.webp\" "\\"Programmer\\"")
\nProgramming is often portrayed as a gateway to creating incredible software,\napps, and technology that can change the world. Many beginners embark on their\ncoding journey with stars in their eyes, fueled by enthusiasm and a\ndetermination to unlock the secrets of the digital universe. However, amidst the\nexcitement and anticipation, there's an often overlooked reality: debugging.
Debugging is the process of finding and fixing errors or "bugs" in your code.\nIt's an essential skill for any programmer, akin to a detective unraveling a\ncomplex mystery. While the promise of bringing your ideas to life through code\nis exhilarating, the path to programming proficiency is not always smooth. In\nfact, it's riddled with frustrating debugging challenges that can test the\nmettle of even the most ardent beginners.
\nIn this article, we'll dive into the debugging dilemma, exploring why so many\naspiring programmers give up when faced with real code debugging. We'll dissect\nthe initial excitement of learning to code, the harsh reality of debugging, the\nlearning plateau, and the common reasons why some learners throw in the towel.\nBut fear not, for we'll also offer strategies to overcome these challenges and\nencourage resilience in your coding journey.
\nSo, let's journey through the highs and lows of programming, the thrill of\ncreation, and the vexing world of debugging—a true rite of passage for aspiring\ncoders.
\nThe initial stages of learning programming are akin to setting out on a grand\nadventure. Armed with a fresh IDE (Integrated Development Environment), a slew\nof online tutorials, and boundless curiosity, beginners often feel invincible.\nIt's the era of "Hello World!" programs, where the smallest snippet of code can\nproduce a sense of accomplishment that's hard to describe.
\nThe allure of programming lies in its creative potential. The ability to\ntranslate ideas into lines of code that can perform tasks, solve problems, and\nentertain is a powerful draw. Many newcomers are thrilled at the prospect of\nbuilding websites, mobile apps, games, or automating everyday tasks.
\nIn these early stages, the world of programming seems full of promise,\nexcitement, and endless opportunities. The euphoria of writing your first lines\nof code and seeing them execute successfully is intoxicating. It's like having\nthe keys to a digital kingdom, where you're the master builder and architect of\nyour creations.
\nDebugging, in essence, is the process of hunting down and exterminating\nbugs—those elusive errors and glitches that lurk within your code, causing it to\nmisbehave or crash. Debugging can be an arduous task, often resembling a puzzle\nwith missing pieces or a maze with unforeseen dead ends.
\nAs beginners transition from simple "Hello World!" programs to more complex\nprojects, they quickly discover that coding isn't just about writing\ninstructions for a computer to follow. It's also about deciphering cryptic error\nmessages, identifying logical flaws, and patiently tracing the execution flow of\ntheir programs.
\nCommon debugging scenarios include:
\nSyntax Errors: These errors occur when your code violates the rules of\nthe programming language. They often manifest as red squiggly lines and\ncryptic error messages that leave beginners scratching their heads.
\nLogic Bugs: Logic bugs are the trickiest, as they involve flawed\nreasoning in your code. Programs may run without errors, but they produce\nincorrect results due to logical errors.
\nRuntime Errors: These occur when a program is running and encounters\nissues. They can lead to crashes, unhandled exceptions, or unexpected\nbehavior.
\nThe frustration that accompanies debugging can be overwhelming. It's not\nuncommon to spend hours hunting for a single misplaced semicolon or an elusive\nmissing parenthesis. For many beginners, this is the first major test of their\npatience and problem-solving skills.
\nThe learning plateau is a phase in the programming journey where initial\nexcitement gives way to a sense of stagnation. It's a period when the\ncomplexities of programming become more apparent, and progress seems to slow\ndown or even come to a halt.
\nDuring this phase, learners may begin to doubt their abilities and question\nwhether they have what it takes to become proficient programmers. The initial\nthrill of coding can fade as they grapple with increasingly complex projects and\ndebugging challenges. It's a crucial turning point where many aspiring\nprogrammers face a make-or-break decision.
\nIn reality, the learning plateau is a natural part of the programming journey.\nIt's the point where the initial burst of enthusiasm needs to be supplemented\nwith perseverance and a willingness to confront debugging head-on. It's where\nthe distinction between those who persevere and those who give up often becomes\nclear.
\nUnfortunately, not all beginners make it past the learning plateau. There are\nseveral common reasons why some aspiring programmers throw in the towel.
\nLack of Patience: Debugging can be a time-consuming process that demands\npatience. Some beginners become frustrated when they can't immediately solve\na problem, leading to a loss of interest.
\nImposter Syndrome: Many learners experience imposter syndrome, a feeling\nof not being "good enough" compared to more experienced developers. This\nself-doubt can erode confidence and motivation.
\nOverwhelm: The vast landscape of programming languages, libraries, and\nframeworks can be overwhelming, especially for beginners. It's easy to feel\nlost in the sea of options and information.
\nUnrealistic Expectations: Some newcomers enter the world of programming\nwith unrealistic expectations, thinking they can master it overnight. When\nthey realize the depth of the subject, they may become disheartened.
\nThese reasons, individually or in combination, can lead to a sense of defeat.\nBut the truth is, they are all challenges that can be overcome with the right\nmindset and strategies.
\nWhile the debugging dilemma is real, it's important to know that it's not an\ninsurmountable obstacle. There are strategies and approaches that can help\naspiring programmers overcome these challenges and stay on the path to coding\nproficiency.
\nSeek Help: Don't hesitate to reach out for assistance when you're stuck.\nOnline communities, forums, and programming mentors can provide valuable\nguidance and solutions.
\nBreak It Down: Divide complex problems into smaller, more manageable\nparts. This makes debugging less daunting and allows you to tackle one issue\nat a time.
\nEmbrace Failure: Understand that making mistakes and encountering bugs is\nan inherent part of programming. Every bug you conquer is a lesson learned.
\nContinuous Learning: Programming is a lifelong journey. Stay curious and\ncommitted to learning, and don't be discouraged by temporary setbacks.
\nMentorship: Consider finding a mentor who can offer guidance, share\nexperiences, and provide insights into effective debugging techniques.
\nBy adopting these strategies and fostering a mindset of perseverance, you can\nnavigate the debugging dilemma with greater confidence and resilience.
\nIn this exploration of the debugging dilemma and the challenges faced by\nbeginners in the world of programming, it's important to recognize that the road\nto coding proficiency is rarely a straight line. It's more like a winding path\nwith obstacles, detours, and occasional setbacks. However, it's precisely these\nchallenges that can shape you into a skilled and resilient programmer.
\nAs you've learned, the initial excitement of coding often gives way to the\nreality of debugging—a process that can test your patience and problem-solving\nabilities. The learning plateau can be disheartening, and common hurdles like\nfrustration, imposter syndrome, overwhelm, and unrealistic expectations can make\nyou question your journey.
\nBut here's the good news: every programmer, from the beginners to the seasoned\nexperts, has faced these challenges at some point. What sets successful\nprogrammers apart is their ability to persist in the face of adversity. They\nunderstand that debugging is not a sign of incompetence; it's a badge of honor\nearned through trial and error.
\nEmbrace the Process: Debugging is not a sign of failure; it's a crucial\npart of the coding process. Each bug you conquer is a step forward in your\nprogramming journey.
\nLearn from Mistakes: Every error, every setback, and every frustrating\nbug is an opportunity to learn and grow as a programmer. Take the lessons\nfrom each experience and apply them to future projects.
\nSeek Support: Don't hesitate to seek help when you're stuck. Join\nprogramming communities, connect with peers, and consider finding a mentor\nwho can guide you through the challenges.
\nStay Curious: Programming is a field that's constantly evolving. Maintain\nyour curiosity and explore new technologies, languages, and frameworks.\nThere's always something new to discover.
\nPersevere: The path to becoming a proficient programmer may have its ups\nand downs, but it's the determination to persevere that ultimately leads to\nsuccess.
\nRemember, the debugging dilemma is not unique to you; it's a shared experience\namong programmers worldwide. In fact, it's these very challenges that make the\ncoding journey so rewarding. The satisfaction of solving a complex problem,\nfixing a stubborn bug, or creating a functional piece of software is\nimmeasurable.
\nSo, if you're a beginner feeling frustrated by debugging, know that you're not\nalone. Keep pushing forward, keep learning, and keep coding. The programming\nworld is waiting for your unique contributions and innovations, and the\ndebugging challenges you overcome today will be the stepping stones to your\nsuccess tomorrow.
\nIn the grand tapestry of programming, each bug fixed and each problem solved\nadds to your expertise and shapes you into a resilient and capable coder.\nEmbrace the debugging dilemma, for it's an integral part of your journey to\nbecoming a proficient programmer.
\nHappy coding, and may your debugging adventures be both challenging and\nrewarding!
\nBefore we conclude, here are some additional tips and parting thoughts to carry\nwith you on your programming journey:
\nCelebrate Your Wins: Whether it's fixing a bug, completing a project, or\nlearning a new concept, take a moment to celebrate your achievements, no\nmatter how small they may seem.
\nStay Curious: The world of programming is vast and ever-changing.\nMaintain your curiosity and explore new technologies, languages, and\nframeworks. There's always something new to discover.
\nBuild Projects: Practical application is one of the most effective ways\nto learn. Create personal projects that challenge and inspire you. These\nprojects not only reinforce your skills but also serve as a portfolio to\nshowcase your abilities.
\nShare Your Knowledge: As you progress in your programming journey,\nconsider giving back to the community. Share your experiences, write\ntutorials, and help fellow learners. Teaching others is a powerful way to\nsolidify your understanding.
\nTake Breaks: Programming can be mentally taxing. Don't forget to take\nregular breaks to recharge your mind and prevent burnout. A fresh perspective\noften leads to better problem-solving.
\nNetwork and Collaborate: Building connections in the programming\ncommunity can open doors to new opportunities. Collaborate with others on\nprojects, attend meetups or conferences, and participate in open-source\ninitiatives.
\nKeep Learning: Learning in programming is a continuous process. Stay\nupdated with industry trends, take online courses, and consider pursuing\nadvanced studies or certifications when you're ready.
\nIn conclusion, the debugging dilemma is not a barrier to your programming\nsuccess; it's a rite of passage. As you navigate the highs and lows of this\njourney, remember that every challenge you face is an opportunity for growth.\nEmbrace the debugging process, stay persistent, and let your passion for coding\ndrive you forward.
\nThe world of technology and programming is waiting for your contributions,\ninnovations, and solutions. Keep coding, keep learning, and never lose sight of\nyour programming goals.
\n","date_published":"Sat, 09 Sep 2023 00:00:00 GMT"}]}