Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
This is probably not a popular comment, but here are the reasons I sometimes do not like working from home.
- if I don't get food, the kid starve
- if there's a meeting, the kid decides to play piano
- I have to watch delivered food that needs refrigerated to rot, while I really want to focus on that mudafukin bug
- if misus is not sleeping during the day, there is a 50% chance I smell something burnt in the house
Feel free to add to this list8 -
Last rant was about games and graphics cards (admittedly not received too well), time for a rant about game development houses.. especially you EA.
So yesterday a friend of mine showed me in one of our Telegram chats that he'd modified some cheats in an old FPS game by editing these scripts (not Lua for some reason) that the game used as a.. configuration language I guess? He called the result a tank cemetery 🙃
Honestly the game looked a lot like Medal of Honor to stoned me at the time, so I figured, well why not fire up that old nx7010 I had laying around for so long, get a new Debian installation on that and rip the Medal of Honor: Allied Assault war chest that I still had, and play it on one of my more modern laptops? Those CD's are now very old anyway, maybe time to archive those before they rot away.
So I installed Debian on it again, looked up how to rip CD's from the command line, and it seemed that dd could do it - just give /dev/cdrom as the input file, and wherever you want to store your copy as the output file. Brilliant! Except.. uh, yeah. It wasn't that easy. So after checking the CD and finding that it was still pristine, and seeing another CD in that war chest fail just the same, I tried burning and then ripping a copy of Debian onto another CD.. checksummed them and yes, it ripped just fine, bit for bit equal. So what the fuck EA, why is your game such a special snowflake that it's apparently too difficult to even spin up the drive to be copied?
So I looked around on plebbit and found this: https://reddit.com/r/DataHoarder/... - the top comment of that post shattered all my hopes for this disc to be possible to rip. Turns out that DRM schemes intentionally screw up the protocols that make up a functioning disc, and detecting those fuck-ups is part of the actual DRM.
"I also remember some forms of DRM will even include disc mastering errors/physical corruption on the actual disc and use those as a sort of fingerprint for the DRM. The copied ISO has to include them at the exact same place in the ISO as on the IRL disc and the ISO emulator has to emulate the disc drive read errors they cause."
So yeah. Never mind that I already own this goddamn game, and that it's allowed by law to make one copy for personal use, AND that intentionally breaking something is very shady indeed.. apparently I don't really own this game after all. So I went onto the almighty search engines, and instantly found a copy of this game for download. You know EA.. I wanted to play nice. You didn't let me. Still wondering why people do piracy now? Might take your top suits that suggested these fucked up DRM schemes another decade to figure out maybe.. even given the obvious now.
But hey I wouldn't even care that much if the medium these games are stored on wouldn't be so volatile (remember these discs are now close to 20 years old, and data rot sets in after 30 years or so). You company decided to publish these on CD. We've had cartridges in many forms before, those are pretty much indestructible and inherently near impossible to duplicate. And why would you want to? But CD is what you chose because you company were too cheap to go to China, get someone to make some plastic molds and put your board and a memory chip in that. Oh and don't even get me started on the working conditions for game devs.. EA and co, aren't you ashamed of yourselves? No wonder that people hate game development houses so much.
Yay, almost finished downloading that copy of Medal of Honor! Whatever you say EA.. I've done everything I could to do it legally. You are the ones who fucked it up.9 -
Good code is a lie imho.
When you see a project as code, there are 3 variables in most cases:
- time
- people / human resources
- rules
Every variable plays a certain role in how the code (project) evolves.
Time - two different forms: when certain parts of code are either changed in a high frequency or a very low frequency, it's a bad omen.
Too high - somehow this area seems to be relentless. Be it features, regressions or bugs - it takes usually in larger code bases 3 - 4 weeks till all code pathes were triggered.
Too low - it can be a good sign. But it should be on the radar imho. Code that never changes should be reviewed at an - depending on size of codebase - max. yearly audit. Git / VCS is very helpful here.
Why? Mostly because the chances are very high that the code was once written for a completely different requirement set. Hence the audit - check if this code still is doing the right job or if you have a ticking time bomb that needs to be defused.
People
If a project has only person working on it, it most certainly isn't verified by another person. Meaning that only one person worked on it - I'd say it's pretty bad to bad, as no discussion / review / verification was done. The author did the best he / she could do, but maybe another person would have had an better idea?
Too many people working on one thing is only bad when there are no rules ;)
Rules. There are two different kind of rules.
Styling / Organisation / Dokumentation - everything that has not much to do with coding itself. These should be enforced at a certain point, otherwise the code will become a hot glued mess noone wants to work on.
Coding itself. This is a very critical thing.
Do: Forbid things that are known to be problematic in the programming language itself. Eg. usage of variables in variables, reflection, deprecated features.
Do: Define a feature set for each language. Feature set not meaning every feature you want to use! Rather a fixed minimum version every developer must use and - in case of library / module / plugin support - which additional extras are supported.
Every extra costs. Most developers don't want to realize this... And a code base that evolves over time should have minimal dependencies. Every new version of an extra can have bugs, breakages, incompabilties and so on.
Don't: don't specify a way of coding. Most coding guidelines are horrific copy pastures from some books some smart people wrote who have no fucking clue what you're doing and why.
If you don't know how to operate on people, standing in an OR and doing what a book told you to do would end in dead person pretty sure. Same for code.
Learn from mistakes and experience, respect knowledge from other persons, but always reflect on wether this makes sense at this specific area of code.
There are very few things which are applicable to a large codebase on a global level. Even DRY / SOLID and what ever you can come up with can be at a certain point completely wrong.
Good code is a lie - because it can only exist at a certain point of time.
A codebase should be a living thing - when certain parts rot, other parts will be affected too.
The reason for the length of the comment was to give some hints on what my principles are that code stays in an "okayish" state, but good is a very rare state -
Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.
We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.
"The Pragmatic Programmer"
2 -
The problem as i see it is summed up in the following: everyone is fucking crazy
asked this guy i see here alot working, 'ever feel left behind in hell' he says 'oh this isn't hell it's (redacted) and we're on (redacted)'s mountain so we're closer to heaven'
so i make a not very novel joke anymore and I say "maybe there's a hellmouth over there, and we'd just have a farther fall" he smiled. it was a funny joke. whenever it was first made.
it was cynical humore expressing my present level of personal misery as I rot with everyone else.
also. remembered being able to convince someone to work for 50/hr doled out each hour as was satisfactory.
wonder if its possible again, person in question doesn't appear to be here today. oh well.
far far more honest than the other fucked up shit they do here and yes this whole rant was made before.
so. not a bot :P
and not making the comment about ownership let someone take this piece of life and let me get booted forward 15 years. fuckers.7
Top Tags
Weekly Rant
View