标签：#JavaScript

GitHub热门项目 | یک پنل گرافیکی کاربردی برای ارائه اشتراک‌های Worker با پروکسی‌های ، Trojan و Warp به همراه زنجیره پروکسی، ارائه دهنده تنظیمات کامل DNS، IP تمیز و روتینگ پیشرفته برای کاربران تمامی پلتفرم‌ها با استفاده از هسته‌های Amnezia، Wireguard، Sing-box، Clash/Mihomo و Xray. | Stars: 3,039 | 24 stars today | 语言: JavaScript

Disclosure: I build Receiptful, the printing API used in this tutorial. The Node and Express parts apply whatever you print with. You have orders coming into your point of sale, and you want each one to print on the thermal printer at the counter. This is a complete walkthrough of a small Node service that does exactly that. By the end you will have an endpoint you can POST an order to and watch paper come out. There is nothing to install next to the printer for this tutorial to work, and no ESC/POS to write by hand. You send HTML, Receiptful prints it. Before you start You need two things from the console : A paired printer, which gives you a printer ID . If you have not done this yet, the getting started guide walks through it in a couple of minutes. An API key (the rf_live_… value), created under API keys and shown only once. On the code side you need Node 18 or newer, so that fetch is available globally with no extra dependency. We will use TypeScript, but the same code works in plain JavaScript if you drop the types. Put your credentials in the environment rather than in the source: export RECEIPTFUL_API_KEY = "rf_live_3f9c…" export RECEIPTFUL_PRINTER_ID = "42" Step 1: model the order Start with the shape of an order. Yours will have more fields, but this is enough to print a useful receipt: interface LineItem { name : string ; quantity : number ; unitPrice : number ; // in cents, to avoid float rounding } interface Order { id : number ; items : LineItem []; placedAt : Date ; } Keeping money in cents and formatting only at the edges saves you from the classic floating point rounding bugs that show up as a receipt total that is one cent off. Step 2: render the order as HTML This is the part that decides how the receipt looks. Receiptful converts the HTML you send into ESC/POS for your specific printer, so you get to lay a receipt out with tags you already know instead of byte codes. function money ( cents : number ): string { return " $ " + ( cents / 100 ). toFi

A game wallet often starts as a single balance field. That is fine for a prototype, but payment retries and unreliable networks quickly make the number hard to trust. A player can tap “buy,” lose the connection, and try again. A store callback can arrive more than once. Two devices can spend the same account at nearly the same time. The fix is to treat the balance as a cached view of a ledger. Record every change Instead of silently changing a balance, record events such as: a verified payment granting virtual currency; an item purchase spending currency; a refund creating a compensating entry; an administrative adjustment with an explicit reason. The current balance remains useful for fast reads, but the ledger explains where it came from. Make payment delivery idempotent A payment callback is a message that may be retried. I use an idempotency key derived from the provider and transaction ID, then enforce uniqueness in the database. The delivery flow is straightforward: Verify the external transaction. Record the payment. Grant currency with the unique key. Mark delivery complete. Return the original result for later retries. This prevents a temporary network problem from becoming a double grant. Protect spending too Client-side balance checks are useful for interface feedback, but they cannot protect an account. The server should lock the wallet row, check the available amount, write the ledger entry, and update the cached balance in one transaction. The same request key should return the original purchase result instead of charging twice. Keep payment, wallet, and item orders separate A real-money payment, a virtual-currency movement, and item delivery are connected but different events: payment order → wallet grant → item order → wallet spend That separation makes refunds and reconciliation much easier. When something goes wrong, support can identify which step is missing instead of guessing from one mutable number. Tests that expose the real failures Before bu

I spent a while building browser-based hardware diagnostics and came away with a much clearer sense of where the web platform is genuinely capable and where it quietly lies to you. Notes below, with live demos for each API so you can poke at them yourself. Refresh rate: requestAnimationFrame is the only signal you get There's no screen.refreshRate . The only approach is timing requestAnimationFrame callbacks and inferring the rate from the median frame delta: const deltas = []; let last = performance . now (); function tick ( now ) { deltas . push ( now - last ); last = now ; if ( deltas . length < 180 ) requestAnimationFrame ( tick ); else { const sorted = deltas . slice (). sort (( a , b ) => a - b ); console . log ( Math . round ( 1000 / sorted [ sorted . length >> 1 ])); } } requestAnimationFrame ( tick ); Two gotchas that cost me time. Use the median , not the mean — a single dropped frame wrecks an average. And browsers throttle rAF in background tabs, so the measurement is meaningless unless the tab is visible; gate it on document.visibilityState . ( live version ) Screen dimensions: four different answers, all "correct" screen.width , window.innerWidth , window.devicePixelRatio and screen.availWidth measure genuinely different things, and the one people usually want — actual native panel resolution — is screen.width * devicePixelRatio . Except that's still CSS-pixel derived, so on a scaled display it can disagree with what the panel physically is. The browser simply does not expose true hardware resolution. ( demo ) Keyboard: event.code vs event.key , and the keys you never receive event.key is layout-dependent, event.code is physical position — for a hardware tester you want code . The real limitation is that some keys never reach JS at all: PrintScreen often doesn't fire keydown , Meta combinations get swallowed by the OS, and Fn isn't a browser-visible key on most laptops. N-key rollover testing works surprisingly well though, since you just track the siz

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What...

Access tokens, refresh token rotation, and theft detection: the parts most Node.js tutorials leave out. A friend messaged me about his side project a few months ago: "Someone else is logged into my account. I changed my password. They're still in." He had followed the tutorials to the letter. Sign a JWT on login, send it to the frontend, keep it in localStorage , attach it to every request. Done. What none of those tutorials mentioned is that this setup has no way to un -log anyone in. A JWT is a signed piece of paper. Once you hand it over, it stays valid until it expires, and his expired in 30 days. Changing the password accomplished nothing, because the token had already been signed and nothing about it depended on the password. There was no list of active sessions to delete from. There was nothing to revoke. His only remaining move was rotating the signing secret, which logged out every user on the platform at once. That was his entire kill switch: burn it all down. This is the walkthrough I wish someone had handed me the first time I built auth. Token design, storage, refresh rotation, theft detection, the Express code, the Axios interceptor on the frontend, and the specific mistakes that turn a working login into an incident. It's long. Auth is one of those areas where the missing ten percent is the part that gets you. What the standard tutorial leaves out Nearly every "JWT authentication in Node.js" post ends in the same place: sign a token, put it in localStorage , send a Bearer header. That gets you a demo. Four things stand between that and production. localStorage is readable by any JavaScript on the page. That includes the analytics snippet you added last week, the npm package that got compromised upstream, and any XSS hole in your own code. One call to localStorage.getItem('token') and an attacker holds a working credential they can replay from their own machine. You can't detect it and you can't stop it. There is no revocation. The appeal of JWTs is st

I wanted a simple WhatsApp AI bot without paying every month for cloud hosting or an AI API. So I built one that runs on a Windows PC I already have running 24/7. The result: WhatsApp integration with Node.js Optional local AI using Ollama No VPS or cloud server required No paid AI API required Runs on Windows 10/11 Can restart automatically after a reboot «The "$0/month" refers to additional software, hosting, and AI API costs. It assumes you already have the PC, internet connection, and electricity.» The basic architecture The setup is intentionally simple: WhatsApp → Node.js bot → Local AI → WhatsApp reply The Node.js application handles incoming WhatsApp messages and decides how to respond. For AI responses, the bot can send the user's message to a locally running Ollama model and return the generated answer back to WhatsApp. That gives us: WhatsApp → Node.js → Ollama on localhost → Node.js → WhatsApp No cloud AI API is required. What you need For the basic setup: Windows 10 or Windows 11 Node.js LTS A WhatsApp account Ollama if you want local AI A computer that can stay powered on You don't need Kubernetes. You don't need AWS. You don't need Docker. And you don't need to rent a VPS. Connecting WhatsApp For this project I used "whatsapp-web.js". The first time the application starts, it displays a QR code. You scan the QR code with WhatsApp, similar to connecting WhatsApp Web. After authentication, the application can listen for incoming messages and send replies. A simplified example looks like this: const { Client, LocalAuth } = require('whatsapp-web.js'); const client = new Client({ authStrategy: new LocalAuth() }); client.on('qr', (qr) => { console.log('Scan the QR code to connect WhatsApp'); }); client.on('ready', () => { console.log('WhatsApp bot is ready'); }); client.on('message', async (message) => { if (message.body.toLowerCase() === 'hello') { await message.reply('Hello from the bot!'); } }); client.initialize(); "LocalAuth" stores the authenticated W

Start from the mismatch, because every bug in this integration comes out of it. Email hands you a MIME tree, an SMTP envelope, and a Message-ID chain that defines the conversation. Slack hands you a channel, a message of at most 50 blocks, and a ts that defines the conversation. The whole job is mapping one onto the other without dropping information — the reply chain, the authentication verdicts, the attachments — on the floor. Here's the whole inbound half, as a Cloudflare Worker. It runs as pasted with one KV namespace bound as SEEN and one dependency ( npm install mailkite ): // worker.js — inbound email → Slack. wrangler secret put SLACK_BOT_TOKEN / MAILKITE_WEBHOOK_SECRET import { MailKite } from " mailkite " ; const clamp = ( s , n ) => ( s . length > n ? s . slice ( 0 , n - 1 ) + " … " : s ); function blocksFor ( email ) { const subject = email . subject || " (no subject) " ; const trusted = email . auth . dmarc === " pass " ; const sender = trusted && email . from . name ? ` ${ email . from . name } < ${ email . from . address } >` : email . from . address ; return [ { type : " header " , text : { type : " plain_text " , text : clamp ( `📧 ${ subject } ` , 150 ) } }, { type : " section " , fields : [ { type : " mrkdwn " , text : `*From:*\n ${ clamp ( sender , 2000 )}${ trusted ? "" : " ⚠️ " } ` }, { type : " mrkdwn " , text : `*To:*\n ${ email . to [ 0 ]. address } ` }, ] }, { type : " section " , text : { type : " mrkdwn " , text : clamp ( email . text || " _no text part_ " , 3000 ) } }, { type : " context " , elements : [ { type : " mrkdwn " , text : `spf \` ${ email . auth . spf ?? " unknown " } \` · dkim \` ${ email . auth . dkim ?? " unknown " } \` · dmarc \` ${ email . auth . dmarc ?? " unknown " } \` ` }, ] }, ]; } export default { async fetch ( req , env ) { const raw = await req . text (); const sig = req . headers . get ( " x-mailkite-signature " ); // HMAC recompute, constant-time compare, ±5-minute replay window: one call if ( ! MailKite . verify

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built For the Perfect Landing prompt, I built Masala Dosa House , a warm and modern landing page inspired by one of my favorite comfort foods — South Indian Masala Dosa . 🇮🇳 The idea was to create a fictional restaurant website that feels like stepping into a familiar neighborhood dosa spot. The landing page focuses on: 🍽️ Hero section featuring Masala Dosa 🥞 Signature dishes 🥥 Chutneys and sambar 🌿 Traditional South Indian food experience ❤️ A warm, welcoming visual design 📱 Responsive layout for desktop and mobile ✨ Smooth interactions and animations 🎨 Food-inspired colors, typography, and visual elements 📍 Restaurant-style call-to-action sections Rather than creating a generic restaurant landing page, I wanted the entire experience to communicate the feeling behind comfort food — warmth, familiarity, and home . Demo 🍽️ Live Project: Masala Dosa House — A Taste of Home View the Masala Dosa House project on CodePen Journey I started by thinking about what makes a food website feel different from a regular landing page. For me, comfort food isn't only about the food itself. It's about the experience around it — the aroma, the warmth, the familiar presentation, and the feeling of sitting down for a meal that you already know you'll enjoy. That became the design direction for Masala Dosa House . I used a warm visual palette inspired by dosa, banana leaves, spices, chutneys, and traditional South Indian dining. The layout was designed to keep the food as the main focus while making the page easy to navigate. Building the experience I structured the landing page around a simple restaurant journey: Discover → Explore → Choose → Visit The hero section introduces the restaurant and immediately establishes the comfort-food theme. The menu section highlights signature dishes, while supporting sections provide more context about the restaurant and its food. I also focused on making the

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built Karachi Ki Raatein ("Karachi's Nights") — a single-page love letter to the street food that keeps my city awake after dark. Instead of a restaurant or a recipe box, I built it around a real pattern from home: Karachi basically runs on an unofficial food schedule. Maghrib means chai and something fried. Bun kabab happens standing up, mid-errand. Nihari is what you sit down for after Isha. Seekh kabab shows up wherever there's smoke. And halwa puri at 3am is for the people who never went to sleep in the first place. The whole page is built around that rhythm instead of a menu. A few things I'm happy with on the frontend side: A signboard hero with a flickering neon-style headline and hand-drawn CSS/SVG steam rising from a cup — no stock photography anywhere on the page, everything is drawn. A canvas-based particle steam system that replaces the static SVG once JS is available — real particles with drift, turbulence and upward acceleration, and they physically scatter when you move your cursor through them, like waving your hand through actual steam. A live "Night Clock" that reads your real local time ( Date , your timezone, nothing hardcoded) and marks whichever stall is "in season" right now with a pulsing "you are here" badge — so the page behaves differently depending on when you actually open it. A theme built for the medium : dark ink background, ember/turmeric accent colors, a hand-lettered chalk font for the "voice" of the thela-wala mixed with a bold display face for the signage, instead of the usual cream-and-terracotta food-site look. Respects prefers-reduced-motion everywhere (falls back to a static SVG steam loop and skips the canvas sim), keyboard-focusable throughout, fully responsive. Demo Journey I wanted to avoid the obvious comfort-food landing page — cream background, terracotta accents, a hero photo of a steaming bowl. It's a solid look but I see it ev

GitHub热门项目 | Modular SenseNova skills for building AI-powered office assistants and productivity workflows | Stars: 4,916 | 1 star today | 语言: JavaScript

GitHub热门项目 | 🔥 The free & Open Source DocuSign alternative | Stars: 6,841 | 26 stars today | 语言: JavaScript

GitHub热门项目 | 📻Terminal/ssh/sftp/ftp/telnet/serialport/RDP/VNC/Spice client(Linux, Mac, Windows, Android, HarmonyOS) | Stars: 14,830 | 54 stars today | 语言: JavaScript

🌀 MOKSHA Devlog — August 15, 2026 Overview Today's session focused on implementing and refining the Shareera Gatee (body-motion) mechanic as a companion to Samaya Gatee (time-flow). Major work included UI/UX polish, physics integration, and karmic carry-over mechanics for praarabdha (accumulated karma from past lives). Commits & Changes 1. UI: Added HUD Element for Shareera Gati Commit: 8874bcc | 06:33 UTC Scope: HTML/JS refactoring of HUD elements Changes: Added new shareera-gatee HUD indicator (cyan, #67e8f9 ) Renamed ui-gatee → samaya-gatee for clarity Updated engine state tracking: _oldStats and _uiScales now include both samayaGatee and shareeraGatee _uiGlows state expanded for dual-gatee animations Files Modified: index.html — HUD markup src/engine.js — State initialization src/main.js — UI element references src/state.js — Animation loop updates Status: ✅ Foundational UI structure ready 2. UI:UX: Implemented Shareera Gatee Commit: 387e488 | 09:30 UTC Scope: Physics integration + dynamic speed modulation Changes: Karma-speed coupling: Punya/Paapa/Praarabdha now reduce player movement speed Base speed modifier: _sMod = 0.7^ashuvhaKarma × 0.8^shuvhaKarma × 0.7^praarabdha Body-motion indicators: 🐌 = slowed (< 100%) 🚶 = normal (100%) 🏃 = accelerated (> 100%) Samaya Gatee now represents relative time flow: Inverted modifier: karmaSpeedMul = (1/0.7)^ashuvhaKarma × (1/0.8)^shuvhaKarma Time accelerates under karma-debt, slows under merit Dynamic emojis: 🧊 (slow) / ⌛ (normal) / ⚡ (fast) Praarabdha snapshot on death: Speed multiplier carries forward to next rebirth Stored in _praarabdhaSpeedMul for persistent karma-weight Game Feel: Karma now directly affects both movement speed and time progression , creating dual gameplay feedback Files Modified: src/engine.js — Physics + HUD animation src/karma.js ��� Rebirth speed carry-over index.html — Icon symbols Status: ✅ Core mechanic implemented 3. praarabdha: No Reset of Samaya Gatee on Punarjanma Commit: 4305106 | 10:25 UTC

A known-bad regex is useful evidence, but putting it directly in the test process can hang the runner before the timeout assertion fires. The boundary I am using: run each adversarial case in a fresh worker thread or child process let the parent own a hard timeout and terminate the child keep semantic-parity fixtures separate from timing guards require the safer replacement to pass both suites record the timeout class and bounded elapsed time as evidence Browser workers have the same trap: startup time should not consume the execution budget, and output limits matter alongside time limits. Disclosure: I maintain MonoTools. I recently tightened its browser-local Regex Tester around a 300 ms post-startup Worker budget, named groups, replacement previews, and regression cases: try the bounded tester What does your team treat as a deterministic CI failure receipt for ReDoS: an exit code, a timeout class, an elapsed-time range, or something else?

This is a submission for Frontend Challenge - Comfort Food Edition Perfect Landing. What I...

Why Environment Variables Matter Every app has secrets: API keys, database URLs, admin passwords. Hardcoding them in source code is a one-way ticket to leaks. Even if your repo is private, you never know who forks it or what CI logs expose. Environment variables are the standard way to keep configuration out of code. But using them safely requires a few habits that go beyond just process.env . The Basics: Loading and Accessing In Node.js, you read env vars with process.env . But you should not access them raw everywhere. Create a central config module that validates and exposes them. // config.js const required = [ ' DB_URL ' , ' API_KEY ' , ' PORT ' ]; for ( const key of required ) { if ( ! process . env [ key ]) { throw new Error ( `Missing required env var: ${ key } ` ); } } module . exports = { dbUrl : process . env . DB_URL , apiKey : process . env . API_KEY , port : parseInt ( process . env . PORT , 10 ), }; Fail fast at startup. If a required variable is missing, crash immediately rather than failing later in a confusing way. Never Commit .env Files Tools like dotenv load variables from a .env file for local development. That file must stay out of version control. Add .env to your .gitignore immediately. Also add .env.local , .env.production , etc. if you use them. Instead of committing the actual values, commit a .env.example with placeholder or fake values. This documents what is needed without exposing anything. # .env.example DB_URL = postgres :// user : password @ localhost : 5432 / mydb API_KEY = your - api - key - here PORT = 3000 Use a Validation Library Manual checks are fine for small projects, but for anything serious use a schema validator like envalid or joi . They give you type coercion, defaults, and clear error messages. // with envalid const { cleanEnv , str , num } = require ( ' envalid ' ); const env = cleanEnv ( process . env , { DB_URL : str (), API_KEY : str (), PORT : num ({ default : 3000 }), }); module . exports = env ; This catches m

A user reports that they keep getting logged out. Not immediately — after a while, randomly, always...

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I...

مرتين خلال أسابيع صار موقعنا يبدو سليمًا تمامًا ولا يستجيب للضغط. الصفحة تُحمَّل، والتصميم في مكانه، والكونسول نظيف، والزوار لا يستطيعون فتح أي رابط. في المرتين لم يكن السبب خطأً برمجيًا بالمعنى المعتاد. كان سلوكًا موثّقًا في المتصفح يعمل كما صُمّم تمامًا، لكنه انطبق على نطاق أوسع مما توقّعنا. والأخطر أن اختباراتنا الآلية مرّت بنجاح في الحالتين. الحادثة الأولى: إعداد واحد عطّل سبعين عنصرًا أضفنا ويدجت مساعد ذكي للموقع، وفيه إعداد يفتح نافذة المحادثة تلقائيًا عند دخول الزائر. فعّلناه. بعدها صارت الصفحة ميتة. الروابط لا تُفتح، والأزرار لا تستجيب، وحقول البحث لا تستقبل كتابة. السبب أن الويدجت يعتمد نمطًا شائعًا في نوافذ الحوار: عند فتح النافذة، يضع السمة inert على كل ما عداها حتى لا يتشتت التركيز ولا يهرب مؤشر لوحة المفاتيح خارجها. سلوك صحيح ومطلوب في الحوارات. المشكلة أن الفتح التلقائي يجعل هذه الحالة هي حالة الصفحة الافتراضية عند كل زيارة . سبعون عنصرًا في الصفحة ورثوا inert ، وبقوا كذلك حتى يغلق الزائر نافذة لم يطلب فتحها أصلًا. // ما يفعله الويدجت عند الفتح document . querySelectorAll ( ' body > *:not(.assistant-root) ' ) . forEach (( el ) => el . setAttribute ( ' inert ' , '' )); و inert ليست سمة تجميلية. الفحص السريع يوضح مداها: const el = document . querySelector ( ' a.main-cta ' ); el . offsetParent !== null ; // true — العنصر مرئي getComputedStyle ( el ). pointerEvents ; // 'auto' — لا شيء يمنع المؤشر el . getBoundingClientRect (). width ; // 180 — له مساحة حقيقية el . matches ( ' :disabled ' ); // false — ليس معطّلًا el . closest ( ' [inert] ' ) !== null ; // true ← هنا الجواب كل فحص اعتدنا عليه يقول إن العنصر سليم. inert تعمل في طبقة أخرى: تُخرج العنصر وكل أبنائه من شجرة الوصول، وتلغي استقباله لأحداث المؤشر والتركيز، بلا أي أثر في الأنماط المحسوبة . لماذا مرّت الاختبارات اختباراتنا كانت تسأل الأسئلة المعتادة: هل العنصر موجود في الـDOM؟ هل هو مرئي؟ هل نصّه صحيح؟ الإجابات كلها نعم. ما كشف العطل كان لقطة شاشة نظر إليها إنسان ، ثم محاولة ضغط واحدة. الفحوص البرمجية كانت تصف صفحة سليمة بينما الزائر يرى صفحة جامدة. إن كنت تستخدم أي مكوّن يطبّق inert ، أضف هذا التأك