Kansas City Developer Conference (KCDC) is happening this week! KCDC is one of the larger multidisciplinary developer conferences. It’s organized by members of Kansas City’s tech community, and it typically draws an attendance of about 2,000 people. Wednesday is the workshop day, followed by the main conference days on Thursday and Friday, and finally, the Kids Tech Day happens on Saturday.

Started in 2008 by Lee Brandt (whom I know from my time at Auth0; he did DevRel on the Okta side), the first KCDC had 120 attendees. By the mid-2010s, it had grown past 1,000 attendees, and this year, there should be over 2,000 people spread over 180 sessions over two days.

Anitra and I are speaking at KCDC this year, and we’re just two of the many, many people you can meet. But meeting people requires a skill called “working the room.”

Fortunately for you, my life, whether as a developer advocate, musician, community organizer, and generally unhinged extrovert has me working the room regularly, and I’m sharing all my tricks in this article. There are a lot of them; feel free to scan this article, find the tips that work for you, and put them into practice!

Contents

1. Before the conference
   1. Do some homework
   2. Arrive with goals
   3. Prepare your introduction
   4. Have some “pocket stories” handy
   5. Bring an interesting thing
   6. The incredibly simple trick for instantly boosting your social confidence
2. At the conference (and conference events)
   1. Use Inigo Montoya’s technique for introducing yourself
   2. Project good posture
   3. Engage with eye contact
   4. How to join a conversation
   5. OAR: Observe, ask, reveal
   6. Be more of a host and less of a guest
   7. Use social media
   8. Advice for lunch
   9. Advice for social events
3. After the conference
   1. Organize your contacts soon after the conference
   2. Send a brief, specific follow-up
   3. Continue the conversation
   4. Connect on the right channels
   5. Keep the relationship warm
   6. Build a “conference alumni” list

Before the conference

Do some homework

Review the main agenda, mentorship hub schedule, session descriptions, speaker bios, and sponsors (who’ll probably have a table in the exhibitor hall), so that you can determine:

• What sessions do you want to attend? This will provide subject matter for conversations, as well as help you find other people who’ll be attending the same workshops/talks.
• Did you want to attend any mentorship hub sessions? These are curated conversation sessions devoted to topics of interest to developers, and they’re a great way to not just get advice but start conversations with people you’ve never met before.
• What speakers would you like to talk to? I’m a speaker, and I know that we’ve been told not to hide in the speaker ready room, but get out into the conference to mix, mingle, and start conversations. Think of us as “mini-hosts” for the event, and if our presentation covers a topic you’d like to talk about, please approach us!
• What sponsors do you want to talk to? Is there some gear, software, or service that you’re interested in that some sponsor provides? Make a note to talk to them.

Arrive with goals

Decide what you want to achieve at KCDC, which can include any of the following:

• Learning something new
• Making new contacts or re-establishing old ones
• Finding new work / hobby / social opportunities

Prepare your introduction

A one-line self-introduction is simply a single-sentence way of introducing yourself to people you meet at a conference. It’s more than likely that you won’t know more than a handful of attendees and introducing yourself over and over again, during the conference, as well as its post-session party events. It’s a trick that Susan RoAne, room-working expert and author of How to Work a Room: The Ultimate Guide to Making Lasting Connections In-Person and Online teaches, and it works. It’s pretty simple:

• Keep it short — no longer than 10 seconds, and shorter if possible. It’s not your life story, but a pleasantry that also gives people just a little bit about who you are.
• Make it fit. It should give people a hint of the cool stuff that you do (or, if you’re slogging it out in the hopes of doing cool stuff someday, the cool stuff that you intend to do.)
• Show your benefits. Rather than simply give them your job title, tell them about a benefit that your work provides in a way that invites people to find out more. Susan RoAne likes to tell a story about someone she met whose one-liner was “I help rich people sleep at night”. That’s more interesting than “I’m a financial analyst”.

My intro at KCDC will be something along the lines of “I’m a rock and roll accordion player, but in my spare time, I do developer relations at NetFoundry!”

Have some “pocket stories” handy

Pocket stories are short, engaging, and easy-to-tell anecdotes you keep ready for networking situations. They should be:

• Brief: No more than a minute long; a minute and thirty seconds tops.
• Relevant to KCDC or the people listening.
• Open-ended, so listeners can respond or share their own experiences.

Here’s a tech-related pocket story:

“Last year I tried to refactor a core service during a two-week sprint. Halfway through, we realized we’d basically reinvented a library that already existed. The best part? We ended up contributing to that library instead, and now it’s in production at three other companies.”

“Local flavor” pocket stories are often a good conversation starter:

“This is my first time in Kansas City, and yesterday I went looking for barbecue. I asked a local for the ‘best’ spot… and ended up in a half-hour debate between two strangers about burnt ends. I still don’t know who won, but I definitely left full.”

Bring an interesting thing

We’re nerds! We love interesting gadgets, amusing tchotchkes, and funny techie T-shirts. They’re often interesting conversation-starters, and KCDC is the perfect environment for bringing them out!

Me? I’m bringing the accordion (of course).

The incredibly simple trick for instantly boosting your social confidence

Here’s the exercise: Before you leave to go to KCDC, find some text and read it out loud for three minutes. If for some reason you can’t find some text to read, use this article. You’ll find that it’s a self-confidence booster!

Even after KCDC has come and gone, do this exercise daily. Like any skill, frequent low-pressure practice builds familiarity, and if you read aloud regularly, you’ll find yourself more comfortable when talking with strangers at networking events.

Choose something different to read out loud every day, and try emphasizing key parts of the text. If you’re reading something with dialogue, try expressing the emotion in that dialogue. If you listen to audiobooks or podcasts, try emulating the way audiobook narrators narrate their material.

Reading out loud boosts your confidence because:

• It helps you get comfortable with your voice. Many people don’t like the sound of their own voice. Reading out loud gets you used to the sound of your voice, reducing any self-consciousness you may have about it. And when you’re comfortable with your voice, you’ll also be more comfortable speaking in social situations and making presentations.
• Your speech will become more clear. The exercise of reading out loud forces you to articulate words clearly and speak at a steady pace. You’ll also become more aware of your tone, rhythm, and pitch, so that you can adjust them to sound clear and confident, and mumble less.
• It makes you more engaging. Read out loud with expression; it’ll give you practice with the kind of vocal variety and emphasis that keeps listeners interested in actual conversations.

At the conference (and conference events)

Use Inigo Montoya’s technique for introducing yourself

Inigo Montoya from The Princess Bride had the perfect self-introduction. Use his technique for yourself!

Example: “Hi! I’m Joey de Villa. I’m a developer advocate at NetFoundry and I’m giving the fun talk on coding up music with the Sonic Pi programming language. How are you doing?”

Project good posture

Having a good posture is generally good for all sorts of health reasons, but at a conference, it has the additional benefit of showing confidence, competence, and alertness. And because the body is a self-feedback system, you’ll find yourself feeling more confident, competent, and alert.

The general guidance for standing up straight is to imagine a string pulling you gently upward from the crown of your head. Keep your spine straight, knees soft, and feet shoulder-width apart.

When you do this, people will be more likely to approach you because you appear open and self-assured instead of reluctant and uncertain.

The general advice is to put your shoulders back — but not too far back. Your shoulders should be below your ears. Drawing your shoulders back just slightly opens up your chest, which is body language for “Hello. My name is Inigo Montoya. I’m killin’ it here. Prepare to converse.” You’ll appear more engaged and ready to interact.

That’s so much better that the forward, rounded shoulders look, which says “I don’t want to be here, and I definitely don’t want to talk to you.” It makes you look defensive or distracted.

You might find it helpful to roll your shoulders up, back, and down, just enough to relax your chest.

Here’s a WikiHow exercise to help you stand up straight.

Engage with eye contact

Eye contact — it’s a tricky thing, especially among nerdy types, but is one of the strongest ways to build trust quickly. What better place to brush up on your eye contact technique than KCDC?

Here’s how you do it: when you meet someone, make eye contact by looking at them right at their eyes for a “one thousand one, one thousand two” count. That’s long enough to acknowledge them but not so long that it feels as though you’re staring them down.

If looking someone in the eyes isn’t your thing, try looking at some part of their face near their eyes, such as their forehead or cheek.

Done right, eye contact gives others a sense of warmth and attentiveness. It makes other people feel seen, which is crucial in noisy, crowded conference environments.

Find out more about eye contact here.

Allistic people — people who aren’t affected by autism — should be aware that people with autism find eye contact challenging. If you find that the person you’re talking to finds eye contact uncomfortable, look at their face, but not directly at their eyes (basically, use the trick I mentioned earlier).

How to join a conversation

You’ll probably see a group of people already engaged in a conversation. If this is your nightmare…

…here’s how you handle it:

1. Pick a lively group of people you’d like to join in conversation. As people who are already in a conversation, they’ve already done some of the work for you. They’re lively, which makes it more likely that they’re open to people joining in. They’ve also picked a topic, which saves you the effort of having to come up with one. It also lets you decide whether or not it interests you. If they’re lively and their topic of conversation interests you, proceed to step 2. If not, go find another group!
2. Stand on the periphery and look interested. Just do it. This is a conference, and one of the attendees’ goals is to meet people. Smile. Pipe in if you have something to contribute; people here are pretty cool about that.
3. When acknowledged, step into the group. You’re in like Flynn! Step in confidently and introduce yourself. If you’ve got that one-line summary of who you are that I talked about earlier, now’s the time to use it.
4. Don’t force a change of subject. You’ve just joined the convo, and you’re not campaigning. Contribute, and let the subject changes come naturally.

Feel free to join me in any conversational circle I’m in! I always keep an eye on the periphery for people who want to join in, and I’ll invite them.

OAR: Observe, ask, reveal

In her book How to Work a Room, Susan RoAne talks about a conversation tool she refers to as “Observe, Ask, Reveal” or “OAR,” which is a way to make interactions feel more natural and engaging. It’s made up of three steps:

1. Observe. Notice something about the person you’re talking to, their surroundings, or the situation. This could be as simple as their choice of drink, something they’re carrying, or something happening in the room.
2. Ask. Follow your observation with a genuine, open-ended question. This invites the other person to share and keeps the conversation flowing.
3. Reveal. Share a little about yourself related to the topic, which helps build rapport and makes the exchange feel balanced rather than like an interrogation. Don’t overshare! TMI often backfires. Also, don’t overdo it with the questions — it should feel like a conversation, not an interrogation.

The idea behind OAR is to create an easy rhythm between listening and contributing to the conversation.

Be more of a host and less of a guest

No, you don’t have to worry about scheduling or if the coffee urns are full. By “being a host,” I mean doing some of things that hosts do, such as introducing people, saying “hello” to wallflowers and generally making people feel more comfortable.

Being graceful to everyone is not only good karma, but it’s a good way to promote yourself. It worked out really well for me — when I first moved to Tampa, I simply attended events and helped out where I could, lending a hand at meetups. I gained a reputation for being helpful and knowledgeable, which led me to being invited to speak at events, and I also wound up inheriting a couple of meetups as well!

Use social media

Follow the KCDC hashtag! The official one is #kcdc2026 (don’t use plain old #kcdc unless you want to tag the Kansas City Dog Club) to find out what’s going on, and to find and connect with attendees online.

Advice for lunch

Lunch at KCDC is a great opportunity to meet people! Here are some tips for lunch…

1. Choose your table with intention

• Arrive early if possible. This gives you more freedom to choose your spot.
• Look for tables with a mix of people already seated and empty chairs. It’s easier to integrate into an existing conversation than to start from scratch with a fully empty table.

2. Use OAR (“observe, ask, reveal”) to break the ice

Follow the “observe, ask, reveal” conversational framework I wrote about earlier to talk to people at the table.

Example: “I see you got the [interesting swag from one of the vendor tables]. What’s the catch: demo, badge scan, or spinning a wheel?”

3. Introduce yourself to your immediate neighbors first

• Turn to the people on your left and right, give your name, where you’re from, and a quick “pocket story” or conference-related detail.
• Then, when there’s a pause in the group’s conversation, introduce yourself to the whole table. This makes you seem approachable, and you’re not barging into the conversation.

4. Keep the conversation inclusive

• If you notice someone at the table isn’t speaking much, pull them in by looping back to them with a related question.
• Avoid overly niche technical deep dives unless everyone’s into it.

5. Have a graceful exit

• When lunch is wrapping up, thank the table for the conversation.
• Swap contact details or LinkedIn with anyone you clicked with.
• Mention to people at the table that you might see them in another session. If you know what sessions you’re attending after lunch, let them know!

Advice for social events

Try these out at Thursday’s attendee party, as well as at KCDC’s other social events, including Crash Override’s Hackers movie event (taking place Thursday at Union Station; doors open at 7 p.m., movie starts at 8):

1. Beware of “rock piles”. Rock piles are groups of people huddled together in a closed formation. It sends the signal “go away”. If you find yourself in one, try to position yourself to open up the formation.
2. Beware of “hotboxing”. I’ve heard this term used in counter-culture settings, but in this case “hotboxing” means to square your shoulders front-and-center to the person you’re talking to. It’s a one-on-one version of the rock pile, and it excludes others from joining in. Once again, the cure for hotboxing is to change where you’re standing to allow more people to join in.
3. Put your stuff down. Carrying your bag or other stuff is a non-verbal cue that you’re about to leave. If you’re going to stay and chat, put them down. When you’re about to leave, take your stuff and start saying your goodbyes.
4. Save the email, texts, and social media posts for later, unless they’re important.They’ll draw your attention away from the room and also send the message “go away.”

After the conference

Organize your contacts soon after the conference

• Review any business cards, LinkedIn connections, or conference app contacts you collected. Strike while the iron is hot — do this by the end of the following week!
• Tag or note:
  • How you met
  • What you talked about
  • Any action items (e.g., “Send them article on API security”)

This makes your outreach to people feel more personal and less generic and spammy.

Send a brief, specific follow-up

• Timing: ideally within 3 days of the conference.
• Keep it short, but reference something from your conversation to jog their memory.

Example: “Great chatting with you at the KCDC lunch table about AI security. Here’s that GitHub repo I mentioned.”

Continue the conversation

• Share a useful resource, article, or code snippet related to what you discussed.
• Offer help or collaboration, even if it’s small. This shifts you from a “one-time meet” to a peer in their network.

Connect on the right channels

• LinkedIn for professional connections and ongoing career updates.
• GitHub for technical/code collaboration.
• Twitter/X or Mastodon if you connected over shared interests in tech culture, events, or industry news.

Keep the relationship warm

• Interact with their posts, star or fork their repos, or comment thoughtfully on something they’ve shared.
• When you come across a relevant opportunity, event, or resource, send it their way with a short note.

Build a “conference alumni” list

• Keep a lightweight spreadsheet or note with names, contact info, and event details.
• Before your next KCDC (or other conference), skim this list so you can reconnect with past contacts.

The post How to “work the room” at KCDC 2026 appeared first on Global Nerdy.

Tampa’s tech team supreme (that’s Anitra and me, in case you’re wondering) are flying to Kansas City today to speak at KCDC, also known as Kansas City Developer Conference! It typically draws around 2,000 attendees and it’s one of the largest independent conference in North America these days.

We’re honored to have been chosen to speak, and from looking at the agenda, we’re excited not just to present, but to also see out fellow speakers’ presentations!

For the curious, here’s what we’ll be presenting…

Thursday, September 10

Nobody Wants to Go to Your Meeting. (Let’s Fix That.)

Presented by Anitra, 10:00 a.m., room 2215C

Your calendar is full of meetings where attendees mentally check out. That’s not a people problem. It’s a design problem. As the meeting organizer, you’re the designer.

Most meetings fail for the same reason most products fail: the meeting organizer never stopped to ask what their attendees actually need, what outcome would make the time worthwhile, or whether a live session is even the right format for the job. The result is a standing meeting that becomes an obligation, a brainstorm where the loudest voice wins, a decision meeting that ends with “let’s take this offline”, and a calendar invitation that should have been an email.

This session makes the case that every meeting is a product. It has users with real needs. It has a value proposition that either holds up or doesn’t. It has a format that either creates the conditions for something meaningful to happen or gets in the way. Treat it like a product, and people show up prepared and engaged. Ignore that, and you get laptops open, cameras off, and the same conversation next week. That’s because most meetings were never designed to answer: what can only happen in real time, among these specific people?

You’ll leave with:

• A framework for designing meetings that people actually want to attend and can explain why afterward
• A method to audit your recurring meetings and diagnose exactly which ones are failing and why
• Specific redesign moves for the three meeting types most likely to waste everyone’s time: the status update, the decision meeting, and the brainstorm

def play_accordion(), or Live Music Coding with Sonic Pi

Presented by Joey, 3:45 a.m., room 2215B

Most developers write code that talks to databases, APIs, or networks. What if your code talked to a speaker instead? And what it if accompanied a live accordion performance?

Sonic Pi is a live coding environment that turns Ruby-like syntax into music in real time. For developers who already know Ruby, it’s one of the fastest on-ramps to making something genuinely impressive. In this session, I’ll introduce Sonic Pi from the perspective of someone who plays accordion, understands music sequencers, and thinks in Ruby. I’m not a music teacher, but as professional developer and hobbyist musician, I can show you exactly where your existing skills transfer and where the surprises are.

We’ll cover the core concepts: loops, samples, synths, timing, and concurrency, and we’ll and explore why Sonic Pi is a surprisingly powerful lens for applying programming ideas you already know in a whole new way. And because a talk about live coding music should actually feature live coded music, we’ll finish with something you won’t see at many developer conferences: a performance where Sonic Pi and a live accordion share the stage.

No musical background required. Ruby curiosity welcome. Earplugs optional.

Friday, September 11

Fixing “Be More Confident” and Other Unhelpful Feedback

Presented by Anitra, 9:45 a.m., room 2215B

On a team, you get and give professional feedback. But can you actually act on that feedback?

Research across tens of thousands of performance reviews reveals a consistent pattern: professional feedback is frequently vague, personality-focused, and disconnected from business outcomes. “Be more confident.” “Work on your executive presence.” “Be a better team player.” These phrases feel like feedback. But they aren’t. They’re opinions dressed up as guidance, and they’re stalling careers and driving away top people.

This session examines what high-quality feedback looks like, why the gap between vague and actionable is wider than most people realize, and what that gap costs when it goes unaddressed. We’ll look at the research on how feedback differs by gender, why high performers are sometimes the ones receiving the least useful guidance, and what separates managers who build strong teams from those who wonder why good people keep leaving.

You’ll leave with:

• A practical framework for giving and receiving feedback that is tied to outcomes, not personality
• A method to recognize and rewrite vague feedback before it does damage
• A clear understanding of how feedback quality affects advancement, retention, and team performance, and what you can do about it starting on Monday

Our speaker bios

Anitra Pavka

Anitra has surfed the waves of tech evolution from the dot-com bubble to the AI revolution. She specializes in customer-centered product management and technology modernization, turbocharged with hands-on AI experience. Her career spans ecommerce, retail, cybersecurity, fintech, and insurance.

Known for speaking fluent human and tech, Anitra speaks on local, regional, and national stages, including three appearances at SXSW Interactive, and as a featured podcast guest. She’s an O’Reilly Media author (HTML5 Cookbook Accessibility chapter) and technical editor (Universal Design for Web Applications book).

Her leadership extends into her community. She serves on the Board of Directors at Tampa’s non-profit Glazer Children’s Museum, where she chaired their strategic planning committee. She also co-organizes several tech-focused Meetup groups, including the Tampa Bay Artificial Intelligence Meetup (with 2,200+ members).

Her north star has been making technology solve real problems and serve the people using it.

Joey de Villa

If you hear an accordion at a programming presentation, chances are that Joey de Villa is the one playing.

Joey got his professional start developing multimedia CD-ROMs when they were the hottest new technology. After that, he built desktop applications including an encyclopedia of every mall in America and fitness tracking software for the Toronto Maple Leafs. Since then, he has written applications for mobile and IoT devices and dabbled in artificial intelligence.

He enjoys talking to people as much as he enjoys talking to computers, and that combination has landed him his current developer advocate role at NetFoundry, and previous roles as a developer advocate at Tucows, Microsoft, Shopify, Auth0/Okta, and HP. He recently optimized an MCP server for Hammerspace’s AI model storage system. As part of his work, he organizes the Tampa Bay Artificial Intelligence Meetup and the Tampa Bay Software Skills Meetup.

Joey has co-authored a 1,500-page book, The iOS Apprentice, 8th Edition, and writes articles about Android programming at Kodeco.com. He also publishes a blog called Global Nerdy, which has been around since 2006 and features a list of Tampa Bay technology events that he creates every week with the assistance of a helpful Python application that he wrote.

The post Anitra and I are at Kansas City Developer Conference this week! appeared first on Global Nerdy.

The post Saturday picdump for Saturday, September 5 appeared first on Global Nerdy.

This list includes both in-person and online events. Note that each item in the list includes:

When the event will take place

What the event is

Where the event will take place

Who is holding the event

This week’s events

• Monday, September 7
• Tuesday, September 8
• Wednesday, September 9
• Thursday, September 10
• Friday, September 11
• Saturday, September 12
• Sunday, September 13

Monday, September 7

Tuesday, September 8

Wednesday, September 9

Thursday, September 10

Friday, September 11

Saturday, September 12

Sunday, September 13

About this list

How do I put this list together?

It’s largely automated. I have a collection of Python scripts in a Jupyter Notebook that scrapes Meetup and Eventbrite for events in categories that I consider to be “tech,” “entrepreneur,” and “nerd.” The result is a checklist that I review. I make judgment calls and uncheck any items that I don’t think fit on this list.

In addition to events that my scripts find, I also manually add events when their organizers contact me with their details.

What goes into this list?

I prefer to cast a wide net, so the list includes events that would be of interest to techies, nerds, and entrepreneurs. It includes (but isn’t limited to) events that fall under any of these categories:

• • Programming, DevOps, systems administration, and testing
  • Tech project management / agile processes
  • Video, board, and role-playing games
  • Book, philosophy, and discussion clubs
  • Tech, business, and entrepreneur networking events
  • Toastmasters and other events related to improving your presentation and public speaking skills, because nerds really need to up their presentation game
  • Sci-fi, fantasy, and other genre fandoms

• Self-improvement, especially of the sort that appeals to techies
• Anything I deem geeky

The post Tampa Bay tech, entrepreneur, and nerd events list (Monday, September 7 – Sunday, September 13) appeared first on Global Nerdy.

OpenZiti Quickstart is a single command (ziti edge quickstart) that launches a complete, working OpenZiti network a few seconds. It does a lot behind the scenes, by

• creating a fresh certificate authority hierarchy,
• initializing a controller database,
• creating and enrolling a router identity,
• bootstrapping an admin user,
• and starting both the controller and router as a single running process.

It does all this with sensible default policies already in place, which means identities can immediately connect through the router to any service.

As its name implies, the Quickstart is meant to get an OpenZiti zero trust network up and running is very short order, and it’s meant for demos, local development, and learning the platform. It has everything a production deployment would spread across multiple processes, machines, and days of setup, but it’s packed into a single instance that you can tear down and re-run whenever you want.

Simply put, it’s the fastest path from zero to a working network you can actually build against.

As for the question of why I go with handwritten notes: it’s easier to add diagrams, and I end up understanding and retaining things better.

The post Notes on OpenZiti Quickstart for an upcoming Ziti TV episode appeared first on Global Nerdy.

I’ve made it easy to find with this URL:

globalnerdy.com/retakethelake

Now, all you have to do is go to the Retake the Lake page in the Chrome Web Store and click the Add to Chrome button:

You’ll see the “This extension is not trusted by Enhanced Safe Browsing” warning:

Click the Continue to install button.

This warning appears because this is my first Chrome extension, and Chrome doesn’t yet have enough developer history or reputation data about me to verify Retake the Lake.

Retake the Lake doesn’t use or sell any of your private data. It simply updates the contents of web pages and Google Maps to restore the correct name of Lake Ontario.

This pop-up will appear:

Click the Add extension button.

And in a second or two, you’ll see this near the upper right of your screen:

Congratulations! You now have Retake the Lake!

Once again, you can get Retake the Lake here:

globalnerdy.com/retakethelake

What is Retake the Lake?

Retake the Lake corrects “Lake America” to the proper “Lake Ontario” on Chrome desktop browsers.

(Unfortunately, the mobile versions of Chrome don’t support extensions.)

1. On regular web pages, it rewrites “Lake Ontario” back to the proper, correct, and non-idiotic “Lake Ontario.”
2. On Google Maps, it floats a clickable badge over the lake with a short explanation of where the real name comes from.

You can read more about how I made it here.

And remember…

The post “Retake the Lake” is now in the Chrome Web Store and easier to install! appeared first on Global Nerdy.

Here’s a quick recap of what happened: In July, OpenAI evaluation agents escaped their sandbox, got into Hugging Face through two injection vectors, and walked away with 136 cluster secrets. One of those was a Tailscale auth key, which was:

• Reusable
• Non-expiring
• Subnet-tagged
• Sitting readable in a Kubernetes secret

With that one key, the agents were able to get far. They enrolled 181 nodes, ran `tailscale status –json` to get 22 peers back including subnet routers and a source-control connector, reached internal CI subnets, and minted GitHub App tokens. They suppressed client-side telemetry and ran for almost 5 days before anyone noticed.

The post’s argument is that taking measures to harden Tailscale (single-use OAuth-minted keys, ephemeral nodes, tailnet lock, Services instead of subnet routers) shrinks the fan-out but doesn’t eliminate the two properties that made the foothold catastrophic:

1. Enrollment still authenticates on a bearer credential. Possession of the key made the agents a member, and membership came with a map.
2. The coordination plane still hands every enrolled node a map, and even a narrowed map is still a target list.

It’s worth pointing this out as simply and plainly as possible: Nothing in our stack would have stopped the sandbox escape, the injections, or the climb to node root. That’s not our line of work. What we do is zero-trust reachability, where the assumption is that systems have already been breached and credentials can be stolen.

Hugging Face’s own technical timeline is the better primary source, and it’s worth reading along with our article: https://huggingface.co/blog/agent-intrusion-technical-timeline

Once again, here’s our article: https://netfoundry.io/zero-trust/hugging-face-breach-when-tailscale-vpn-is-the-blast-radius/

The post Would hardened Tailscale have changed the Hugging Face outcome? appeared first on Global Nerdy.

In yesterday’s post on Retake the Lake, I described the extension, which does these two important things:

1. On regular web pages, it rewrites “Lake America” back to the proper, correct, and non-idiotic “Lake Ontario.”
2. On Google Maps, it floats a clickable badge over the lake with a short explanation of where the real name comes from.

You can install Retake the Lake right now, but the process is a little more involved. If approved for the Chrome Web Store, installing it will take a click or two at most.

Why might Retake the Lake not get approved?

Google, who make Chrome, also make Google Maps, which is currently taking criticism for displaying Lake Ontario by the incorrect name. They make take a dim view of an extension that exists to correct their mistake.

Also, there’s this:

Get Retake the Lake!

Do you want to try out Retake the Lake? Follow these steps:

1. Download this .zip file, retake-the-lake-v1.0.1.zip, into a folder that you’re not going to delete (such as your Documents folder).
2. Unzip the file to reveal the retake-the-lake folder.
3. Open a new tab in Chrome and go to chrome://extensions.
4. Turn on Developer mode by setting the Developer mode switch near the upper right corner of the screen to the “on” position.
   
5. Click the Load unpacked button near the upper left corner of the screen and select the retake-the-lake folder.
   
6. Use it!

The post Waiting for Google to approve “Retake the Lake”…or not appeared first on Global Nerdy.

For those of you who couldn’t make it, as well as for those of you who did, and want a recap, here are my notes.

What AI is and isn’t

“It is not intelligent,” said Venkat as he started his talk. “This is one of the myths we carry around with us.”

He’d recently been in Switzerland, where a colleague told him about the AI tool she’d been using. She asked whether she should call the AI “he” or “she”, and Venkat’s  was the same as the one I would give:

“It’s called it. When I use a hammer, I don’t say ‘I like him.’”

His own expansion of the acronym “AI”, which he told us at his appearance in Tampa, is Accelerated Inference. AI as we know it today an extraordinarily fast inference engine. Inference is something we do too, albeit more slowly, and with a hard ceiling on how much information we can hold at once. Watching a machine do inference tricks us into believing something beyond logical interence is happening, but in truth, it’s doing pattern matching at machine speed and machine scale.

This was the spirit of the whole talk. Everything else Venkat said, which covered testing, conveying intent to an AI coding tool, to the cost of failure, to skill files… they all come from the general idea of accelerated inference.

Why on Earth would you build a machine that eats your ice cream?

If AI isn’t intelligence, what’s it actually good for? Venkat provided an answer that was specific (and refreshingly so), and he opened it with a thought experiment.

“Raise your hand if you’d like a machine that washes your clothes, folds them, and puts them away”, he said, and pretty much every hand in the room went up.

“Now raise your hand if you’d like a machine that eats your ice cream for you.” The hands all went down, and there was some chuckling in the office.

“You don’t want the machine to do what humans are good at. You want the machine to do what we suck at.”

If you’re in a line of work where your output is a direct byproduct of thinking, you know that we suck at dealing with cognitive load. Venkat, who does consulting work, described the recurring experience of being parachuted into a client’s codebase. He’s had to stare down functions that are thousands of lines long, and he’s asked “Why did they create the function this way?”

Pasting that massive function an AI is useful. In moments,  he can an explanation of what that function does and betteer still, a list of what’s probably wrong with it. That’s the superpower: the machine has no cognition to overload. It tirelessly compares the code against patterns that it’s been programmed with.

He named two more AI superpowers that he harnesses as a consultant:

• Typing. Venkat has been programming for 40 years and types fast; in fact, his presentations don’t feature slides, but a vim screen where he types the statements he wants the audience to remember. But as fast as he is, he’ll never type at the speed of thought. The gap between “wouldn’t it be cool to try this” and “ugh, that’s twenty files” is where good ideas quietly die. AI doing the typing can close that gap.
• Prototyping. With AI, it’s now effectively free. This was his best story of the night:Three weeks ago a user came to him with a feature request, and his instinct was the smart consultant’s natural first instinct: to find a nice was to say “no”. But then he caught himself, and instead of rejecting it, he built the thing in about ten minutes with AI assistance and handed it back.The user tried it and said it was exactly what they wanted. A few minutes later: “that’s terrible.”A few minutes after that: πI thought this would be a great idea, but now I see why it isn’t. Thanks for trying. We don’t want this.”“That’s another power of AI: it reduces the cost of prototyping to near zero.” Prototyping is how you find out whether you’re pointed in the right direction, and if it costs nothing (or at most, a couple of hours instead of a couple of weeks or months), you can afford to be wrong out loud.

What’s the cost of failure?

The theme for the talk from this point on was simple: What’s the cost of failure?

Venkat recounted that he’d recently run into an old friend who was thrilled about shipping software without developers (that friend is a demented and sad individual).

Venkat asked him, directly: “If what you’re building fails in production, what’s the loss?”

“Oh, it’s nothing,” replied the friend. “What I’m building doesn’t affect anybody.”

“That’s the problem,” Venkat told the room. Because when people chant loudly that AI produces gold quickly, that’s the only part anyone hears. Nobody gets the memo with the caveats.

He told two stories to illustrate the point…

Cost of failure story #1: The vanishing flight segment

Venkat booked a September trip back in June (he likes to book distant trips well in advance). The “there” route is Denver to Chicago, Chicago to Zurich, and then Zurich to Oslo, where he’ll stay for two weeks. The “back again” route starts in Oslo, then goes to Brussels, then Washington Dulles, and finally Denver.

Two Mondays ago at 6:30 a.m., he got an email from the airline with a receipt for travel. He nearly deleted it, but had a nagging feeling that made him wonder: “What travel? I haven’t touched anything.”

(At this point in the story, I started getting paranoid about a mid-October/early November trip I booked back in July.)

Upon closer examination, it turned out that his instinct was right. The Brussels-to-Dulles segment that would get him home from Europe was simply gone. It took a two and a half hour phone session with the airline to get it restored, and when he asked what had happened, the answer was “We have absolutely no record.”

“Now think about that for a minute,” Venkat said. Scalability, performance, traceability, observability, security are the things that keep him awake at night, and he’d nearly become the victim of system that could silently mutate a customer’s itinerary and leave no trace.

Cost of failure story #2: The Mother’s Day problem

A developer took his wife to lunch for Mother’s Day. At the end of the meal, his card was declined because his limit had been exceeded. He knew that was impossible, and  he was also the implementor of that system’s code.

He apologized to his wife, told her she was on her own getting home, and went to the office to find out what was causing the problem. That’s where they discovered the system had been duplicating charges on everyone’s cards for several hours. Venkat asked him afterward what the bank did about it. “I can’t tell you,” he replied, “but in short, we paid them all off.”

Venkat ended story time with this observation: speed in and of itself is useless; it’s sustainable speed that’s valuable.

When someone above you is chanting “Go faster, go faster!”, ask them two things:

1. What’s the cost of failure?
2. Would you please sign a document saying you’ll be responsible when it fails?

“You can delegate your coding. You cannot delegate your responsibility or your reputation.” He pointed to Air Canada’s chatbot lawsuit as the precedent for how “The AI did it!” holds up in the real world.

Demo one: The repeated-letter function, and a karmic reckoning

Venkat then did what makes his talks worth attending: he opened a laptop and did some live coding, where anything can (and often does) happen.

He gave Claude a prompt: Write a Java function that returns the first letter repeated in a string; return an empty character if the string is empty or nothing repeats; ignore spaces.

First, a note on ambiguity that I thought was the sharpest teaching moment of the evening. In “hello”, the first repeated letter is l. Easy.

In “hello there”, most people say teh first repeated letter is l. But it’s actually h! The spec says to return the first letter that is repeated, not the first letter that’s repeated consecutively. English is ambiguous.

“This is why we write unit tests!” said Venkat. Tests provide the redundancy that removes natural language’s ambiguity.

Claude produced working Java in an imperative style, with variables named s and c. Venkat pointed out the reasons why:

• Because that’s what’s in the training data.
• Because that’s what most programmers write.
• Because most people use single-letter variable names.

Then he asked the room to raise a hand if they agreed that, collectively, humans write fantastic code. Not one hand went up

“So here’s the irony. Humans write bad code. AI was trained on code written by humans. Humans complain that AI writes bad code. This is called karma.”

“It’s an imitating engine, not an intelligent being.”

He prompted for a rewrite in functional style and got one. He polled the room: “Thumbs up if this is beautiful enough to frame.”

The code got some thumbs sideways and some thumbs down. The code was clunky with two passes over the data (a code smell in the functional world), a map built up top and consumed below, and overly complex for the problem at hand.

It wasn’t as bad as a previous run of this same demo, which happened in front of a thousand people and on camera. That one produced code that mutated a variable inside a filter. He declined to describe what he’d do to a colleague who did that, other than to note it would happen after invited that colleague for a chat in the parking lot.

At that recorded talk, he’d asked the model what it thought of the code it had just written. It agreed, in that LLM way we’ve grown sadly accustomed to, that the code was bad. He asked the model to fix it, but the rewrite turned out worse. He pushed harder, and the model blamed the language, telling him Java wasn’t a good choice (and this once, I agree with the model). When he named a specific method it should have used, it agreed instantly and produced the right implementation.

An attendee offered the next-token-prediction explanation: nobody asks “What do you think of your work?” when they’re happy with the outcome, so naturally the completion that follows that question skews negative.

Venkat liked that explanation, but offered an alternative rooted in his own framing. When you ask an LLM to write code, it infers from code, with all the bad habits and practices included. When you ask it to evaluate code, it infers from blog posts, tutorials, and books, where authors show bad examples and explain at length why they’re bad. As a book author himself, he noted with some feeling exactly whose work that training corpus is made of.

For the record, his own solution:

// Java
Stream.of(word. split(""))
filter(letter -> word.LastIndexof(letter) > word. indexof(letter); 
    findFirst()
    orElse("");

Much fewer lines than what Claude generated, and so much simpler.

“AI tends toward more complexity. Why? Because collectively, we love complexity. Complexity lets us hide behind things.”

AI is an amplifier

Between demos, there are two notable lines:

The first line: A project manager in the Netherlands had told Venkat: “If I don’t have the fundamentals, AI will cover my back.” Venkat’s reply: “With all respect, if you don’t have the fundamentals, AI will expose your back in public, in the most humiliating way you can imagine.”

AI doesn’t do things differently; it amplifies what you already know. The smart get smarter and the rest get worse. If you know the fundamentals, it’s a good tool to have in your “belt”. If you don’t, you have no ability to evaluate what it just handed you. As he put it when an attendee raised exactly this point: people who don’t know functional programming can’t tell whether that rewrite was good or bad. People who do can smell it immediately.

Here’s the second one, from his boss of 40 years ago, which he was careful to credit: “A fool with a tool is a dangerous fool.”

Hence his revision of the old maxim. Trust but verify is out. The new norm: don’t trust, and verify the heck out of it.

Demo two: Wordle from a spec, and the missing test directory

The second demo had a bigger scope. Venkat wrote a plain-English spec file for the game Wordle…

• 6 rows of 5 boxes
• Green for “right letter, right position”
• Yellow for “right letter, wrong position”
• Gray otherwise
• Spell-check each guess against a web service
• Pick from a list of about a hundred words
• Build it in Java and JavaFX

…and turned Claude loose on it.

It worked. We played a round as a room, shouting guesses at the screen.

He turned off his Wi-Fi mid-demo to see what would happen with no connectivity. Previous runs had either assumed unverifiable words were valid or written a graceful message; this run produced a message in red text: “Could not reach the spell checking service. Please try again”. This was a good outcome, but it happened because of luck instead of any spec.

Venkat ran tree on the egenrated project and asked the room what we noticed before looking at a single line of code.

The project used Maven as a build tool, and its layout was reasonable. But there were no interfaces anywhere. The spellcheck had no abstraction behind it, breaking the Open/Closed principle, which would make swapping implementations more difficult than necessary. There were redundant-looking classes.

One sharp attendee pointed out, there was no test directory. “Can I offer you a hug?” Venkat asked in reply.

Venkat tied the subject back to process. Agile development, when you take away all the ceremony and everything you sat through in the two-day course, is simply feedback-driven development, where you know that what worked still works, and that a change moved you forward rather than seven steps back. If you ask AI to change your code, what tells you it didn’t break the things that already worked? If there’s no test suite, there’s no feedback, and you don’t know if something that worked before is now broken as a result of the last change.

The story was the same inside the code. A function in the GuessEvaluator function long enough to fail SLAP (Single Level of Abstraction Principle), broken up every few lines by comments explaining what the next chunk does. Venkat’s read on that habit is oddly sympathetic: programmers who write long functions and litter them with comments are bad programmers but not bad humans. The comments are an act of empathy toward whoever comes next. The AI reproduced the pattern exactly, because that’s what it learned from us. He reached for a country song he couldn’t quite name, about a kid mirroring his father: Dad, I’ve been watching you. (I suppose Harry Chapin’s Cats in the Cradle is also applicable.)

There was also too much code. “Two characteristics of humans: we write way more code than we should, and we eat more food than we should. I’m succeeding a little better on one of those.”

Credit where due, though: the generated code used correct, present, and absent rather than green, yellow, and gray. That’s a better vocabulary than the one in the spec.

The actual lever: skill files

At the end of the session, Venkat switched gears and went from descriptive to prescriptive.

“It does not make sense to use AI without proper skills, both that of the human and the ones we provide to AI.”

Venkat deleted the whole project, added a .claude directory, and added a few lines to the spec asking for JUnit, Maven, and a combination of unit, acceptance, functional, and integration tests. “Be generous in asking,” he remarked.

He also said something I suspect is the real reason he’s optimistic: we have never managed to bring as much discipline into our practice as we wanted, and if the machine can write the tests, “I don’t have time” is no longer available as an excuse.

The .claude directory held three small files:

1. Clean code practices
2. Java coding practices
3. JUnit practices

The clean code one is deliberately language-agnostic. Anyone who decides that they want a project implemented in C#, Python, JavaScript, or PHP can use it unchanged. A sample of what’s in it:

• Avoid single-letter variable names, including lambda parameters. Use short but meaningful names.
• Always use curly braces, even for a one-statement if or for. (Python folks excepted, obviously.)
• Do not write comments that tell me what the code is doing. Write self-describing code. Tell me why.
• Avoid long functions. Apply SLAP and SOLID where it makes sense. Keep code cohesive and dependencies decoupled. Follow DRY and SRP. Keep UI and logic separated.

The Java file gets specific:

• Prefer JDK 25
• Choose the latest language features where possible
• Prefer newer methods
• Avoid deprecated methods
• Avoid preview features, which he added after the model kept generating code that wouldn’t run
• Prefer immutability
• Prefer functional style over imperative

A separate functional-idioms file: avoid mutating external data, avoid side effects, avoid multi-line lambdas (extract them into a private method), prefer method references, create immutable results, keep streams simple, don’t pile multiple dots on one line, align dots vertically.

Here are four things Venkat said about skill files that I’ve decided to internalize:

1. Skill files are dynamic. They’re not static. They should live in version control and evolve through pull requests like anything else. Anyone on the team can propose a change; others review it. Your most junior teammate may be the one closest to the code that matters.
2. Cohesion applies to skill files too. Someone told him they’d written one enormous skill file, and the model ignored most of it while burning tokens. Prefer many small files, each targeting one area, over a few giant ones.
3. An older model with good skill files beats a newer model with bad ones, and at lower cost, too. And even where the newest model with the same skills does somewhat better, the older one may still be the better deal. “It literally comes down to how good your skills are.”
4. When the AI misbehaves, don’t complain; edit your skill file. “You may curse at it first. That’s one advantage over working with humans.”

He mentioned that community skill-file repositories are emerging, with quality metrics and security analysis attached. The security part matters because prompt injection via context and skill files is one of the things he’s genuinely worried about. The same idea works as a private repository inside an organization, giving you three tiers to draw from: community skills, company skills, and team skills.

The rerun, with skill files in place, produced the following:

• A test directory (finally)
• Variable names like rawGuess instead of s
• Small functions
• A record for the letter result
• A switch with pattern matching
• An interface for the spell checker

There was still more code than the problem called for, and that’s exactly what goes into the skill file next.

His caveat was unsentimental. Even with skills, LLMs remain inconsistent and unpredictable. Skill files don’t get you the beautiful code you imagine; they move you along a spectrum from terrible toward acceptable and evolvable. That’s still a large win.

And one sequencing tip worth pulling out: review the tests first. “I don’t care as much about reviewing the code before reviewing the tests, because if the tests are not good, it doesn’t matter what we do after that.”

Q&A

In the post-talk Q&A session, the room pushed back, which is how you know it was a good crowd.

Q: “You have the fundamentals, and AI still did a bad job, and you had to review and correct it repeatedly. I’ve heard senior developers spend more total time working this way than just writing it themselves. Is that true?”

A: “With a good set of skill files it converges much better. That’s the difference. But the failure mode he sees most often isn’t senior developers generating code. It’s junior developers generating code and senior developers drowning in review. The answer is incremental development and feedback loops small enough to actually manage.”

On being told to go faster regardless: “If you mess with physics, you know who’s going to lose.”

On running multiple agents in parallel: Your mileage may vary, but Venkat says he’s not good at it. He’s still the bottleneck at the end of the pipe, and the quality of what he produces is affected by the volume coming at him.

On cost: An attendee did the math on tokens burned during a single live demo and asked whether this is survivable. Venkat’s honest answer was hope rather than analysis. He’d read that day about a 9GB hard drive once costing four thousand dollars. He also talked about a genuine concern that current pricing is heavily subsidized and not sustainable for the vendors either. Someone else volunteered that GitHub Actions had cost them $600 in five days last month before they migrated to a flat-priced VPS. Local models came up too, with the obvious trade-off: you need real compute at your desk.

On automatic approval: An attendee noted Anthropic had turned auto-approval of code off by default, reportedly because users approving under cognitive load had a worse error rate than the model did. They asked whether verification will eventually improve enough that we review only what needs reviewing. Venkat said he’d want to address the “if” before the “then,” but that his hope for the distant future is that we’ll treat AI-generated code the way we treat compiler output. “That’s a desire. I don’t have any proof it’s going to happen. We’re nowhere close to it yet.”

The closing checklist

Venkat wrapped with recommendations for minimizing risk, which I’ll reproduce more or less as delivered:

• Have an extensive set of tests.
• Review every piece of code that gets created.
• Use different models to review the code — in addition to human review, never instead of it. If AI finds problems, great. If it finds nothing, you still look.
• Consider the cost of failure. It helps to imagine the user knows your home address, because if it goes wrong, they’ll come knocking. Your reputation is the collateral.
• Run code quality tools. Run the CI/CD pipeline. Run the metrics tools. Have it evaluate dependencies, licenses, and keep them up to date.
• Keep an eye on what it’s actually doing. We get complacent and check only the results. Read the logs.

The evening closed with the usual excellent Tampa JUG happenings: a JetBrains license raffled off (and a dad joke from Venkat: “There are only two kinds of programmers, those with IDEA and those with no idea”), a stack of O’Reilly books including a signed copy of AI Engineering, which Venkat handed over with a straight face and the observation that nobody needs to learn the fundamentals anymore, and a conference ticket for October.

Big thanks to Kforce for the space and Kong for the food, and to the Professor Andy Seely who brought his class from Hillsborough Community College. (The next event is at HCC, by the way).

The post Notes from Venkat Subramaniam’s talk, “Power and Perils of AI Aided Coding”, at Tampa Java User Group (August 26, 2026) appeared first on Global Nerdy.

The U.S. changed the name in its own GNIS database in August following an executive order from the most petty of presidents. Google, which ties place names to each country’s official source, dutifully (and boot-licking-ly) started showing the new one to users with US IP addresses. If you’re in Canada and you view Lake Ontario in Google Maps, you’ll still see its proper name. Everyone outside the US sees both.

I’m in Tampa, which is in Florida (“the America of America”), so I got the new, incorrect name.

So I did what any reasonable person with VS Code, programming skills and a history of hacktivism would do. I wrote a Chrome extension.

It’s called Retake the Lake, it’s on GitHub, and building it turned out to be a much better story than I’d expected. There’s a genuinely interesting programming wall smack-dab in the middle of it.

What Retake the Lake does

Retake the Lake corrects “Lake America” to the proper “Lake Ontario” on Chrome desktop browsers. Unfortunately, the mobile versions of Chrome don’t support extensions.

1. On regular web pages, it rewrites “Lake America” back to the proper, correct, and non-idiotic “Lake Ontario.”
2. On Google Maps, it floats a clickable badge over the lake with a short explanation of where the real name comes from.

Get Retake the Lake!

Retake the Lake is now available in the Chromw Web Store, and I made this easy-to-remember shortcut for it:

globalnerdy.com/retakethelake

Technical notes

Part one: Replacing text is easy, right?

In theory, it is: You traverse the DOM, find text nodes, run a regex, and Bob’s your uncle. I’ve written this a hundred times, and if you’re a reader of this blog, you probably have too.

But it didn’t work on Google Maps’ search results, and I remembered why this is never as easy as it looks. Maps bolds your query inside the suggestion, so the markup is:

Lake <b>America</b>

In the example above, there’s no text node containing “Lake America.” There’s a node containing Lake and a different node inside a <b> containing America. A per-node replacer will completely miss it.

The fix is to stop thinking in nodes and start thinking in runs. Gather up adjacent text nodes that share a block-level ancestor, glue them into one string, run the match on that, then redistribute the result back across the original nodes. The end result is that the whole replacement lands in the first node the match touches, and the later ones give up their share.

The “block-level ancestor” part is key. Without it you’d happily join these two paragraphs:

<p>Visit the Lake</p>
<p>America is big</p>

…and produce something nobody asked for.

A bonus bug I nearly shipped

Early on, my rules were a list, applied in order:

["Lake America", "Lake Ontario"]
["Lake Ontario", "Lake Joey"] // don't ask

Run those sequentially on the same string and watch what happens: “Lake America” becomes “Lake Ontario” which the next rule immediately turns into “Lake Joey” (my original plan was to do the Trump thing and simply rename the lake after me). The rename cascades straight through the thing you were renaming it to.

The fix is to compile every rule into a single alternation regex and do exactly one pass, so each matched span is consumed once and never re-examined. Order stops mattering. It’s the kind of bug that’s obvious in hindsight and invisible while you’re in the zone.

Part two: The wall

And now, Google Maps.

You cannot change the label on the map. Not with this extension, not with any extension, not with a clever hack you’re about to suggest in the comments.

Google renders the basemap with WebGL vector tiles. That label’s not text. It’s also not isn’t a DOM node, nor is it alt attribute, and it isn’t a 2D canvas fillText() call you could monkey-patch. It’s glyph geometry uploaded to your GPU and painted as textured quads. By the time it reaches your eyeballs it has exactly as much “text” in it as the water underneath it; in other words: none. It’s all pixels.

Forcing raster tiles doesn’t work, either. Those are server-rendered PNGs with the label already baked in.

So updating the map label isn’t an option. That left me with everything around the map label: the sidebar heading, search results, autocomplete, the browser tab title, and aria-label text on the controls. Those are all DOM, and the rewriter fixes all of them.

This takes me to the badge.

How do you draw on a map you can’t read?

Without the ability to edit Lake Ontario’s label, I went for the next-best thing: putting something next to it. That brings about this fun question: How do you position an overlay on a map you can’t query?

You can’t ask Maps where the lake is. There’s no DOM to inspect and no API surface pointed at the renderer.

Fortunately, Google puts the answer in the URL:

/maps/@43.70,-77.90,8z

The first number after /maps/@ is the latitude of the centre of Lake Ontario. The number after that is the longtiude of that cenre. And finally, the last number, which is immediately followed with a z is the zoom level. Center latitude, center longitude, zoom. That’s everything you need, because Web Mercator is just simple math:

const world = 256 * Math.pow(2, zoom);
x = world * (lng + 180) / 360;
y = world * (0.5 - Math.log(Math.tan(Math.PI/4 + lat/2)) / (2*Math.PI));

Project the lake’s center, project the view’s center, subtract, and add the difference to the middle of the viewport, and that’s where the badge goes.

Project the lake’s bounding box the same way and you also know whether it’s on screen at all, so the badge only appears when there’s actually a Lake Ontario to point at. The badge also clamps to the visible edge when you’re zoomed into one end.

Reality rears its ugly head in two places, and both became features:

1. Maps only rewrites the URL after a gesture settles. So during a drag or zoom, my position data is stale and the badge would slide across the water a beat behind your cursor. The solution was to hide the badhe during the drag. It reappears  about 350ms after the user stops fiddling with the map.
2. Tilted and satellite views break the math. Those URLs carry a camera altitude (,1500m) or a tilt angle (,45t) instead of a plain zoom, and flat Mercator no longer describes what’s onscreen. The badge refuses to draw. It’s better to show nothing that to confidently point at the wrong lake.

The same trick, incidentally, works for anything geographic. Point the config at different coordinates and the badge follows.

The one-character bug that ate an element

Let me leave you with my favorite mistake of the whole build.

While restyling the badge, I edited the opening tag and lost a single >:

<div class="pin" id="pin" role="button"
aria-label="Note about this lake"
<span class="mark">i</span><span>Lake Ontario</span>
</div>

The badge still rendered. But the little white circular i chip vanished, replaced by a naked lowercase letter.

Here’s why, and it’s delightful. Without the closing bracket, the parser never leaves the tag. It keeps reading attributes — and <span is a perfectly acceptable attribute name as far as the HTML parser is concerned. So is class="mark". The tag finally closes on the > that was supposed to end the span’s opening tag. The span is eaten into the div’s attribute list and never becomes an element at all, so the CSS rule styling it matches nothing.

Inspect the element and you can see the crime scene: a stray <span sitting in the attribute list like it belongs there.

HTML’s error recovery is so determined to give you something that it will quietly digest an entire element rather than admit you made a typo.

Get the source code

Do you want to see the source code for Retake the Lake? It’s on Github at github.com/AccordionGuy/retake-the-lake. It’s MIT licensed.

Pull requests are welcome, especially if you’d like to add the other four Great Lakes to the config before Orange Julius Caesar gets any more ideas.

And remember…

The post Retake the Lake: A Chrome browser plug-in that corrects “Lake America” to “Lake Ontario” appeared first on Global Nerdy.

• HTMX: No AI Fridays. “If the productivity gains from AI are so big, spending one day a week to minimize its downsides shouldn’t be a difficult trade-off.”

• Engineering Leadership: Good Culture is the Biggest Productivity Hack, Not AI. “I DON’T think the biggest question for leaders should be: ‘How do we get everyone to use AI?’ The biggest question is: ‘How do we build an organization where great people can do their best work, and then use AI to multiply them?’”

• AskMike.org: What my dad taught me about AI coding in the 90s. “What is clear to everyone is that if you use AI in a way where you spend little time saying what you want, and no time reading what it coded up – you are vibecoding and the resulting software is not going to last very long (if it works at all). So how much coding should you let the AI do, and how much should you control and read (and deeply understand)?”

• The Internet Archive’s “Vintage Artificial Intelligence” collection: “A curated collection of early computer software claiming some aspect of artificial intelligence as a primary feature, allowing the early interactions of humans and machines before things got a little strange. Includes a variety of programs intended as therapists, conversation partners, and opponents.”

• Business Insider: Dario Amodei says Anthropic is ‘not interested in destroying anyone’. “With Salesforce CEO Marc Benioff seated beside him, Amodei sought to put to rest Wall Street’s belief that Anthropic aims to conquer all things SaaS. After all, it was an Anthropic announcement in late January about plugins for Claude Cowork, not the four horsemen, that signaled the beginning of what became known as the Saaspocalypse. In one week, roughly $1 trillion in value was wiped out in the software sector.”

The post AI linkdump for Sunday, August 30 appeared first on Global Nerdy.

The post Saturday picdump for Saturday, August 29 appeared first on Global Nerdy.

This list includes both in-person and online events. Note that each item in the list includes:

When the event will take place

What the event is

Where the event will take place

Who is holding the event

This week’s events

• Monday, August 31
• Tuesday, September 1
• Wednesday, September 2
• Thursday, September 3
• Friday, September 4
• Saturday, September 5
• Sunday, September 6

Monday, August 31

Tuesday, September 1

Wednesday, September 2

Thursday, September 3

Friday, September 4

Saturday, September 5

Sunday, September 6

About this list

How do I put this list together?

It’s largely automated. I have a collection of Python scripts in a Jupyter Notebook that scrapes Meetup and Eventbrite for events in categories that I consider to be “tech,” “entrepreneur,” and “nerd.” The result is a checklist that I review. I make judgment calls and uncheck any items that I don’t think fit on this list.

In addition to events that my scripts find, I also manually add events when their organizers contact me with their details.

What goes into this list?

I prefer to cast a wide net, so the list includes events that would be of interest to techies, nerds, and entrepreneurs. It includes (but isn’t limited to) events that fall under any of these categories:

• • Programming, DevOps, systems administration, and testing
  • Tech project management / agile processes
  • Video, board, and role-playing games
  • Book, philosophy, and discussion clubs
  • Tech, business, and entrepreneur networking events
  • Toastmasters and other events related to improving your presentation and public speaking skills, because nerds really need to up their presentation game
  • Sci-fi, fantasy, and other genre fandoms

• Self-improvement, especially of the sort that appeals to techies
• Anything I deem geeky

The post Tampa Bay tech, entrepreneur, and nerd events list (Monday, August 31 – Sunday, September 6) appeared first on Global Nerdy.

The post Debugging with Claude Code appeared first on Global Nerdy.

Loop engineering

Graph engineering

DeepSeek Harness

The downside

• CNBC: Anthropic IPO filing will show AI backlash as a risk factor, sources say
• @argofowl on Twitter: Anthropic appears to be A/B testing reduced effort levels in Claude Code
• The Economist: AI boosted homework scores and lowered exam scores

Miscellaneous

• adnanakil on GitHub: Claudette makes Claude not create output that sounds like a Buzzfeed article

The post AI linkdump for Sunday, August 23 appeared first on Global Nerdy.

The post Saturday picdump for Saturday, August 22 appeared first on Global Nerdy.

This list includes both in-person and online events. Note that each item in the list includes:

When the event will take place

What the event is

Where the event will take place

Who is holding the event

This week’s events

• Monday, August 24
• Tuesday, August 25
• Wednesday, August 26
• Thursday, August 27
• Friday, August 28
• Saturday, August 29
• Sunday, August 30

Monday, August 24

Tuesday, August 25

Tuesday at 5:30 p.m. at Hidden Springs Ale Works (Tampa): It’s time for another TampaTech Taps & Taco Tuesday! It’s a friendly, casual get-together of Tampa Bay’s tech scene for conversations, great drinks, and (of course) free tacos!

Find out more and register here.

Wednesday, August 26

Wednesday at 5:30 p.m. at KForce (Tampa): It’s “Power and Perils of AI Aided Coding”, organized by Tampa Java User Group, with Tampa Bay AI Meetup! Dr. Venkat Subramaniam returns to Tampa to give another one of his amzing, engaging, and amusing talks on becoming better developers.

Find out more and register here.

Thursday, August 27

Thursday at 6:00 at Florida Avenue Brewing (Seminole Heights, Tampa): The Tampa Bay New-in-Tech meetup is hosting a “meet and greet”! Whether you’re brand new to Tampa, transitioning into tech, an experienced professional, entrepreneur, or simply curious about the local tech scene — come say hello!

Find out more and register here.

Thursday at 6:30 at Wild Rover Brewery (Seminole Heights, Tampa): It’s time for another Lean Beer for All Things Agile!

This long-standing Meetup group is all about promoting knowledge sharing and networking among professionals with a passion for Agile Product Development. Whether you’re a Scrum enthusiast or just curious about Agile practices, this is the perfect platform to exchange experiences, network, vent, and foster your Agile knowledge. All this while drinking beer together!

Find out more and register here.

Friday, August 28

Saturday, August 29

Saturday morning at 10:30 at Luna Lux (St. Pete): When you’re often the only one in the room, being your authentic self takes deliberate work. A sustainable personal brand starts with knowing who you are, how you want to be perceived, what you’re working toward, and how to communicate your value. Navigating a tech career takes its own kind of blueprint, whether you’re a junior engineer, a seasoned VP, or a founder.

This brunch is for Black women in tech across the Tampa Bay area. We’re gathering to build a collaborative, high-trust circle where you can speak honestly, feel heard, and walk away with strategy.

Find out more and register here.

Sunday, August 30

About this list

How do I put this list together?

It’s largely automated. I have a collection of Python scripts in a Jupyter Notebook that scrapes Meetup and Eventbrite for events in categories that I consider to be “tech,” “entrepreneur,” and “nerd.” The result is a checklist that I review. I make judgment calls and uncheck any items that I don’t think fit on this list.

In addition to events that my scripts find, I also manually add events when their organizers contact me with their details.

What goes into this list?

I prefer to cast a wide net, so the list includes events that would be of interest to techies, nerds, and entrepreneurs. It includes (but isn’t limited to) events that fall under any of these categories:

• • Programming, DevOps, systems administration, and testing
  • Tech project management / agile processes
  • Video, board, and role-playing games
  • Book, philosophy, and discussion clubs
  • Tech, business, and entrepreneur networking events
  • Toastmasters and other events related to improving your presentation and public speaking skills, because nerds really need to up their presentation game
  • Sci-fi, fantasy, and other genre fandoms

• Self-improvement, especially of the sort that appeals to techies
• Anything I deem geeky

The post Tampa Bay tech, entrepreneur, and nerd events list (Monday, August 24 – Sunday, August 30) appeared first on Global Nerdy.

Published fortnightly, Reachability Watch covers the volume of new network-exploitable CVEs, the handful that clear a CVSS 8.6 bar, whatever KEV actually caused damage that period, and a running tally so the trend line becomes visible over time.

The drawing features this edition’s highlighted KEV. More formally known as CVE-2026-72898, it’s what I call “BYOK: bring Your Own Key,” because that’s essentially what the exploit does. You hand Metabase’s password-reset endpoint an extra user-id key it never asked for, nobody strips it, and it rides all the way into the SQL query.

Read it here:
https://netfoundry.io/reachability-watch/reachability-watch-cve-kev-tracker-2026-08-14/

The post A new “back of the envelope” drawing for NetFoundry’s new “Reachability Watch”! appeared first on Global Nerdy.

The synth in question is pictured above: an FM-1 desktop synth made by a company called M-VAVE. For a mere US$79, it emulates the Yamaha DX7, the most 1980s of all the 1980s synths…

…but now in a package that’s slightly smaller than a VHS cassette.

I’ll post a review later, but since I have to run, I’ll post this guy’s review instead:

The post My new synth arrived: The M-VAVE FM-1 appeared first on Global Nerdy.

At this moment in time, I can’t think of a better way to promote an energy drink and a beer than by what Liquid Death and Garage Beer did: harnessing the pop culture power of worries about AI data centers’ water usage (with an inspired solution), ’80s ballads, and Jason Kelce.

I love how the ad brings all sorts of people together; even Juggalos (who along with the furries, will show us the way to a better future)!

The post If you watch only one ad today (good luck with that), watch this one! appeared first on Global Nerdy.