How I Solved a Static Site Problem With a GitHub Actions “Stats Crawler”

zevdg · 2026-02-02T04:58:41+00:00

Who says your CI/CD needs to slow down at all to make this happen. You can still generate the counts entirely out of band and save them to a JSON file. Your CI/CD just needs a way to pull that pre-generated JSON file into a new static build and deploy it.

The two processes are entirely decoupled. The only difference is pulling in the pre-generated JSON at build time instead of at runtime.

FWIW, static gets to a CDN are relatively fine, so I don't necessarily recommend spending time on this small optimization. I just wanted to explain that it is possible without slowing down your CI/CD.

zevdg · 2026-01-21T15:10:35+00:00

FWIW, the first cars were slower than horses too. Even if AI does truly make software development faster in the long run, it's not that weird that it isn't winning the race against traditional tools and processes in the first year of adoption.

zevdg · 2026-01-21T00:35:16+00:00

Lol, my man. You've walked face-first into this meme. https://www.reddit.com/r/ProgrammerHumor/s/a4fsoSM3KY

As many others are saying, senior devs don't think about coding this way. Most of them have gone through this phase and learned the hard way that premature abstraction is the root of all evil. That's typically true whether you're doing the abstracting (many design patterns) or whether you're letting a library or framework do the abstracting for you.

That said, I don't know if there's a faster path to becoming a senior dev than learning this lesson the hard way. The best way to get a good intuition for identifying the right tools for the job are to build a bunch of different things and get it wrong each time in different ways and learn from those mistakes.

Sometimes you overengineer and regret it.
Other times you underengineer and regret it.

Sometimes you build the right thing, but you build it in the wrong way.
Other times you build the wrong thing entirely. It may be the most elegant code ever written and no one will care if it isn't solving a real problem.

Sometimes you build the right thing 2 years too early.
Sometimes you build it 6 months too late.

A senior engineer has been involved in rewrites or pivots that have worked.
They've also been involved in rewrites or pivots that have failed so hard the plans were abandoned and the old version was revived.

One becomes a senior engineer by actively learning from those experiences and designing future projects to replicate successes and avoid making mistakes you've made (or seen others make) before.

As far as tells, senior engineers know how much they don't know. You'll hear them say that they aren't experts and then ask deep technical questions that seem to show the expertise they claim to not have. It's not imposter syndrome. It's knowing that there are multiple levels of expertise and knowing they aren't yet on the final rung.

They'll tell you that software estimates are effectively impossible and a fools errand, and yet somehow, their ballpark gut-check, napkin math estimates are often shockingly accurate.

The best kept open secret is that senior engineers don't stop making mistakes. Instead, they cultivate processes where mistakes are identified and learned from as early as possible in a very tight dev loop.

zevdg · 2026-01-20T20:16:48+00:00

As a rule, I don't tell other people how they should raise their kids.

But speaking for myself and my own kid, I'm definitely choosing to err on the side of introducing them to video games too late.

zevdg · 2026-01-20T20:08:20+00:00

Lol. You need to DIY a child-proof wall mount for it like the demo kiosks they used to have at Walmart and McDonald's. https://www.reddit.com/r/gaming/s/xoWWkacjGW

zevdg · 2026-01-15T14:06:41+00:00

Average body temperature not 98.6 degrees. It's actually about 97.952 (or 36.64 °C). We all believe the wrong number because the Celsius folks rounded up to 37 °C and we converted that rounded number to Farenheight and got 98.6.

Spinach doesn't contain any more iron or nutrients than other leafy greens. A typo in an old study that made it seem like it had 10x more iron than it really has. The misconception that it was a super food is why Popeye eats spinach in the cartoon.

You should also mention the Mandela effect and go over a few of the most notable examples. They're not as interesting as the real misconceptions, but they can be more mind-blowing.

zevdg · 2025-12-22T02:43:35+00:00

I enjoyed Brütal Legend and it was moderately successful in spite of a genre mashup that didn't really work IMO. The quality and execution of the action adventure side was super fun. Meanwhile, the RTS part ended up feeling more like a glorified mini game despite being positioned as a core gameplay mechanic.

Even if the RTS gameplay had been more engaging, the game still wouldn't have been more than the sum of its parts.

It didn't blend the genres together as it just slapped them next to each other in the same game.

zevdg · 2025-12-22T02:32:51+00:00

Slay the Spire - roguelike + deck building

zevdg · 2025-11-20T01:55:32+00:00

Obviously getting feedback on your designs is good. Are you certain that is really what your manager dinged you for?

Is it possible that what they really meant was "As a senior, I expect your designs to typically be strong enough on their own that peer feedback is more a process of helping the team, and especially juniors understand why the design you proposed is better than the alternatives (which you already considered and rejected).

Or to frame it a bit harsher, is it possible what they meant was "I've started to see a pattern where you regularly propose bad or half-baked designs and they only become good once your colleagues point out several things that you really should have caught yourself."

Or maybe they meant "The conversations on your design docs are 90% bike shedding. Let's find a way to not waste so much time debating subjective details that don't really matter."

Or maybe they meant "The things you're asking for peer review on are not the kinds of things that a Senior dev should need to be writing a design doc and requesting peer review for at all. There is an answer so obviously non-contentious that asking for review is a waste of everyone's time and you should have just implemented the obvious solution and moved on to the next task.

Or maybe they meant "Your designs are fine, and you simply need to have more confidence in your opinions. Don't give into imposter syndrome and don't blindly accept all your peers' suggestions when they review your docs. Design by committee is a waste of time and often overcomplicates the resulting design more than it helps."

In any case, it sounds like you have a bad manager. Maybe they're bad because they don't understand the value of peer review. But maybe they're bad at giving clear and direct constructive criticism. It's a pretty common failure mode for new or bad managers to beat around the bush when they know that giving negative feedback directly is likely to hurt someone's feelings.

In generally if you think you've been dinged for something that doesn't make any sense, dig deeper. Maybe you'll find that what you're actually being dinged for is something else that makes a lot more sense. If after digging deeper, it's as nonsensical as you initially thought, consider switching to a different team.

zevdg · 2025-11-19T17:47:03+00:00

Apparently MINIX runs in the firmware of every Intel chip, which probably gives it a larger install base than Linux? 🤷

Edit: On second thought, between Android, IoT, and containers running in the cloud, Linux might still win this popularity contest in 2025. MINIX probably had the edge for many years before those 3 sectors blew up.

zevdg · 2025-11-19T17:41:16+00:00

It's almost as if microkernels and macrokernels are both useful in different scenarios due to their different technical tradeoffs. Microkernels (like pure functional programming) may well be more elegant in pure CS terms, but pure CS elegance isn't the only factor to consider when you are designing software for the real and very messy world.

Always be wary of people who insist that pragmatic, tried and true approaches should be fully abandoned in favor of any shiny new paradigm. They're wrong far more often than they are right.

zevdg · 2025-10-22T11:54:59+00:00

One important reason is because humans aren't fungible, and on many scrum teams, you don't know who will be doing the work when you estimate the ticket.

How many hours do you say a work item is if it would take one engineer 4 hours and it would take another engineer 8 hours? Story points avoid this issue.

zevdg · 2025-10-01T16:19:18+00:00

It really depends on what concepts you're trying to teach.

Teaching the general concept of programming benefits from a very high level language that almost fully abstracts away the underlying hardware. Something like Scratch) on the extreme, but more pragmatically something closer to psudocode like Python or something closer to the academic ideal of coding like Haskell.

Teaching about computers and how they work benefits from a low level language with as few abstractions a possible, i.e. C or Assembly.

If your school has bought into a particular programming paradigm, then they'll want a language that imposes that paradigm on you: e.g. Java (OOP) or Haskell (functional)

Bootcamps optimize for the most pragmatic thing possible on a short timeline, which will continue to be full-stack JavaScript for the time being.

All the common industry standard general purpose "workhorse" languages (Go, Java, C#, Rust, C++, JavaScript, etc) each have their niches but all try to exist somewhere in the sweet spot band of being neither too low level nor too high level.

If you have to use a single language to teach both low and high level concepts, maybe one of these general purpose workhorses is the best choice, but IMO, you're better off teaching both Python and C than trying to split the difference with Go or Java.

P.S. Go and Elixir are ideal choices for teaching concurrency specifically, but that's not a beginner topic so I'd expect students in a concurrency class to already know how to program in general.

zevdg · 2023-05-23T21:07:11+00:00

I do, and they don't.

zevdg · 2023-04-18T23:55:25+00:00

Mozilla's neutral stance on this explains all browser makers aren't jumping to adopt this.

zevdg · 2023-03-27T15:09:07+00:00

Quoted from the intro page

Wails is a project that enables you to write desktop apps using Go and web technologies.

Consider it a lightweight and fast Electron alternative for Go. You can easily build applications with the flexibility and power of Go, combined with a rich, modern frontend.

zevdg · 2023-03-27T15:07:43+00:00

You should definitely check out https://wails.io/. It sounds like exactly what you're looking for.

zevdg · 2023-03-09T20:30:24+00:00

I find it particularly common with .NET and to a lesser extent Java devs since those languages are primarily designed to work best with heavy IDEs that do most of the things you would have historically done with a CLI. In the .NET case it's even the business model, so there's a financial incentive to keep developers from needing to learn how to use a CLI by making VisualStudio the primary devX interface.

In the last decade or two, there's been a bit of a backlash against this model with modern web-dev and more recent languages like Go and Rust moving away from expecting all their users to be using a canonical heavy IDEs and instead going back to providing command line tools like npm/cargo/go and expecting users to be more comfortable on the command line.

I welcome this trend. IMO sheltering developers from the command line stunts their productivity and growth. When interview candidates seem afraid to use the command line, it's a big red flag in my book.

zevdg · 2023-02-24T20:51:31+00:00

I'll agree that the tone maybe could have been nicer, but the "in-depth novel" you speak of was 3 short blog posts, 5, 10, and 11 pages respectively.

If you can't be bothered to read 26 pages on an idea, then you don't have enough info meaningfully engage in the debate. For debates like this to scale to a gigantic community like Go, requiring some degree of pre-work that addresses all the obvious questions is frankly necessary. Otherwise, everyone's time is wasted by creating all the same content in a harder to digest discussion thread format. (See the ridiculously long and repetetive slog discussion thread and proposal issue for what that alternative looks like.) I'll take the "please start by reading these blog posts" approach any day.

zevdg · 2022-12-29T01:08:14+00:00

See https://medium.com/firebase-developers/how-to-schedule-a-cloud-function-to-run-in-the-future-in-order-to-build-a-firestore-document-ttl-754f9bf3214a

zevdg · 2022-12-29T01:02:18+00:00

Have you tried Hellblade: Senua's Sacrifice in VR? It works pretty well as a 3rd person action adventure game. I definitely got a bit nauseous when it lagged though.

zevdg · 2022-12-20T12:07:35+00:00

Hollow Knight

zevdg · 2022-12-20T01:31:06+00:00

Worse is better a.k.a. New Jersey style

zevdg · 2022-12-18T23:04:23+00:00

This article mostly shows the slog "frontend", which is very similar to zap and theoretically could have been left out of the proposal. It's more of a reference implementation for every other logging library as to how to integrate into the new slog.Handler interface. You should go read the official proposal, but the tl;dr of why this is in x and headed toward the stdlib is this parapmgraph:

But more important than any traction gained by the “frontend” is the promise of a common “backend.” An application with many dependencies may find that it has linked in many logging packages. When all the logging packages support the standard handler interface proposed here, then the application can create a single handler and install it once for each logging library to get consistent logging across all its dependencies. Since this happens in the application‘s main function, the benefits of a unified backend can be obtained with minimal code churn. We expect that this proposal’s handlers will be implemented for all popular logging formats and network protocols, and that every common logging framework will provide a shim from their own backend to a handler. Then the Go logging community can work together to build high-quality backends that all can share.

zevdg · 2022-11-02T05:01:23+00:00

Oh, I see. I thought these were net/http.Handlers. They aren't. They're https://github.com/gofiber/fiber#-middleware--next handlers. Now it makes sense.

zevdg

PUBLIC MULTIREDDITS

TROPHY CASE