I built on online multiplayer boggle game back in 2008 that somehow drew a lot of users, many of whom still play every day after 17 years. About a year ago I started a rewrite from scratch in more modern technologies but stalled out after getting to about 80% of the way there. A few months ago Claude enabled me to finish the remaining 20% and was able to relaunch mostly successfully! It's been tough though. I'm a dad with three kids and use Claude all day at my day job and my interest in working late isnt always there. But I'm eeking my way to something that hopefully can stay up for another 17 years.

https://serpentinegame.com

https://SerpentineGame.com brings in close to that with advertisements and premium subscriptions. It is a clone of a game called Tangleword that is itself a clone of Boggle. I originally wrote it in 2008 and am currently re-writing it from scratch because the technology stack is so old and cumbersome to maintain.

What ad platforms do you like and dislike?

Whenever this kind of disagreement happens with my team, we put it to a vote and then the winning convention is enforced across the codebase from then on. There are tons of things in programming that come down to opinion but the important thing for me is that the team has a set convention and sticks to it.

I worked in a place where my team lead wanted us to vote on a technical decision. I found that unfair because half of the team was at a junior level.

If you can't explain why your idea is good to a junior engineer, voting is the lead of your problem. If you mistrust half your team as a rule, how can you trust anything to get done well?

It's hard to explain to junior engineers why chasing fads is a bad idea. Why boring technology is often the best choice. That's only something that most people figure out with experience.

Seniors often don’t like doing new things for the simple reason that they already know how to do things a different way and they don’t feel like learning something new.

and juniors like to make mistakes because that's how they turn into seniors.

The point is, and will continue to be, that a senior's opinion should be heeded or you disallow them from steering the ship away from the glacier that they know is there.

You can always justify everything with a reason. If your goal is to justify, then great, you did that. If your goal is to be effective, you need to stop trying to justify.

Do both groups favor turning every decision into a dichotomy? If so, maybe those aren't seniors after all.

In the old days the user would submit the form, the validation would happen on the server, then return a result. If the result was a failure, you would render the errors on a new page load. If the result was a success, you could redirect the user to "confirmation" page or reload the same page but with a different output.

I did try Firefox 57 on my Android phone and found the scrolling to be unpleasant with lots of artifacts and stuttering. It's still a much better experience with the mobile version of Chrome.

That's right but it's not so bothersome anymore esp on faster devices.

It would be interesting to try to cobble together a Linux distribution with a rust userland, using coreutils (https://github.com/uutils/coreutils) and over time building more and more of the userland/interface in rust.

whyy couldn't they pick a different name for this project?

rustutils? coreutils-rust?

name collision like this is how we have millions of people running around thinking that vim is vi while they bash emacs for having bloat as compared to the 'minimalism' of 'vi'..

I only skimmed the article but I agree with the conclusion. I evaluated both HAProxy and Nginx for a high-volume/low-latency load balancer cluster (500k requests/s) and HAProxy simply beat the pants off of Nginx. It has an extensive and well documented set of configuration options, tooling, and reporting, and it performed flawlessly on production (after much toiling). I couldn't ever quite get Nginx to handle the same load without falling apart at the seams.

I've got two NUCs, which I use as HTPCs running Fedora. They're fantastic machines. Really tiny, quiet, and plenty powerful enough for HD movies and light gaming/emulation.

The thing is, all of these details are implemented in the git command line tool, not in a library. So it is pretty difficult to write a tool that works exactly the same way the command line tool does, or if you do manage to do it, it'll be fragile since the command line tool could change behavior at any time.

This is exactly my stance on the matter. Don't litter the code with unnecessary comments that will never get acted upon. Instead, make a story in your bug tracker and act upon it.

The reason TODOs have survived the test of time is that bug trackers come and go while source code sticks around.

Not only that, but bugs come and go. People add a bunch of tech debt issues into the system, then a bunch of feature requests, possible bugs, and whatnot gets added. Then some big milestone or release comes up and everyone filters through the list, deciding what to fix and what not to. And then anything that doesn't need to get fixed "RIGHT GODDAMN NOW" often ends up on the ash heap of history, never to be seen again. And then years later someone looks at the code or runs into a bug and remembers "oh yeah..., hey, we should fix this eventually".

If you want to fix/change something eventually at some indeterminate time in the future then comment TODOs are a good place for that sort of issue to live.

It seems the TODOs are not the problem but the fact that they are not acted on.