magic_lobster_party

When you hold a hammer everything looks like a nail. Just because it’s useful in some cases doesn’t mean it’s always the best solution.

The article mostly rants about front end devs using unnecessarily complex solutions for simple problems. Like using React for generating static web sites.

When web development started to move away from jQuery towards Angular, React, Ember, Vue and all that shit I made the conscious decision to stay away from front end development. Well, I already made the decision after struggling aligning elements in all web browsers with CSS.

I’m glad I made that decision.

Simplicity is unsophisticated and lacking in many parts. The simplest solution to a problem is always the best solution. Choose simplicity. I’m begging you. Your future is begging you.

This goes with all of programming. It’s rare someone makes a clever solution that doesn’t immediately turn into “technical debt”.

This is tied to YAGNI. Do you really need to impose this restriction on this database? Don’t add restrictions “just in case it might be useful”. If you don’t have a good reason, you ain’t gonna need it.

Learn You a Haskell! One of the best written tutorials ever!

https://learnyouahaskell.github.io/recursion.html#quick-sort

I don’t think you should do LLM or machine learning stuff if you want to get software development out of the project. Mostly because most of the time you won’t do software dev stuff with that kind of stuff. You will mostly just download some off the shelf model, prepare data, tweak parameters, cross your fingers and pray for slightly better results, and repeat.

My recommendation without knowing much about you is to make a game engine. You remove the pressure of making something practical, and can just focus on making stuff that looks cool. You can easily control the scope of the project, and you will face a great variety of software development challenges. Lots of opportunities to learn.

And finally you will also have something that’s fun to present.

was 2097 the best one?

In my opinion, yes. It’s the one that best captures the feeling. It’s has that gritty industrial look and the best music.

The later ones are also good, but they’re a bit too “clean futuristic” to scratch my Wipeout itch.

First one hasn’t aged as well. Mainly because if you bump into a wall ever so slightly, you lose most of your speed. 2097 and onward are better at keeping your momentum going. I also love those spark effects that come when bumping into walls in 2097.

There’s nothing wrong with wanting a short TL;DW summary. I’ve already seen the video a while ago, but I don’t remember all the exact details.

When the internet is riddled with clickbait and sensational headlines, we’re getting quite protective of where we want to put our attention.

I dismissed it before because it’s a coop multiplayer game. I was concerned it wouldn’t be too much fun playing with strangers.

To my pleasant surprise the game is incredibly well designed to ensure the entire team cooperates - even without the need of using chat. It far exceeded my expectations!

Why spend 15 minutes to get the answer when it can be explained in a few paragraphs?

I just started with Deep Rock Galactic after sleeping on it for a while. I’m just a few hours in, but it’s safe to say that it’s probably going to be my new obsession.

First good step is to get the program running. Particularly good if you manage to set it in an IDE so you can use a debugger.

Next would be to play around with the program. Does it give any print outs? Search for the printed text in the code to see where it comes from. What would it take for it to get there?

Are there any configuration files? Try to find where the configuration is loaded in the code and see where the config parameters are used. How does different settings affect the program?

Are there any API endpoints? Find where the endpoint is defined. Do you know how to call it? Figure out what you need to call it. Do you get any interesting response? Figure out why you got that response.

Keep searching for clues like these about how the program works. See how the program behaves and work out why it behaved that way.

Over time you might learn the anatomy of the code base. It will become easier and easier to navigate around the code.

That is, while there is value in the items on the right, we value the items on the left more.

This is funnily the part of the manifesto most have trouble understanding.

It’s more about poor planning vs good planning. Of course a project with good planning is more likely to deliver in time.

It’s just to that poor planners tend to use “agile” as an excuse for their poor planning.

As a point of comparison, 360 has 512MB RAM. HL2 was targeting PCs comparable to PS3/360, but somehow they got it working on an Xbox.

I do that all the time. Sometimes I even realize I missed an even more obvious solution to the problem or how to better communicate the intent of the code.

Flash was considered unsafe because it allowed malicious actors to write malware.

There has been instances of popular and well meaning projects become hijacked by hostile actors. A recent notable example is xz, but there’s also event-stream npm package a few years ago that got infected with Bitcoin stealing code.

Just because a protect looks good now doesn’t mean it won’t turn bad in the future.

And not only would you need to audit the project. You also need to audit all of its dependencies as well. The xz vulnerability made it in to SSH. Who would think about looking into xz for vulnerabilities?

The amount of effort it would take to fake this for very little benefit is enormous.

The benefit of installing back doors can be enormous.

And after each instruction, the CPU go to the next instruction

Anything is a goto in disguise when you think about it