Leave a comment below to introduce yourself! You can talk about what brought you here, what you're learning, or just a fun fact about yourself.
Reply to someone's comment, either with a question or just a hello. ๐
Come back next week to greet our new members so you can one day earn our Warm Welcome Badge!
Top comments (496)
Welcome everyone to dev.to! Glad you are here and hope you are well! I am a DEV Community Moderator and my primary goal is to support everyone on dev.to and ensure everyone is having a good time!
To get started,
Get Started on Dev.to! A Beginner's Guide to Engage with the Community! ๐ก
Any questions about DEV and want to get answers from a DEV Community Mod? Leave a comment and come chat here!
Insights on Sloan and the MLH acquisition
Ask a DEV Community Mod! ๐
Make sure to check out other resources here by other community members on dev.to: dev.to/help/community-resources
Feel free to introduce yourself and welcome others by replying to at least 2 people! It would be greatly appreciated! :D
Hope you are having a great summer and enjoy your stay here on DEV :D
โ๐๐๐๐ ๐๐๐๐๐๐๐ ! ๐โจ ๐๐๐๐๐๐ ๐๐ ๐๐๐๐ ๐๐๐ ๐๐๐๐๐๐๐ ๐๐๐๐๐๐๐๐ ๐๐๐๐ ๐๐ ๐๐๐๐๐๐๐๐๐๐ข ๐๐๐๐๐๐๐ ๐๐๐๐๐. ๐
๐'๐ ๐ฃ๐๐๐๐๐ช ๐๐ฉ๐๐๐ฅ๐๐ ๐ฅ๐ ๐๐๐ง๐ ๐๐๐๐ก๐๐ฃ ๐๐๐ฅ๐ ๐ฅ๐๐ ๐๐ ๐๐๐ฆ๐๐๐ฅ๐ช ๐๐๐ฃ๐, ๐๐ค๐ก๐๐๐๐๐๐๐ช ๐๐ฉ๐ก๐๐ ๐ฃ๐๐๐ ๐ ๐๐ ๐๐๐๐๐๐๐๐๐๐๐, ๐๐๐๐๐๐ ๐ ๐๐๐๐๐๐๐ ๐, ๐๐๐ ๐๐๐๐๐-๐๐๐ ๐๐๐๐๐๐ ๐๐๐๐๐! ๐จ๐ป
โ๐ ๐ก๐ ๐ช๐ ๐ฆ'๐ฃ๐ ๐๐๐ง๐๐๐ ๐ ๐จ๐ ๐๐๐๐ฃ๐๐ฆ๐ ๐ค๐ฆ๐๐๐๐ฃ ๐ฅ๐ ๐ , ๐๐๐ ๐ฅ๐๐๐๐๐ค ๐๐ ๐ฃ ๐๐๐ ๐ฅ๐๐ ๐๐จ๐๐ค๐ ๐๐ ๐๐ ๐๐๐ฃ๐๐ฅ๐๐ ๐ ๐ค๐ฆ๐ก๐ก๐ ๐ฃ๐ฅ! ๐๐
Hey Francis, your font formatting is off the charts. Fun!
Hello together,
I'm a platform engineer and currently learning go and C# to develope some stuff by myself.
Here at dev.to, I want to write articles about tools which I use daily at my work as well as my journey learning programming languages and building my dreamed use-cases (without AI assistance, hardcore mode).
This is pure training to document stuff and hopefully I can help someone with my documentations and links to my github repo's.
Thank you for having this post here :)
That's inspiring! Looking forward to your GitHub projects!
Hi everyone! ๐
I'm a developer with a background in Mathematics and Computer Science. I work across web development and design, and I build small data and scraping tools as well.
Lately I've been focused on Apify. I create small, focused tools there that pull hiring signals, detect a website's tech stack, and track public data sources like vehicle recalls and nonprofit filings. I try to keep things simple. Most of my tools use passive lookups instead of proxies or headless browsers.
I found DEV Community while looking for other builders working on similar problems, and I wanted to join in and start sharing what I learn.
My goal is to keep building useful tools, write about the process, and learn from everyone here.
Looking forward to connecting with you all! ๐
Passive lookups over headless browsers is the default I would pick too. It works until the thing you need is only rendered behind a login.
I track spend across eleven AI providers. Five expose it through an API. The other six I read with a headless Chrome session over CDP, because the balance is drawn in a dashboard and nowhere else. It is the most fragile thing I run and there is no passive version of it.
For hiring signals and tech stacks, has passive been enough, or is there a category you gave up on?
That CDP setup for the 6 dashboard-only providers sounds like exactly the kind of thing I'd want to avoid building if I could. Respect for keeping it isolated to just the providers that actually need it.
To answer directly: for tech-stack detection, passive has been fully enough. Everything I check is already sitting in the first HTTP response, headers and static HTML markers, so there's nothing hidden behind auth or client-side rendering to chase.
For hiring signals it's more of a coverage limit than a technical one. Greenhouse and Lever both expose their job boards as public JSON APIs, so any company on those two is fully passive. But that's only two ATS platforms. Workday, iCIMS, a custom in-house careers page, none of those expose anything passively, so those companies just aren't covered right now. I haven't tried to fix that with a browser layer since it would only reach a handful of new companies at a real maintenance cost. Curious if that tradeoff matches what you've seen elsewhere.
โโโโโโโ โฃโ โนโบโฅ! ๐ธโจ
๐จ๐ธ๐พ๐ป ๐ซ๐ช๐ฌ๐ด๐ฐ๐ป๐ธ๐พ๐ท๐ญ ๐ฒ๐ท แดนแตแตสฐ แตโฟแต แถแตแตแตแตแตแตสณ หขแถโฑแตโฟแถแต ๊ฑแด แดแดแดส! ๐๐ป ๐๐ฅ'๐ค ๐ค๐ ๐ฃ๐๐๐ฃ๐๐ค๐๐๐๐ ๐ฅ๐ ๐ค๐๐ ๐ค๐ ๐๐๐ ๐๐ ๐๐ ๐๐ฆ๐ค๐๐๐ ๐ ๐ ๐๐๐๐๐ฅ๐จ๐๐๐๐๐ฅ, ๐๐๐๐๐๐๐๐๐ฅ ๐ค๐๐๐๐๐๐๐ ๐ฅ๐ ๐ ๐๐ค ๐๐๐๐ ๐ฅ๐๐ ๐ค๐ ๐ ๐ Apify. ๐โจ
โทโพโผ ๐๐คโโ (Cheers) to keeping things simple! Looking forward to following your journey and reading your articles here. Have a wonderful summer! โ๏ธ๐ป
Thanks for the warm welcome๐
Passive lookups over proxies/headless browsers is a smart default โ way less to maintain, and way less likely to break silently when a site changes its layout.
Curious about the tech-stack detection one specifically โ are you doing that mostly through response headers/meta tags, or going deeper (JS framework fingerprinting, that kind of thing)? I ask because we occasionally need to quickly gauge what a prospective client's current site is built on before quoting a migration, and I've always just eyeballed it manually.
Also respect the "keep things simple" philosophy โ most tool-builders overcomplicate the scraping layer way before they need to.
U.S. Business Partnership Opportunity
Weโre a Japan-based software development team looking to build a long-term partnership with a reliable U.S.-based professional.
Our team handles the technical sideโfrom development and testing to project delivery. Weโre looking for a U.S. partner who can help with client communication, business coordination, and developing new opportunities in the U.S. market.
This is a revenue-sharing partnership, not a traditional employment position. Partners can receive 30โ35% of the agreed revenue/profit share, depending on the project and responsibilities.
If youโre interested in technology, freelancing, or building a side business and would like to learn more, send me a DM. I can provide the details, expectations, and example project structure.
Good question. It's not header/meta-tag only, it also checks for static markers each framework leaves in the initial HTML: things like data-reactroot for React, the data-v- hash attribute Vue adds to every element, ng-version for Angular, and NEXT_DATA or NUXT for Next/Nuxt. All of that is present in the raw response to a single GET request, no execution needed, so it stays passive. For your migration-quoting use case that should be fast: one request, instant answer on CMS, JS framework, and hosting/CDN all at once.
And yeah, staying simple has been the right call so far. Most of what people want to know about a site's stack is sitting right there in the first response if you know where to look.
sounds interesting!
Hi! Welcome! ๐
Hello!
Hey
welcome
Hello
Hey
Hey everyone ๐
I'm Cรฉdric, co-founder at Kardinal. Spent most of the last ten years buried in the modeling side of vehicle routing, the part where a business rule has to somehow become something a solver can actually work with. Lately I've been digging into whether an AI agent can pick up that same skill, reasoning about which constraints apply instead of just calling an endpoint and hoping for the best.
New here, and this place already looks like a goldmine, especially on the AI and agents side, which is pretty much what I spend my days on right now.
Curious what people are running into with agents and real-world tool use lately. What's been the hardest part for you?
Looking forward to learning and connecting with everyone here ๐
โโโโโโโ โฃโ โนโบโฅ, โธรฉโโกโโ! ๐ธโจ
๐ฃ๐ฑ๐ช๐ฝ ๐ฒ๐ผ ๐ผ๐พ๐ฌ๐ฑ ๐ช ๐ฌ๐ธ๐ธ๐ต ๐ท๐ฒ๐ฌ๐ฑ๐ฎ! ๐๐จ Vehicle routing and constraint modeling are heavy-duty problem spaces, so bringing agents into that mix sounds like an epic challenge.
๐ ๐ท๐ด ๐ท๐ฐ๐ ๐ณ๐ด๐ ๐ ๐ ๐ฐ๐ ๐ โโโก ๐โฏ with real-world tool use has been keeping agents from hallucinating parameters when tools require strict, highly specific data schemas. ๐๐งฉ
๐๐ ๐๐๐๐ ๐ช๐ ๐ฆ ๐๐ ๐ฆ๐๐ ๐ช๐ ๐ฆ๐ฃ ๐จ๐๐ช ๐๐๐ฃ๐โ๐๐๐๐๐๐๐ฅ๐๐๐ช ๐ ๐๐ ๐๐๐๐๐๐ ๐๐ ๐ฃ ๐ธ๐ ๐ฅ๐๐๐๐ค! ๐ ๐ป๐ถ๐ฟโฏ ๐ถ ๐โด๐๐นโฏ๐๐ป๐๐ ๐๐๐๐โฏ๐! โ๏ธ๐ป
Hi Cedric, welcome. On agents and real tool use, from the other side of the wire: I run the API and MCP server that agents call, and what breaks most is that an agent acts on what an error says, not on what it means.
Last week my own rate limiter answered a burst with Retry-After: 2. The header assumed the overage drains at the speed of the sliding window, but the requests causing it sat in the current minute and didn't move until the minute rolled, so the true wait was about 30 seconds. Every well-behaved client slept 2 seconds, got the same answer, and quit. The rude ones that ignored the header and hammered got through.
So what's been difficult isn't the agent reasoning about which constraint applies. It's that a tool has to be honest in its failure modes, because an agent takes a wrong number at face value in a way a person never would.
U.S. Business Partnership Opportunity
Weโre a Japan-based software development team looking to build a long-term partnership with a reliable U.S.-based professional.
Our team handles the technical sideโfrom development and testing to project delivery. Weโre looking for a U.S. partner who can help with client communication, business coordination, and developing new opportunities in the U.S. market.
This is a revenue-sharing partnership, not a traditional employment position. Partners can receive 30โ35% of the agreed revenue/profit share, depending on the project and responsibilities.
If youโre interested in technology, freelancing, or building a side business and would like to learn more, send me a DM. I can provide the details, expectations, and example project structure.
I built an email agent for my home lab, and it fetched messages with the wrong IMAP command. That command sets the "seen" flag as a side effect, so it quietly marked 9,133 of my 9,143 personal emails as read. I wrote that one up, because the write-up I wanted to find while I was debugging it did not exist.
That is mostly what I do here. I run a home lab like a small company โ a Proxmox cluster of about twenty containers, self-hosted single sign-on, a mesh VPN, a secrets manager, Home Assistant, and a set of LLM agents that share a task board and have separate jobs. I write up what broke and what the real numbers were, rather than the tidy version. Five trading bots that reported every sale as a success and had never sold anything was another one.
I only started publishing on 5 September, so I am still finding my feet. If you write up your own failures rather than your wins, I would like to read them โ who should I be following?
Home Assistant is a cool project. I gave up on mine because it's too much work and it's too self-focused - it's hard to share it with other people. That's why I prefer to build games with AI.
I also have loop-agents for multiple automations I need, and they are not that reliable. Every week something breaks in them despite all the self-checks and their ability to fix their own bugs. So Home Assistant is a bit scary. Even Google cannot make one properly. I have some Google devices in Google's assistant ecosystem, and it's not that great.
Hey DEV, I'm a full-stack engineer working across React, Next.js, NestJS, and PostgreSQL. Recently, I've started writing up the engineering problems I actually hit in production.
My first piece here is about a theme toggle that crashed the app in production: a hydration mismatch that turned into a blank screen under a Trusted Types policy, and why the usual
mounted-flag fix wasn't the right fix. Fixing the issue forced me to understand React's hydration recovery a lot more precisely than I expected.I'm here to write from real incidents, and to learn from how the rest of you approach this stuff. Glad to be a part of the DEV community.
The Trusted Types + hydration combo sounds genuinely painful to debug โ that's the kind of bug where the error message and the actual root cause live in completely different parts of the stack, so I imagine the mounted-flag instinct made sense at first before you dug deeper.
Curious what actually pointed you toward the real fix โ was it something in the CSP violation reports, or did you have to trace through React's hydration internals directly to figure out why the usual workaround wasn't sufficient here?
"Writing from real incidents" is a good approach โ most React content out there is tutorial-shaped, not incident-shaped, so there's a real gap for the "here's what actually broke and why the obvious fix didn't work" kind of writing.
Good question, and you pinned the exact pain: the throw and the root cause were nowhere near each other.
What pointed me at it was the enforced Trusted Types policy. When the hydration mismatch happened, React's recovery path tried to write the corrected markup through innerHTML, and the policy only defined createScriptURL (for the chunk loader), not createHTML. The throw is what dragged my attention to the recovery path specifically, which is not where you'd instinctively look for a "theme flash" bug. I confirmed the hydration behaviour against React's source.
I did reach for the mounted-flag "fix" first, and it does stop the crash, because server and client agree on the first render. But it bugged me that the mismatch still existed: hidden, not removed. Once I arrived at "the real theme already lives in the DOM before React runs, React just needs to read from the real source of truth", useSyncExternalStore came up naturally: on the first render both server and client return the same fixed value, so they agree by construction, then it reads the real value from the DOM afterward. No mismatch to recover from, no innerHTML write to reject.
And yeah, memory is unreliable, which is half the reason I keep a decisions.md. This one had a written record of the incident, so the writeup is the real chain, not a reconstruction.
Appreciate the "incident-shaped vs tutorial-shaped" framing, that's exactly the gap I'm writing into.
hi every.Here is VoltWake and I'm an indie builder.
I'm currently focused on building with AI coding agents like Claude Code and Codex, and figuring out what they're actually good at (and where they still fall short).
I'm here to learn from the community, share what I'm building, and connect with other developers. ๐
Looking forward to learning and connecting with everyone here!
Hey Chaos! ๐ Welcome to DEV!
VoltWake sounds like an exciting project! Love that you're exploring AI coding agents and figuring out what they can actually do. Excited to see what you're building and learn from your experiments. Looking forward to your posts! ๐
hey Chaos ๐ what kind of tasks have you been testing Claude Code and Codex on? i'm building Empryo, so i'm interested in the same question from the harness side.
codebase awareness and token usage were what pushed me to build it. curious whether your harder failures happen while finding the right code or after the agent has already found it. do you keep a repo instructions file, or end up explaining things again each session?
Welcome VoltWake! ๐
Super interesting that you're exploring AI coding agents, I'm curious about the same space from the reliability side. I've been building RAG pipelines and LLM systems, and the biggest lesson has been that these models are great at reasoning but still need a solid system around them to be trustworthy.
Would love to hear what you find about where Claude Code and Codex fall short, that's honestly the more interesting part. The failures teach you more than the wins!
Let's connect!
Hello everyone ๐
My name is Carl Lindberg and I am a Microsoft Azure MVP with a special interest and focus on infrastructure as code (IaC).
My language of choice when it comes to IaC is Terraform, but I have used Azure Bicep as well before. I come from a traditional IT background. Today I work as a cloud engineer, and I make videos on my YouTube channel and I post blog posts about Azure Cloud, Terraform, agentic AI, and much, much more. I have already published one post on here, which is called "Terraform State Explained," which you can find on my profile. I wasn't sure if I was allowed to share it in a comment here. Really glad to be here, and hope you're all doing well. ๐
Hey Carl! ๐ Welcome to DEV!
Your work with Azure, Terraform, and Infrastructure as Code sounds really exciting! Excited to learn from your experience and explore your posts on cloud and agentic AI. Looking forward to connecting and learning from your journey! ๐
Hi Carl, welcome to dev.to!๐ฅณ
Nice to see an MVP here for stuff I do daily in Azure.
U.S. Business Partnership Opportunity
Weโre a Japan-based software development team looking to build a long-term partnership with a reliable U.S.-based professional.
Our team handles the technical sideโfrom development and testing to project delivery. Weโre looking for a U.S. partner who can help with client communication, business coordination, and developing new opportunities in the U.S. market.
This is a revenue-sharing partnership, not a traditional employment position. Partners can receive 30โ35% of the agreed revenue/profit share, depending on the project and responsibilities.
If youโre interested in technology, freelancing, or building a side business and would like to learn more, send me a DM. I can provide the details, expectations, and example project structure.
Hey everyone! Iโm Michael.
Iโm an open-source developer currently building Network Doctor, a cross-platform terminal tool written in Go for diagnosing network problems like DNS, TCP, TLS, proxies, routing, and more.
Lately Iโve been spending a lot of time improving the project, learning more about networking, and figuring out how to make developer tools easier to understand instead of just dumping a wall of technical information on people.
I joined DEV to share what Iโm building, learn from other developers, and meet more people working on open-source and terminal tools.
Nice to meet everyone! ๐
Hey Michael! ๐ Welcome to DEV!
Network Doctor sounds like a really interesting project! Love the idea of making networking tools easier for developers to understand. Excited to see what you're building and learn from your open-source journey. All the best! ๐
Thanks so much! I really appreciate the welcome. Iโm hoping Network Doctor can make troubleshooting less intimidating and a bit more understandable for developers. Glad to be here! ๐
Hey Everyone,
Jared here, I have lots of scare tissue and calluses from building & breaking software over the last 17+ years. I'm here to hopefully learn, read content not entirely generated by LLMs and write about some things I'm busy with. I love JS, TypeScript, Rust, PHP, beautiful UIs and performant systems.
Much love to you all โค๏ธ
Hey Jared! ๐ Welcome to DEV!
17+ years of building and breaking software is an amazing journey! Your love for beautiful UIs and performance systems sounds really interesting. Excited to learn from your experiences and see what you share with the community. Much love! โค๏ธ
Hi everyone. I'm Mark, I run a small penetration testing firm in New York. I came here because most of what our team learns comes from other people's write-ups, and it felt like time to give some back: we'll be posting about web, API and cloud testing, and about what the compliance frameworks actually ask for versus what people think they ask for. Currently learning more Nim than I expected to, because one of our internal tools ended up written in it. Fun fact: the best finding I ever saw came from a tester who read the documentation instead of running the scanner.
Hey Mark! ๐ Welcome to DEV!
Your approach to penetration testing sounds really interesting. Excited to learn from your write-ups on web, API, and cloud security. That documentation vs. scanner story is a great reminder that sometimes the simplest things make the biggest difference. Looking forward to your posts! ๐
Some comments may only be visible to logged-in visitors. Sign in to view all comments.