My talk “Frontend Ruby on Rails with Glimmer DSL for Web” went well at RubyConf Austria 2026 . Especially given that after the talk, Chad Fowler (the starter of RubyConf and famous book author of The Passionate Programmer , among other books) told me “good job”, and Obie Fernandez (a famous entrepreneur and book author of The Rails Way , among other books) told me he will try Glimmer DSL for Web because he doesn’t like React.js. Presentation Slides Direct Original Long Link: https://docs.google.com/presentation/d/e/2PACX-1vQ9oBnZpzK_eicVLGSqDmVzhsXsblONEKepnw5_xGHGXTM52JSjaS_ObYUJbx-zkb1M2ul9N2A2MnvU/pub?start=false&loop=false&delayms=60000&slide=id.g140fe579a5a_0_0 Glimmer DSL for Web GitHub: https://github.com/AndyObtiva/glimmer-dsl-web I ran a poll at the beginning of my talk, and everyone agreed that they love Ruby and that Ruby is superior to JavaScript, plus the majority indicated that they’d like to write less JavaScript and more Ruby during their Rails web development work. Several attendees told me my talk was great after the talk. Charles Nutter had me help him with his JRuby workshop afterwards by showcasing my other Glimmer project, Glimmer DSL for SWT , which runs on JRuby. In about 1 minute, I scaffolded a Hello World desktop app from scratch and then packaged it as a native executable on the Mac. Attendees were impressed. So, I’ve participated in presenting 2 events at this conference. I am very grateful for having such a great experience at RubyConf Austria 2026 overall, especially given that it uniquely included several classical/neoclassical/jazz concerts in between talks that entertained us and relaxed us. Chad Fowler concluded the conference with a beautiful Jazz piano and sax performance. Shout out to Hans Schnedlitz, Muhamed Isabegovic, and Zuzanna Kusznir (plus everyone who helped out) for organizing and hosting such a special Ruby conference!!! Original blog post version: https://andymaleh.blogspot.com/2026/06/rubyconf-austria-2026-frontend-r

AirDrop only works between Apple devices. Most alternatives require an app install, a cloud account, or route files through a third-party server. I wanted something simpler: Open a URL → discover nearby devices → send files. So I built LocalDrop — a peer-to-peer file transfer app that works entirely in the browser over local Wi-Fi. GitHub: https://github.com/akshaykdadheech/localdrop Live Demo: https://localdrop-4fddd39fb6ad.herokuapp.com How It Works Devices connected to the same Wi-Fi network automatically discover each other through a lightweight signaling server. Once discovered, WebRTC establishes a direct peer-to-peer connection: Browser A ──► Signaling Server ◄── Browser B └──────── WebRTC P2P ────────┘ The signaling server only helps devices find each other. File transfers happen directly between browsers via WebRTC and are DTLS encrypted, so the server never sees your files. Interesting Challenges Backpressure Handling WebRTC DataChannels on Chromium have a ~16 MB buffer limit. Sending data too aggressively can crash the tab. I solved this using: bufferedAmountLowThreshold Flow control based on drain events Cross-Platform Compatibility Different browsers expose different capabilities. Android Chrome supports the File System Access API iOS Safari does not This required separate file-receiving flows for each platform. Large File Transfers Keeping multi-gigabyte files in memory isn't practical. On Chrome, showSaveFilePicker() is triggered after the transfer completes, allowing transfer progress to remain visible throughout the process without buffering everything in RAM. Tech Stack Svelte 5 + Vite TypeScript WebRTC DataChannel Node.js + ws Docker Self-Hosting git clone https://github.com/akshaykdadheech/localdrop cd localdrop docker compose up -d Then open: http://your-ip:3001 from any device connected to the same Wi-Fi network. I'd love feedback from anyone who's worked with WebRTC DataChannels, especially on mobile browsers. If you find the project useful, a

I applied for a role at a mid-sized SaaS company about two years into my career. Strong company, interesting problem, good pay. I sent my application, got a recruiter callback, and then nothing for two weeks. When the feedback finally came: "We went with candidates with a stronger portfolio presence." I had 23 GitHub repositories. I had a portfolio site. I had projects. What I didn't have — and what I didn't understand for another six months — was a portfolio that told a story. I had code. Not evidence of thinking, decision-making, or the ability to ship something real. I've since built, rebuilt, and advised on a lot of developer portfolios. I've seen what gets people calls and what gets them ghosted. This isn't a guide about which framework to use or how to pick colors. It's about what actually moves the needle — the things I wish someone had told me in year one. Lesson 1: Two Great Projects Beat Twenty Mediocre Ones The instinct is to fill the portfolio. More projects = more evidence of experience. This is wrong. A hiring manager or engineering lead looking at your portfolio has about three minutes. They're going to look at your two or three most prominent projects, click one or two live demo links, and form an opinion. If they see twenty repositories and most of them are "Todo App v2," "Weather App," "Netflix Clone," "Portfolio v1 through v6" — they've already categorized you as someone who builds tutorials, not someone who builds things. The better approach: three to five projects, each with: A real problem it solves (not "I wanted to learn React") A live deployment that actually works A README that explains why you made the decisions you made Enough complexity to have generated at least one interesting engineering problem Projects that tend to work: tools you built because you were frustrated with an existing tool, apps solving problems you personally had, projects where you integrated with a real API or real data source, anything with a live user base (even 10

Last year I helped a startup integrate the OpenAI API into their product. It was a chat feature — users could ask questions about their data and get natural language answers. The integration took about a day. Three days after launch, the founder messaged me: "Hey, something's wrong. Our AWS bill just showed an unexpected charge." It was $340. For three days. They had 60 users. The issue wasn't a bug — it was that production API usage looks nothing like a tutorial. The tutorial shows you openai.chat.completions.create() and returns a response. The tutorial doesn't show you what happens when users send 500-token messages, when they open 15 browser tabs each maintaining their own chat context, or when one user fires requests 30 times per minute because they think it's broken. This guide covers what the tutorials skip: rate limiting, token counting, cost guards, streaming, error handling with retries, and model selection. These aren't optional additions — they're what separates a demo from a production feature. Why Production Is Different Here's the gap between tutorial code and production code, stated plainly: Concern Tutorial Code Production Code Cost control Not mentioned Token counting, spending limits, model selection by task Rate limiting Not mentioned Per-user and per-IP limits to prevent abuse Error handling try/catch that logs to console Typed errors, retries with backoff, user-facing messages Response delivery Wait for full completion, return at once Streaming via SSE — response appears as it generates Context management Each request is independent Conversation history managed, truncated at token limit Secrets management API key hardcoded or in .env (no rotation) Rotation strategy, usage monitoring, per-feature keys Let's build a production-grade Express API that addresses all of this. We'll go layer by layer. The Architecture ┌─────────────────────────────────────────────────────────┐ │ CLIENT (Browser / Mobile) │ │ POST /api/chat { messages: [...] } │ │ GET

The first time I deployed a Next.js app to production, it took me three days. Not because the app was complicated — it was a straightforward portfolio site. It took three days because I had no idea what I was doing with AWS, I'd never written a GitHub Actions workflow, and every tutorial I found either skipped the hard parts or assumed I already knew them. By the time I was done, I had a deployment pipeline I was genuinely proud of: push to main, GitHub Actions runs the build, tests pass, the app deploys to an EC2 instance behind CloudFront. Zero manual steps. Zero downtime deploys. Total cost: about $5/month. This guide is the one I wish had existed. We're going to deploy a Next.js app to AWS from scratch — EC2 for compute, CloudFront for CDN, GitHub Actions for CI/CD — with every step explained so you understand what you're building, not just copying commands. Why AWS Instead of Vercel? This is a fair question. Vercel is genuinely excellent for Next.js, and for most projects it's the right call. You push, it deploys. Done. AWS makes sense when: You need to control the infrastructure (compliance, data residency, custom VPC configuration) You're running other services (databases, queues, lambdas) in AWS and want everything in the same network You want to learn infrastructure skills that transfer to enterprise environments Your app has specific performance requirements that benefit from custom CloudFront configuration You're a freelancer or consultant who wants to bill separately for infrastructure If none of those apply to you, use Vercel. This guide is for when they do. The Architecture Here's what we're building: ┌────────────────────────────────────────────────────────┐ │ GITHUB ACTIONS CI/CD │ │ │ │ Push to main → Build → Test → Deploy to EC2 │ └──────────────────────┬─────────────────────────────────┘ │ SSH deploy ▼ ┌────────────────────────────────────────────────────────┐ │ AWS EC2 INSTANCE │ │ │ │ Ubuntu 22.04 LTS │ │ Node.js 20 + PM2 (process manager) │ │ N

The LedgerSync pipeline was inserting 1.5 million rows into PostgreSQL using pandas.to_sql() . It took four minutes per run. I switched to psycopg2's COPY command and it dropped to 18 seconds. Same data, same schema, same machine. That is not an optimization tip. It is the difference between a pipeline that fits in an Airflow schedule and one that does not. This article is about patterns like that: the ones that matter when you are building pipelines that run on a schedule, not when you are writing ad-hoc queries. Loading Data: to_sql vs execute_values vs COPY There are three ways to write rows from Python into PostgreSQL, and the performance gap between them is significant. pandas to_sql issues one INSERT statement per row by default, or a multi-row INSERT with method="multi" . It is the easiest to write and the slowest for any serious volume. psycopg2 execute_values batches many rows into a single multi-row INSERT VALUES statement. About 5x faster than to_sql for medium-sized loads. psycopg2 COPY streams rows directly to PostgreSQL using its native bulk-load protocol. No statement parsing, no row-by-row overhead. For LedgerSync at 1.5M rows, this was the one that mattered. import psycopg2 import io import pandas as pd conn = psycopg2 . connect ( " host=localhost dbname=proj_db user=proj_user password=proj_pass " ) def bulk_copy ( df : pd . DataFrame , table : str , columns : list [ str ]): buf = io . StringIO () df [ columns ]. to_csv ( buf , index = False , header = False ) buf . seek ( 0 ) with conn . cursor () as cur : cur . copy_from ( buf , table , sep = " , " , columns = columns ) conn . commit () print ( f " Loaded { len ( df ) } rows into { table } " ) Use COPY for initial loads and large backfills. For incremental daily writes of a few thousand rows, execute_values is fine and gives you more control over conflict handling: from psycopg2.extras import execute_values def bulk_insert ( rows : list [ dict ], table : str ): if not rows : return columns = list

The first gameplay trailer shows off bloody melee combat.

I would like some advice from well experienced devs that you would give to junior devs submitted by /u/Dizzy_External2549 [link] [留言]

At its big State of Play show on Tuesday, Sony shared new look Marvel's Wolverine, the next big title from Insomniac Games that's launching exclusively on PS5 on September 15th. Dressed in the iconic yellow Wolverine outfit, Logan slunk around and stabbed his way through a bunch of enemies, using his blades to take them […]

There's a specific feeling you get after your third production caching incident. It's not panic....

Running multi-turn or multi-agent AI sessions? There is a consistent degradation pattern across tools: context fills with repeated history, tool schemas, and subagent handoffs. A 2026 paper by Bai et al. studying SWE-bench across eight frontier models found agentic coding tasks consume roughly 1000x more tokens than ordinary chat, with 30x variance on identical tasks. Accuracy does not rise with spend. In one tracked research synthesis run I observed context hit 450,000 tokens. The agent dropped early constraints, re-queried sources already in history, and required manual reset. After adding three controls, the same class of task peaked near 85,000 tokens: PLAN.md and INVARIANTS.md outside the conversation window, read fresh each major turn A 2,000-line read budget gate per turn (agent states intent before any retrieval) Out-of-band notes for subagent coordination so side traffic never enters the main transcript Dynamic tool discovery produces similar ratios. One harness reduced input tokens 96% and total spend 90% by loading schemas only for tools the agent actually selects, rather than injecting a full catalog on every call. Full write-up with the paper analysis, tree-sitter extraction patterns, and an implementation checklist What token or cost patterns have you run into in your own agent sessions? submitted by /u/magicroot75 [link] [留言]

AI agent built into your CRM who works leads for you Discussion | Link

Microsoft missed the boat on apps, so get ready for agents.

While the majority of Summer Game Fest takes place over the weekend, Sony is getting a jump on things with its next State of Play showcase, which airs on June 2nd at 5PM ET. It’s coming at a pivotal time for the PlayStation brand: The PS5 keeps getting more expensive and Sony’s big bet on […]

submitted by /u/sizelrd [link] [留言]