标签：#community

I joined DEV in June and started doing what I have been avoiding for a long time. Now and then, I hit...

Hey everyone! I bring you my development journey on what I have discovered, accomplishments for this...

You know that moment when you're building an n8n workflow and realize: “Wait… does n8n already have a node for this?” Maybe you need a specific AI provider. Or a browser automation tool. Or some obscure database. Or a service that isn't part of n8n's core integrations. The first instinct is usually to reach for the HTTP Request node. But before writing API calls yourself, there's another possibility: Someone may have already built the node. That's one of the reasons I created Awesome n8n Community Nodes . The n8n ecosystem is bigger than it looks One of the best things about n8n is that it isn't limited to its built-in integrations. Developers can create community nodes and publish them as npm packages, extending n8n with new services, triggers, actions, AI capabilities, utilities, and more. The ecosystem has grown significantly. One existing ecosystem tracker had already indexed thousands of community nodes, showing just how quickly the space is expanding. That's great for n8n users. But it creates a new problem: Discovery. Having thousands of nodes is useful only if you can actually find the one you need. So I built a directory I created: Awesome n8n Community Nodes 🔗 https://github.com/bhavyshekhaliya/awesome-n8n-community-nodes It's an open-source, curated directory for discovering community-built n8n integrations and utilities. Instead of organizing everything as one massive list, I grouped nodes around what you're actually trying to automate. 🤖 AI, Agents & Search Looking for AI, LLM, search, agent, or AI-media capabilities? There's a dedicated section for that. 🌐 Browser, Web & Scraping Need browser automation, crawling, scraping, or web extraction? You'll find those together. 💬 Communication & Messaging WhatsApp, email, chat, notifications, and other communication-related nodes have their own category. 🗄️ Data, Storage & Observability Database, storage, infrastructure, monitoring, and data-related integrations live here. 📄 Documents, Media & Productivity For

The AWS Community Builders program opens applications once a year, typically in early January, and closes within about two weeks. That's a narrow window. If you're serious about the 2027 cycle, you have roughly four months from now to build the contribution track record that gets you selected. I wrote my personal story about getting into the program from Cameroon. This post is different. It's a practical, no-fluff guide covering how the program works, what the application actually asks, what reviewers evaluate (based on patterns from people who've been accepted and rejected), and how to prepare starting today. What the AWS Community Builders Program Actually Is AWS Community Builders is a global program that recognizes people who share AWS knowledge publicly. Not AWS employees. Not necessarily experts. Engineers, students, content creators, and community organizers who consistently write, build, speak, or contribute to open source around AWS services. The key word is consistently . This is not a certification you study for. It's recognition of a public track record of helping others learn and build on AWS. The program sits below the AWS Heroes program in AWS's community ladder. Heroes are veterans with years of visible impact. Community Builders is the accessible entry point, and for most engineers reading this, the realistic first target. It's free to apply. Membership runs in yearly cycles with renewal based on continued activity. The Categories (Pick One That Matches Your Work) When you apply, you select a technology category. For 2026 the categories were: AI Engineering : Building generative AI applications with Amazon Bedrock, prompt engineering, RAG, fine-tuning, agents Cloud Operations : Observability and configuration (CloudWatch, Systems Manager, Config, Service Catalog) Containers : ECS, EKS, Fargate, App Runner Data : Databases and analytics (DynamoDB, RDS, S3, OpenSearch, Redshift, Athena) Dev Tools : CI/CD, CDK, build pipelines, Application Composer Fro

When I became an AWS Community Builder, one of the things I was most excited about was getting the opportunity to experiment with AWS. Let me Introduce .... eventinary.com A Completly free event management software Like most developers, I had a long list of things I wanted to build. AI applications, serverless projects, agents, APIs — there was no shortage of ideas. The AWS credits made it easier to experiment without constantly thinking about the cost of every service I turned on. But after a while, I started asking myself a different question. What if I used those credits to build something that could actually give back to the community? That question eventually led me to Eventinary . I've always enjoyed technical meetups and community events. A meetup may only have a few dozen people in a room, but something interesting happens there. Someone learns about a technology for the first time. Someone meets another developer. Someone gets inspired to build something. Someone gives their first technical talk. The event may last only a few hours, but the impact can last much longer. Then I started looking at what happens behind the scenes. Organizers have to create the event, manage registrations and RSVPs, keep track of attendees, coordinate speakers, prepare schedules, communicate updates, and somehow keep everything organized. For larger events, the number of tools and spreadsheets can grow quickly. I thought, why not build a platform that makes this easier? That became Eventinary. At first, it was just another idea. Then I started building it. As the platform grew, I realized I didn't want to build another simple invitation or RSVP website. I wanted to create a proper digital event platform that could support the entire event experience. Today, Eventinary can help organizers with things like: Event creation and digital event pages RSVP and attendee registration Speaker and session management Event schedules and itineraries Guest and attendee management Event informat

TL;DR Welcome back to Dev Opportunity Radar. This is a weekly series where I share opportunities,...

It’s been almost 2 months on Dev.to, and I’ve learned a lot from this community. Not just knowledge,...

You heard me. Alright, that was mean lol. Though based on the title, you probably already knew the...

Eighty minutes into building with three people I had met that morning, I renamed the idea I brought with me. 21:05 Rename the product to Civiq and credit the team I wrote that commit message myself. By then the idea had four authors. Some context on the room. The Claude Impact Lab is part of Claude Community, the run of local events where people who use Claude get together in person. This one followed a Claude Conversation held earlier in Los Angeles, where people talked through what AI is doing to their jobs. The Impact Lab takes what came out of that conversation and turns it into a build day. You get the problem brief, you form a team, you have the day, you demo at the end. Travis Johnson, a Claude community ambassador, hosted with Evan Grenda at Intersections LA. Developers and non-developers both, and they meant it. What I brought was not a project. It was an idea and a spec for it. No code, nothing built, nothing running. The idea comes out of something that is true in most cities. Your city government publishes what it intends to do before it does it. Agendas go up ahead of the meeting, and any resident can read them, show up, and speak on an item before the vote. That right exists. Using it takes work, which is probably why every time I used it I would give up on what I was looking for. In Ventura it means 21 separate boards and commissions, each with its own page, posting PDFs that run long and read like they were written for the people already familiar with the subject matter. Because they were. So if you want to know whether anyone is voting on something a block from your house, you go looking, board by board, document by document. And you have to already know the words the city uses for the thing you would call a pothole. Agenda Watch was going to make all of that searchable in plain language, with every answer carrying a receipt back to the page it came from, so nobody has to take the tool's word for anything. In use that is a small thing. You ask a que

TL;DR Welcome back to Dev Opportunity Radar. This is a weekly series where I share opportunities,...

A few months ago I got properly bitten by the Linux bug. Ubuntu became my daily driver, I started digging into terminal tools way past the point of “practical necessity,” and I got obsessed with an idea that wouldn’t leave me alone: old hardware doesn’t have to die just because it’s old. I work as an on-site IT coordinator, handling day-to-day IT operations for an industrial company. Between that and years of general sysadmin work, I’ve watched a lot of perfectly usable machines get pulled out of service and shipped off as e-waste — not because they were broken, but because someone decided they were “too old” for whatever OS they were running. A Core 2 Duo with a fresh SSD and a lightweight distro can still be a genuinely useful computer.That gap between “technically obsolete” and “actually still works great” is where a lot of my curiosity lives right now. The gap I kept running into The more I looked into the Norwegian Linux scene, the more I found — Skolelinux/Debian Edu has deep roots here, NUUG (Norwegian Unix User Group) has been active for decades, and there’s a project called PC-Aid that collects, wipes, and reinstalls Debian Edu on used PCs, then sends them to schoolchildren in Ukraine. It’s been running for a few years now, quietly doing real, tangible good. I wanted in. But when I looked for any of this activity near me — Sunnmøre, a district on Norway’s west coast (in Møre og Romsdal county, home to the town of Ålesund) — there was nothing. No local NUUG chapter, no meetup, no group. Just… a gap. (If you’re not from Norway, don’t worry, most Norwegians would need a map for this too.) So instead of waiting for someone else to fill it, I started SLUG — Sunnmøre Linux User Group. Reaching out, awkwardly, like you do Starting a group is the easy part. Getting it to mean anything is harder. So I did the obvious thing: I found people who’d actually been part of PC-Aid and reached out. First was someone who’d been active in the project early on. I sent a message

📌 TL;DR I'm still early in my own career, and lately I've been thinking about how much advice we...

Yes! this was about 12 years ago, when I was just a little 10 year old girl. I was very lazy even...

TL;DR Welcome back to Dev Opportunity Radar . This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss. This week's edition features the Claude Community Ambassadors Program , the YC Startup Internship Expo , Z Fellows , and CS329A: Self-Improving AI Agents , a free graduate-level Stanford course exploring the latest research behind modern AI agents. If you're new to the series, you can also browse previous editions, search past opportunities, and explore Community Finds , Reader Updates , and Resources Worth Checking Out on the Dev Opportunity Radar website . I've also written a short post about why I built it. You'll find links to both at the end of this article. This week's 🌟 Community Finds section features opportunities shared by Francis ( @francistrdev ) and Konark Sharma ( @konark_13 ) . I always love seeing readers help others discover opportunities they might otherwise have missed. If you've discovered something through the radar, I'd love to hear about it. Whether you applied to an opportunity, attended an event, joined a community, completed a program, built something, or found a resource you hadn't seen before, I'd be happy to feature your experience in a future 💙 Reader Updates section (with your permission). And if you've come across an opportunity, resource, community, program, event, or anything else you think deserves more attention, feel free to share it in the comments. If I feature one of your 🌟 Community Finds in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you. Table of Contents ⚡ Quick Scan 🔄 Still Open From Previous Editions 📍 This Week's Opportunities 📌 Claude Community Ambassadors 📌 YC Startup Internship Expo 📌 Z Fellows 📚 Resources Worth Checking Out CS329A: Self-Improving AI Agents 🌟 Community Finds CALEC Volunteer and Internship Opportunities JP

On Monday I published a piece admitting that my deploy verification tolerates sixty seconds of "not there yet" for a reason I couldn't defend. Three retries, twenty seconds apart. I picked twenty because it was the first interval where my false alarms stopped, my sample was about three deploys, and I had never once recorded how long propagation actually takes. I made three commitments in that piece. A birth certificate for the constant. A rule fixed before the run it judges. And the one that mattered most: emit the value, not just the verdict — a check that prints only pass or fail hides the exact signal that would tell me it's miscalibrated. I did the third one that afternoon. Every deploy since writes down how long it took to go green. Three samples in: Aug 03 ( 1.7, 21.7 ]s Aug 05 ( 0, 6.7 ]s Aug 05 ( 40, 70 ]s They're intervals rather than points because my poll spacing is twenty seconds. All I can honestly say is that green happened somewhere between the last failed check and the first successful one — a number I can't resolve finer than my own instrument. The third one failed Not the deploy. The check. I shipped a post, ran verification, and got a clean red: page 404, hero missing, sitemap entry absent. Three attempts, twenty seconds apart, exactly as designed. By its own rules the deploy had failed. Nothing was wrong. A longer script came back 200 on everything. Total elapsed: somewhere between forty and seventy seconds, against a tolerance of sixty. So the false alarm I widened the interval to eliminate returned on the third recorded sample, four days after I published the sentence "my sample was about three deploys." I'd like to say I predicted this. I predicted the category, not the timing, and the timing is the part that stings. The part I hadn't considered at all Here's what the red actually said, in order: attempt 1 article 404 · hero missing · list page MISSING · sitemap missing attempt 3 article 404 · hero missing · list page OK · sitemap missing The

I keep seeing this same tension play out everywhere. TikTok, Instagram, X, all over the tech corners of the internet. It's the fight between software engineers and vibe coders, and tbh, I get both sides of it. Let me take the engineers' side first, because they're not wrong. If you spent four plus years learning to actually code, grinding the fundamentals, learning why the thing works and not just that it works, then yeah, I understand the frustration. Someone opens up Claude or ChatGPT, writes a prompt, ships their first app, and calls themselves a software engineer. And half the time, the second they hit a real problem, the whole thing falls over, because they don't actually know what's under the hood. I'd be a little annoyed too. And real talk, nothing replaces that depth. An engineer who can reach into the code, read it, and understand exactly what every line is doing is on a different level than someone vibe coding their way through. That's just true. But here's the part that sits weird with me. The problem isn't people using AI to build. It's when it turns into a wall. When the message becomes "you're not allowed in here, you don't get to build the thing in your head, because you didn't earn it the right way." That's the part I don't buy. I've watched this play out with my own friends. Engineers on one side, the ones just getting into vibe coding on the other, and there's this real contention between them. Almost a running joke about who counts and who doesn't. I think big ideas come first. The imagination comes first. Then you go find the resources, or the people, or the tools to actually build it. If someone has a huge idea and AI is the thing that finally lets them build it without waiting for permission, I don't see a problem. I see someone building. Gatekeeping who gets to make things never made much sense to me. You can respect the craft and still leave the door open. Those two aren't in conflict. Just my take.

A few weeks ago I killed an indicator of mine in public. I had been trying to work out how much of my audience was automated. One signal was whether an account had uploaded its own avatar. It fired on 100% of the accounts I was confident were people and 97% of the ones I suspected were not. That isn't a lenient signal. It isn't separating anything — it tracks something both groups share, and I had been counting its votes for weeks. I wrote that up. Named the defect, retired the indicator, moved on feeling like I'd learned something. Three days later I shipped another one. The same hole, in a different shape I needed to check whether a comment on one of my posts was actually visible to readers — I'd found one the API returned and the comment count included, but that moderation had removed. So I wrote a check: // v1 — passes for anyone with a second comment on the page. Zero separation. visible : html . includes ( comment . user . username ) // v2 — the only witness with jurisdiction over one comment. visible : html . includes ( comment . id_code ) Two comments from the same account, one removed and one live, both came back visible under v1. I found it by accident, and only because I happened to compare against something else. Someone in a thread put the problem in a sentence I couldn't argue with: if the fix is "I noticed this one," the next indicator ships with the same blind spot in a different shape. Which is, word for word, what I had already written about the previous defect. Their prescription was structural. A labeled control set shouldn't be a diagnostic you run when something feels off. It should be a permanent seed every indicator has to clear a margin on before it's allowed to vote — not just beat chance on the live population, which is exactly the condition that let the avatar signal pass silently. Building it Twenty-eight accounts. Fourteen labeled human, fourteen automated, and every label carries a provenance string saying how it was established — seve

Two numbers from my own systems, side by side. When I deploy, a check confirms the pages are actually live. It retries three times, twenty seconds apart, so it tolerates up to a minute of "not there yet" before calling anything wrong. When my monitor decides whether production is down , it waits five seconds and retries once. The check that guards the more consequential claim is the more impatient one. I did not decide that. I never compared them. Until last week I had never seen those two numbers in the same place, and neither had anything else. Where the numbers came from The deploy one has an origin story I'd have told you proudly a week ago. I shipped nine pages, then checked the URLs immediately instead of trusting the CLI's success message. Four returned 404. Nothing was broken — CDN propagation — and twenty seconds later all nine were 200. A single check at the wrong moment would have told me, with total confidence, that a perfectly good deploy was broken. So I wrapped it in a retry loop. Three attempts, twenty seconds apart. Problem solved, and it even sounds like engineering. Here is the part that isn't. I picked twenty because it was the first interval where the false alarms stopped. My sample was about three deploys. I have never recorded how long propagation actually takes. I widened the tolerance until the red went away, and then I wrote about it as if I'd learned something. Someone in a thread named this before I saw it: a tolerance chosen that way is the same muting I'd been criticizing, relocated inside the assertion where it reads as rigor instead of avoidance. The test I was given, and the answer I didn't want In that same thread I speculated that my deploy tolerance was probably leaking into my outage detector through a shared helper. It sounded plausible and I said it like a finding. The reply was sharper than the guess: that's a falsifier, not evidence. Here's the concrete test — do the two checks consume the same retry policy or threshold confi

I want to talk about what I have notice on the platform and want to address what we all have been...