标签：#productivity

Hey dev community! 👋 As developers, our inboxes often turn into a graveyard of job alerts (LinkedIn, Indeed, ZipRecruiter) and tech newsletters we subscribe to with the intention of "reading later" but never actually open. The result? Important emails get lost, and we get the dreaded "Account storage is almost full" notification. Recently, I hit that wall. I had thousands of accumulated emails. While Gmail allows you to create filters for incoming mail, it doesn't have a native feature to say: "Delete this email automatically after 7 days" . So, I decided to solve it the way we solve everything: by writing some code. 🛠️ The Solution: Google Apps Script + JavaScript Since the Google Workspace ecosystem runs on a JavaScript-based environment, I put together a custom script. Fun fact: a simple loop originally failed due to Google's strict 6-minute execution limit. To fix this, I optimized the code to process emails in batches of 100 , preventing the server from timing out. Here is the final production-ready script: function cleanSpamTsunami() { // 1. Loop to delete ALL Job Board emails in batches of 100 var continueJobSearch = true; while (continueJobSearch) { var jobThreads = GmailApp.search('computrabajo OR indeed OR linkedin OR OCC OR neuvoo OR talent.com OR jooble', 0, 100); if (jobThreads.length > 0) { Logger.log('Deleting a batch of ' + jobThreads.length + ' job alert emails...'); GmailApp.moveThreadsToTrash(jobThreads); } else { Logger.log('No more job alerts found!'); continueJobSearch = false; // Break the loop } } // 2. Loop to delete old Newsletters (older than 7 days) in batches of 100 var continueNewsletters = true; while (continueNewsletters) { var newsletterThreads = GmailApp.search('unsubscribe OR "cancelar suscripción" older_than:7d', 0, 100); if (newsletterThreads.length > 0) { Logger.log('Deleting a batch of ' + newsletterThreads.length + ' old newsletters...'); GmailApp.moveThreadsToTrash(newsletterThreads); } else { Logger.log('No more old newslett

Table of Contents The Moment That Changed Everything What It Actually Is The Setup Nobody Believes Is This Simple Focused Sessions — One Agent, One Mission Sub-Agents With Specific Skill Sets Building MCPs for Your Own Stack What We've Actually Achieved How It Became a Force Multiplier for Incident Response From OpenCode to FRIDAY — The Agent That Investigates Incidents Autonomously From FRIDAY to JARVIS — Thinking About Write-Path Autonomy Deleting 130,000 Accounts Without Writing Code Learning the Entire Product in Conversations Why This Is Different From ChatGPT The Uncomfortable Truth What's Next The Moment That Changed Everything It was 11pm on a Tuesday. A cache migration in our production environment had just caused thousands of authentication failures for two of our largest enterprise customers. Our VP of Product wanted answers. Our support team was fielding escalations. And our engineers were alt-tabbing between AWS console, Datadog, GitHub, Azure DevOps, and PagerDuty trying to piece together what happened. Three weeks later, when we needed to attempt the same change again, an engineer typed this into a terminal: "Review the ADO change ticket, compare the MOP against the actual ElastiCache configuration in prod region, check the K8s config repo for how Redis env vars are wired on the Green cluster, and tell me if this approach avoids the token validation failure that caused the previous customer impact." Fourteen seconds later , the system had pulled the work item, queried AWS ElastiCache across four regions, read the Kubernetes configuration from GitHub, cross-referenced the deployment patches, and delivered a precise technical assessment including a risk it identified that the team hadn't documented: in-flight tokens during the 30–60 second Global Accelerator propagation window. That system is OpenCode — an AI-powered CLI assistant connected to our entire operational stack through the MC(Model Context Protocol). And it has fundamentally changed how a 20-

Every serious AI workflow eventually runs into the same failure. The agent does useful work in one session. It learns the shape of the project. It figures out which assumptions were wrong. It follows a correction, makes a decision, and gets closer to the real work. Then the session changes. The next run starts too cold. Old context comes back without the correction that changed it. The agent asks for the same setup again. It repeats an assumption that was already fixed yesterday. You end up managing the memory of the work instead of moving the work forward. That is the problem Pith is built for. Pith gives AI agents durable project memory they can trust when facts change. It is not trying to make an agent remember everything. That would be the wrong goal. Real projects are messy. Facts change. Decisions get reversed. A note that was useful last week can become stale after a release, a migration, a new customer constraint, or one correction from the human operator. The harder problem is not recall. The harder problem is knowing which memory is still useful. Why Longer Context Is Not Enough Longer context helps, but it does not solve continuity by itself. A long prompt can carry more text into a single run. It cannot automatically decide which prior facts survived a correction, which decision is now superseded, or which evidence should come back when the project resumes three days later. Developers working with agents already feel this. The friction shows up as small taxes: repeating project background that the agent should already know; re-explaining decisions that were already made; correcting stale assumptions that were already corrected; losing the reason behind a prior choice; restarting from a cold state after every meaningful break. Those taxes compound. The more serious the workflow, the more expensive the memory gap becomes. If an agent is helping with a toy task, forgetting is annoying. If an agent is helping with a codebase, a release, a customer workflow,

Technology companies are extending AI beyond code generation into earlier stages of the software lifecycle, including PRD validation, design inputs, and code review. Initiatives from Uber, DoorDash, and Cloudflare highlight a shift toward AI-driven governance layers that evaluate engineering artifacts before implementation while preserving human oversight across the development pipeline. By Leela Kumili

Quando comecei a trabalhar com tecnologia, há mais de duas décadas, a Inteligência Artificial era algo restrito a laboratórios de pesquisa e ficção científica. Hoje, ela está embutida no aplicativo que recomenda sua próxima série, no e-mail que filtra spam automaticamente e até no GPS que recalcula sua rota em tempo real. A IA deixou de ser promessa para se tornar infraestrutura invisível do cotidiano. Neste artigo, quero ir além do hype e mostrar, com exemplos concretos, como essa tecnologia já transforma a forma como vivemos e trabalhamos. Produtividade pessoal e profissional turbinada O caso de uso mais palpável da IA hoje está na produtividade. Assistentes baseados em modelos de linguagem (LLMs) como ChatGPT, Claude e Gemini reduziram drasticamente o tempo gasto em tarefas que antes consumiam horas: redação de e-mails, geração de relatórios, resumos de reuniões e até depuração de código. Na minha rotina como gestor de TI, integrei essas ferramentas a fluxos de trabalho reais. Por exemplo, utilizo modelos de IA para revisar contratos de smart contracts escritos em Rust para a rede Stellar, identificando padrões de vulnerabilidade antes mesmo da auditoria formal. Não substitui a perícia humana, mas funciona como uma primeira camada de triagem que economiza tempo precioso da equipe. Algumas aplicações práticas que recomendo testar: Transcrição e resumo automático de reuniões com ferramentas como Otter.ai ou Fireflies Geração de documentação técnica a partir de comentários de código Automação de respostas em suporte de primeiro nível via chatbots treinados com a base de conhecimento da empresa O segredo está em tratar a IA como copiloto, nunca como piloto automático. A revisão humana continua indispensável, especialmente em contextos críticos. Saúde, finanças e decisões do dia a dia A IA também opera nos bastidores de decisões que afetam diretamente nossa qualidade de vida. No setor de saúde, algoritmos de visão computacional já auxiliam radiologistas na detecção pr

You have an API response. You want a Zod schema. So you paste the JSON into a JSON-to-Zod converter, copy the output, and ship it. Here's the trap: a lot of those converters infer basic types only . Your email , your uuid , your url , your ISO timestamp — they all come out as z.string() . The schema compiles, the types look right, and your validator quietly accepts "not-an-email" , "ftp://nope" , and "2026-99-99" forever. I wanted to see exactly how much gets lost, so I ran the same payload through two tools and diffed the output. Everything below is real, copy-pasteable output — nothing edited. The input A pretty ordinary user object: { "id" : "3f2a9c1e-5b7d-4e8a-9f1c-2d3e4f5a6b7c" , "email" : "ada@example.com" , "website" : "https://ada.dev" , "age" : 34 , "rating" : 4.7 , "created_at" : "2026-03-04T10:15:30Z" , "is_active" : true , "address" : { "city" : "Lyon" , "zip" : "69001" }, "tags" : [ "early-adopter" , "beta" ] } Tool 1 — json-to-zod (npm) const user = z . object ({ id : z . string (), email : z . string (), website : z . string (), age : z . number (), rating : z . number (), created_at : z . string (), is_active : z . boolean (), address : z . object ({ city : z . string (), zip : z . string () }), tags : z . array ( z . string ()), }); Structurally correct. But every meaningful field is a bare z.string() / z.number() . This schema will happily validate email: "lol" and created_at: "yesterday" . Tool 2 — TypeMorph import { z } from " zod " ; export const userAddressSchema = z . object ({ city : z . string (), zip : z . string (). regex ( /^ [ A-Z0-9 ][ A-Z0-9 \s\-]{1,8}[ A-Z0-9 ] $/i ), }); export type UserAddress = z . infer < typeof userAddressSchema > ; export const userSchema = z . object ({ id : z . uuid (), email : z . email (), website : z . url (), age : z . number (). int (). min ( 0 ). max ( 150 ), rating : z . number (). min ( 0 ). max ( 5 ), created_at : z . iso . datetime (), is_active : z . boolean (), address : userAddressSchema , tags :

Você já fez um commit no repositório do trabalho e percebeu que estava com o seu e-mail pessoal? Ou o contrário? Esse é um dos erros mais comuns de quem usa Git com múltiplas contas no mesmo computador. Neste tutorial você vai aprender a configurar tudo corretamente, de uma vez, usando chaves SSH separadas e .gitconfig condicional — sem gambiarras. O problema Por padrão o Git usa uma configuração global: git config --global user.name "Seu Nome" git config --global user.email "seu@email.com" Isso significa que todos os repositórios no seu computador usam o mesmo usuário. Quando você tem contas separadas (ex: joao@empresa.com no GitLab da empresa e joao@gmail.com no GitLab pessoal), os commits vão sair com o e-mail errado. A solução profissional envolve duas partes: Chaves SSH separadas para cada conta .gitconfig condicional que aplica o usuário certo — e a chave SSH certa — por pasta Passo 1 — Gerar as chaves SSH Abra o terminal e gere uma chave para cada conta. Use nomes diferentes para não sobrescrever: # Chave para a conta pessoal ssh-keygen -t ed25519 -C "joao@gmail.com" -f ~/.ssh/id_ed25519_pessoal # Chave para a conta do trabalho ssh-keygen -t ed25519 -C "joao@empresa.com" -f ~/.ssh/id_ed25519_trabalho 💡 Por que ed25519 ? É o algoritmo mais moderno, mais seguro e recomendado pelo GitHub, GitLab e Bitbucket. Evite RSA a menos que seu servidor seja muito antigo. Ao final você terá quatro arquivos em ~/.ssh/ : id_ed25519_pessoal ← chave privada (nunca compartilhe) id_ed25519_pessoal.pub ← chave pública (você registra no GitLab) id_ed25519_trabalho id_ed25519_trabalho.pub Passo 2 — Registrar as chaves no GitLab Para cada conta: Copie o conteúdo da chave pública: # Pessoal cat ~/.ssh/id_ed25519_pessoal.pub # Trabalho cat ~/.ssh/id_ed25519_trabalho.pub Acesse Settings → SSH and GPG keys → New SSH key na conta correspondente e cole o conteúdo. Faça isso nas duas contas , cada uma com a sua respectiva chave pública. Passo 3 — Configurar o Git por pasta (o pulo do gato)

PDF work shows up in dev life more often than we'd like to admit — exporting docs, compressing build artifacts, merging client deliverables, or converting a spec sheet someone sent as a scanned PDF into something you can actually search. Paid suites like Adobe Acrobat are overkill for most of these one-off tasks. Here are 10 free, no-signup tools that get the job done, ranked roughly by how often you'll reach for them. 1. ToolTiny — PDF to Word/Excel/PowerPoint ToolTiny converts PDFs into editable DOCX, XLSX, or PPTX files directly in the browser, alongside the usual merge/split/compress/watermark/password toolkit. No account, no watermark on output. What's actually useful for dev workflows: it handles presentation-style PDFs (think exported slide decks or design-heavy one-pagers) reasonably well — most converters flatten these into a single unreadable text blob, but ToolTiny keeps the layout intact while still giving you editable text. Good for the "client sent a PDF, I need it as a Word doc by EOD" scenario. 2. Smallpdf The OG in this space. Smallpdf's PDF-to-Word conversion is excellent at preserving layout — it renders the page as a background image and overlays editable text boxes at the correct coordinates, which is why it handles complex layouts better than most. Free tier caps you at 2 tasks/day though. 3. iLovePDF Similar feature set to Smallpdf, slightly more generous free tier. Their "Organize PDF" drag-and-drop page reordering is one of the smoother UX implementations out there if you need to quickly reshuffle a multi-doc PDF before sending it out. 4. PDF24 A German tool that's been around forever and quietly does everything — OCR, forms, signing, comparison. Less polished UI than the others but the OCR accuracy on scanned technical docs is genuinely strong. 5. Stirling-PDF If you want something self-hosted, Stirling-PDF is the open-source answer. It's a Docker container you spin up yourself, giving you a full PDF toolkit (split, merge, compress, OCR, wa

Here's a thinking process: Analyze User Input: Role: Ghostwriter for Roberto Luna Osorio Editorial Profile: Developer Storytelling (primary), Build in Public, Técnico, Reflexivo. Philosophy: Share the process/learnings, not just the perfect result. Mandatory narrative questions: Problem, First attempt, What went wrong, How solved, What learned, What's next. Tone: First person, direct, honest, technical but accessible, curious. Avoid corporate jargon, clickbait, marketing hype, false modesty, empty summaries. Language: Spanish (natural/colloquial tech MX/LatAm) OR English (conversational, dev-friendly). Wait, the prompt says "English only (Dev.to is primarily English)" for this specific article. I'll stick to English as instructed for the Dev.to angle. Angle: TECHNICAL DEEP-DIVE ("HOW I BUILT IT"). Focus on code, architecture, specific files. Different from Medium's narrative style. Style: Technical, precise, code-forward. Real file/function names, error messages. First person but engineer-voice. English only. Mandatory Structure: TL;DR, The Problem, What I Tried First, The Implementation, Key Takeaway, What's Next. Length: 800-1200 words. Tags: #vibecoding #buildinpublic + relevant tech tags. Input Data: Repo: VS, Date: 2026-06-23. Commits show v1.6.0 sprint 1, booking reminders, /confirm/:token, notifications, bulk actions, pipeline v2. Files modified: booking-reminders.service.ts , booking.controller.ts , email.cron.ts , notifications.controller.ts , NotificationBell.tsx , confirm/[token]/page.tsx , ventas/pipeline/page.tsx , etc. Diffs show version bumps, cron integration, notification controller refactor, new components. Constraint: Do NOT repeat angles from this week: "El control de acceso y la caja negra de las publicaciones". Choose a completely different angle. Final Instruction: Write complete article. Start directly with TL;DR. Include actual code snippets. Do NOT write a story — write a technical breakdown. Map to Editorial Profile & Constraints: Profile

You don't need a 5-person engineering team to run like one. Here's how small businesses are cutting manual work — without the overhead. The Problem Nobody Talks About Openly You're running a business. You have leads coming in from your website, follow-up emails to send, invoices to track, onboarding tasks to assign — and somehow, you're still doing most of it manually. You've probably heard the advice: "Just hire a developer." But a full-time developer costs $60,000–$120,000/year in the US. A dev team? Multiply that by four. For a growing small business, that's not an option yet. Here's what nobody tells you: you don't need a full dev team to automate 80% of your operations. You need the right tools — and someone who knows how to connect them. What "Workflow Automation" Actually Means (No Jargon) Workflow automation is just this: if X happens, do Y automatically — without you touching it. Some real examples: A new lead fills out your form → they get an automated welcome email + a task is created for your sales rep An invoice is marked paid → a receipt is sent + your spreadsheet updates + a Slack message goes to your finance channel A support ticket comes in → it's categorized, assigned, and a reply is sent based on the topic You already know these need to happen. Automation just removes you as the middleman. The Modern Stack: 4 Tools That Do 80% of the Work 1. Zapier / Make (formerly Integromat) These are no-code automation platforms. Think of them as the "if this, then that" engine for your apps. Connect 5,000+ apps (Gmail, Shopify, Notion, Slack, HubSpot, etc.) Build multi-step automations visually — no coding needed Best for: Email triggers, form responses, basic data sync Cost: Free tier available; paid from ~$20/month 2. Salesforce (with OmniStudio / Flow) If your business is scaling or you're in B2B sales, Salesforce isn't just a CRM — it's an automation engine. Flow Builder lets you automate record updates, approvals, emails, and task assignments visually Omn

I'll be honest — I didn't set out to build a developer tool. I'm an engineer by trade. I build structural and forensic engineering software. C++, WinUI 3, heavy desktop apps. But a big chunk of my prototyping and internal tooling happens in Python — and every time I sat down to spin up a quick Python desktop app, I hit the same wall. Every launcher, every hot-reload tool, every dev cockpit I found wanted something from me. Install this. License that. Set up a virtual environment. Add five dependencies just to watch a file change. I just wanted to run my app, see it update when I changed something, and get back to work. So I built ILX Launcher. The rule I gave myself was simple: pure Python stdlib and tkinter. Nothing else. If it couldn't be done with what Python already ships with, I didn't need it. What came out of that constraint surprised me. No pip install. No virtual environment required. No licensing headaches. You clone it, you run it, it works. That's it. It's a developer cockpit for Python desktop apps — run, hot-reload, test, profile, and ship, all from one place. The kind of tool I wished existed six months ago. It's early. It's rough around the edges. But it works, and it's already saving me time every single day. If you've ever felt like your dev tooling was getting in the way of actually building — I'd love for you to try it and tell me what you think. 👉 github.com/ilxstudio/ILX-Launcher And if it saves you even five minutes — drop a ⭐ on the repo. It genuinely helps others find it.

I remember the exact moment my first AI side project died. It was 3 AM, I had just spent two full weeks building an elaborate RAG pipeline with vector databases, custom embeddings, and a fine-tuned model—all for a tool that would "revolutionize how developers read documentation." I hadn't written a single line of user-facing code. I hadn't even validated if anyone wanted it. And when I finally deployed it to a hobby server, the cost of hosting the model alone was $200/month. I killed the project before anyone ever visited the URL. That was three months ago. Since then, I've shipped three AI side projects that actually have users. Not millions—but real people who use them daily. Two of them even cover their own hosting costs now. The difference? I stopped trying to build the perfect AI infrastructure and started shipping the stupidest thing that could work. Here's what I learned from those three MVPs, and how you can break out of the "AI side project graveyard" too. The Trap: Thinking You Need to Build Everything The biggest lie in the AI side project space is that you need to own the stack. Every tutorial screams "self-host Llama 3," "set up your own vector database," "build a custom agent framework." That's great for learning, but it's death for shipping. For my second project—a tool that automatically generates commit messages from diffs—I spent exactly one evening. I used the OpenAI API directly, with no caching, no streaming, no error handling. Here's the core of it: import openai import subprocess def get_diff (): result = subprocess . run ([ " git " , " diff " , " --cached " ], capture_output = True , text = True ) return result . stdout def generate_commit_message ( diff ): response = openai . chat . completions . create ( model = " gpt-3.5-turbo " , messages = [ { " role " : " system " , " content " : " Write a concise git commit message summarizing the changes. " }, { " role " : " user " , " content " : diff } ] ) return response . choices [ 0 ]. message .

I wanted AI code review I could actually own. Not access through a subscription or a black-box service with its own limits. The deployment, credentials, providers, and usage under my control. I kept hitting usage limits mid-week during deep building sessions. The models were capable. The workflow was useful. But access still depended on somebody else's weekly allowance, and centralized platforms can change whenever the company behind them decides to. Pricing, quotas, models, plan boundaries. A workflow that fits this month may sit behind another subscription next month. I could not find a reliable open-source option that gave me the ownership model I wanted. So I built one. That became Codra : A self-hosted AI review engine built around bring-your-own models, your own data boundary, and no Codra-imposed usage ceiling. What Codra Is Codra is an open-source, self-hosted AI code review engine for GitHub pull requests. It listens to pull request events, reviews changed files, posts inline findings, and provides a dashboard for jobs, repositories, model routing, history, usage, and failures. It runs on Cloudflare Workers and uses: Cloudflare Queues for review jobs PostgreSQL through Hyperdrive for storage KV for sessions and cache A React dashboard for operations The GitHub App, model credentials, database, and review history are yours. Provider keys are encrypted with AES-GCM using your deployment secret. Bring Your Own Model, Bring Your Own Limits Changing providers does not require replacing your review history, configuration, or workflow. You configure the provider and model. Supported: OpenAI-compatible APIs OpenRouter Anthropic Google / Gemini Cloudflare Workers AI Why Self-Hosted Matters Here A large frontend repo and a tiny backend repo should not need the same review strategy. Each repository gets its own review settings. You tune triggers, skip generated files, ignore drafts, use mention-triggered reviews, configure labels, set file limits, and define custom ru

TL;DR: We launched Tarotas, a tarot reading app, in five languages (Czech, Slovak, Polish, English, German) on a single domain. Each market behaved completely differently. Here is what the data showed us about multi-locale growth. When we started building Tarotas at Inithouse, the plan seemed straightforward: one product, five languages, one domain. Czech as the base, then Slovak, Polish, English, and German. Same cards, same readings, same UI. Just translated. What we did not expect: each locale acts like a separate product. The setup Tarotas is a tarot card app where you draw a card and read a calm, generic interpretation. No fortune telling, no sign-ups, no paywall. 78 cards across five languages, all on tarotas.com with language detection. We built it in Lovable and deployed it in under two weeks. The multi-language part took another week: content generation for 78 cards times 5 languages, plus locale-specific meta tags and URL structures. What the data told us The Czech and Slovak markets responded first. That was expected: our studio is based in Prague, our existing portfolio (products like zivafotka.cz and magicalsong.com ) already had traction in CZ/SK. But the interesting part was the divergence. CZ/SK users stayed longer. Session duration in Czech and Slovak was noticeably higher than in other locales. Users explored multiple cards, came back for second readings. The "reflection" positioning landed well in these markets, likely because tarot has a quiet cultural niche in Central Europe: not mainstream, but not fringe either. Polish users bounced faster but shared more. The PL locale had higher bounce rates but showed a different signal: social referrals. Polish users who did engage were more likely to share readings. The tarot community in Poland leans more social: Facebook groups, Instagram stories, TikTok readings. Our product caught some of that energy. German users barely showed up. DE was our weakest locale by far. German-language search demand for ta

Beyond the Prototype: Why Teams Need More Than Vibe Coding Over the last year, AI coding tools such as Lovable, Bolt.new, v0, Base44, and others have fundamentally changed how software gets created. A single founder or developer can now go from a rough idea to a working prototype in hours rather than weeks. That kind of acceleration is genuinely exciting, and it has opened software creation to far more people. That democratization is a good thing. Rapid experimentation, faster feedback loops, and lower barriers to entry are changing how products get started. Many successful companies and ideas will emerge because these tools made building more accessible. As I've followed the conversations happening around these tools—through reviews, articles, community discussions, and the experiences being shared by founders and engineering leaders—I've noticed an interesting pattern. The challenge is no longer getting to the first version. The challenge begins after. The Prototype Was Never the Finish Line The prototype works. Stakeholders become excited. Customers show interest. Momentum builds. Then a different set of questions starts to emerge. How do we align everyone on what we're building? How do we evolve an existing application instead of starting over? How do we maintain quality as complexity increases? How do multiple people collaborate without losing context? How do we know whether we're delivering the outcomes we intended? And how do we continuously improve without creating chaos? These aren't failures of AI coding tools. They're simply different problems. Many of today's AI builders are optimized for individual acceleration and rapid exploration. But once a promising idea becomes a product that teams must own, maintain, and evolve together, different requirements naturally emerge. What works for one person experimenting is not always enough for a group of people building something intended to last. Building Software Is More Than Generating Code Software development

If you write software for a living and you're considering a trip to China in 2026, the friction you'll hit is not what you expect. The Great Firewall is the headline, but it's rarely what trips up a first-time visitor. What actually breaks your week is the small stuff: a QR code at a noodle shop, a metro turnstile that won't take your foreign card, a hotel Wi-Fi that quietly drops every request to Google. This is a brief survival guide written from a developer's mindset: what's actually changed in 2026, what you can fix before you leave, and what you should just accept. 1. Visa-free entry now covers most Western devs As of late 2025, China extended its 30-day visa-free transit policy to passport holders from 38 countries, including the US, UK, Germany, France, Australia, the Netherlands, and most of the EU. If you're flying in for a vacation, a conference, or even a short remote-work stretch, you may not need to apply for a visa at all — you just need an onward ticket within 30 days. The catch: the rules per nationality drift quarterly, and the official guidance is scattered across embassy pages. I keep a more current breakdown here: FirstTripChina visa-free guide — worth checking the week you book your ticket. 2. The payment problem is the real "API" you need to integrate China runs on two payment rails: Alipay and WeChat Pay. Cash is technically legal but vendors below the level of a 4-star hotel will look at you like you handed them a stone tablet. Foreign credit cards work at airports and big chains; they do not work at the dumpling place you actually want to eat at. The fix that exists in 2026 — and that did not exist three years ago — is "Tour Card" inside Alipay and "International" mode inside WeChat Pay. Both let you link a Visa/Mastercard issued outside China and pay via the same QR system locals use. Setup steps (roughly): Install Alipay (App Store / Play Store, US/EU regions both work). Verify with passport + selfie (KYC takes about 3 minutes). Tap Tour C

Some days the work spreads across a few projects instead of landing as one big feature. Today was that — three distinct threads, each with a lesson worth keeping. I'll keep things generic and teach the pattern rather than the project, but the through-line is the same: move things that were hardcoded or ephemeral into something you can configure, repeat, and trust. Thread 1 — Make scheduled tasks configurable instead of code-only If you've run a Laravel app for any length of time, you know the scheduler lives in code: routes/console.php or the kernel, a wall of ->daily() , ->everyFiveMinutes() , ->cron(...) . That's fine until the day an operator — not a developer — needs to change when something runs. Then you're shipping a deploy just to nudge a cron expression. Silly. Today's work pulled scheduler configuration into a settings-backed UI. The pattern is worth stealing: instead of the schedule being a literal in code, the code reads its cadence from a settings store, and there's an admin screen to edit it. // Instead of a hardcoded cadence... $schedule -> command ( 'subscriptions:reconcile' ) -> daily (); // ...read it from settings, with a sane default baked in. $schedule -> command ( 'subscriptions:reconcile' ) -> cron ( $this -> schedulerSettings -> reconcileCron ?? '0 2 * * *' ); Two things made this clean. First, a SchedulerSettings object (Spatie's settings pattern) so the values are typed, cached, and migratable — not loose rows you Setting::get('...') by string key. Second, grouping the more user-facing schedules behind their own modal rather than dumping every cron in one giant form. A subscription-related schedule belongs next to subscriptions; a platform schedule belongs in admin. Same data, but organized by who needs to touch it . The edge case to watch: a UI-editable cron is a foot-gun if you let people type nonsense. Validate the expression on save, and always keep a default so a blank setting can never silently disable a job. Thread 2 — A load-testing

Every time I opened a fresh session with my coding agent, it started from zero. Which repos am I working across? Which client is this for? Where did we leave off yesterday? I'd re-explain the same context, the agent would occasionally load the wrong project, and nothing I decided last week survived into this one. A "re-explain myself" tax on every single session. I tried the obvious fix first — a better prompt, a longer system message. It didn't hold. Context that has to persist can't live inside the chat; the chat is the thing that resets. What actually worked: give the agent a place outside the chat to read and write — and make it the most boring, durable thing I could. Plain files in a git repo. The substrate: markdown + YAML the agent reads at session start open-bridge is a plain git repo of markdown and YAML. At the start of every session the agent reads it, so it begins already knowing my world. No database, no SaaS, no daemon, nothing to host — the substrate itself runs nothing . It's just files the agent reads. That "just files" choice is the whole point: Agents can read a file but can't hold an API key. What I write today, the agent still reads in six months — no migration, no second app, no vendor lock-in. It's auditable. Clone it and cat anything the agent reads. No black box. It's model- and tool-agnostic. Plain text is something every agent runtime can read. A tiny slice of what that looks like (from the repo's examples/agency setup — fictional "Acme Dev"): # ecosystem.yaml — the repos/clients the agent should know about projects : bigcorp : { display_name : " BigCorp E-Commerce" , repos : [ bigcorp-api , bigcorp-frontend ] } startupxyz : { display_name : " StartupXYZ MVP" , repos : [ startupxyz-app ] } # work/board.md — generated from the task dirs, read every session ## Doing | bigcorp-api-payment-retry | incident | P1 | Stripe webhook retries failing | | startupxyz-onboarding | feature | P2 | guided signup flow | So when I say "good morning, briefing

"What time works for everyone?" is a surprisingly hard question to answer in code. You have to read each person's calendar, line up the busy blocks, respect working hours and time zones, leave buffer time between meetings, and only then find the gaps everyone shares. The Nylas Availability API does all of that in one request: hand it a list of participants and a window, and it returns the time slots that actually work. This post covers finding meeting times from two angles: the HTTP API for your backend, and the nylas CLI for the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I'm checking a calendar. Availability versus Free/Busy There are two endpoints here, and picking the right one saves you work. The Availability endpoint finds bookable slots across a group of participants, applying working hours, buffers, and meeting duration to return times you can actually book. Free/Busy is simpler: it returns the raw busy blocks for one or more email addresses over a window, leaving the slot math to you. Reach for Availability when the question is "when can these people meet?" and you want the answer as a list of open slots. Reach for Free/Busy when you only need to see when calendars are busy, for example to gray out times in a custom UI. Availability is a POST /v3/calendars/availability , an application-level call that takes participants by email, while Free/Busy is grant-scoped at POST /v3/grants/{grant_id}/calendars/free-busy . This post focuses on Availability, since that's the one that answers the scheduling question directly. Find a time across participants The core request lists the participants and the window to search. Each participant is identified by email and must be associated with a valid Nylas grant, since the endpoint reads their calendars. You set start_time and end_time as Unix timestamps for the search window, duration_minutes for how long the meeting is, and interval_minutes for how the candidate start times ar

Email is how most files still move between people: the signed contract, the PDF invoice, the logo embedded in a newsletter. If your app sends or processes mail, it has to handle attachments, and doing that against each provider means Gmail's attachment encoding, Microsoft Graph's, and raw MIME for IMAP. The Nylas Email API gives you one model for both directions: attach files to outbound messages with the same call you use to send, and pull files off inbound messages with a read-only Attachments API. This post covers both halves from two angles: the HTTP API for your backend, and the nylas CLI for the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I'm checking a file came through. Two APIs: one to attach, one to read There's a split worth understanding up front. You add attachments through the Messages or Drafts API, as part of sending or saving a message, and you read existing attachments through the dedicated Attachments API. The Attachments API is read-only: it downloads bytes and returns metadata, but it never adds files. That division keeps the model simple, since attaching is part of composing a message and reading is a separate concern. The size of what you're attaching decides how you encode it on the way out. Small files ride inline in the JSON request, larger ones move to a multipart request, and very large files use a separate upload step. On the way in, every attachment, regardless of how it was sent, is fetched the same way: by its attachment_id together with the message_id it belongs to. Get those two ideas straight and the rest is mechanical. Attach a small file inline with Base64 For files that keep the whole request under 3 MB, the simplest path is the application/json schema. You pass each attachment in an attachments array with its content_type , filename , and the file bytes as a Base64-encoded content string. The 3 MB ceiling covers the entire HTTP request, not just the file, so it's the right path for