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
-
Finally a keyboard made for waffling on about how your indentation character choice is strictly superior to the other option
7 -
https://fuckoff.services.
Wrote it because fuck it why not. Was sick at home and wanted to build something :)
Feedback would be great!
About the short character limit, I might up it a little but this thing is about writing short messages and not stories so that's a choice on purpose.42 -
The riskiest dev choice...
How about "The riskiest thing you've done as a dev"? I have a great entry for that. and I suppose it was my choice to build the feature afterall.
I was working on an instance of a small MMO at a game company I worked for. The MMO boasted multiple servers, each of them a vastly different take on the base game. We could use, extend, or outright replace anything we wanted to, leading to everything from Zelda to pokemon to an RP haven to a top-down futuristic counterstrike. The server in this particular instance was a fantasy RPG, and I was building it a new leveling and experience system with most of the trimmings. (Talents, feats/perks, etc. were in a future update.)
A bit of background, first: the game's dev setup did not have the now-standard dev/staging/prod servers; everything ran on prod, devs worked on prod, players connected and played on prod, etc. Worse yet, there was no backup system implemented -- or not really. The CTO was really the only person with sufficient access. The techy CEO did as well, but he rarely dealt with anything technical except server hardware, occasionally. And usually just to troll/punish us devs (as in "Oops ! I pulled the cat5 ! ;)"). Neither of them were the most reliable of people, either. The CTO would occasionally remote in and make backups of each server -- we assumed whenever he happened to think of it -- and would also occasionally do it when asked, but it could take him a week, sometimes even up to a month to get around to it. So the backups were only really useful for retreiving lost code and assets, not so much for player data.
The lack of reliable backups and the lack of proper testing grounds (among the plethora of other issues at the company) made for an absolutely terrible dev setup, but that's just how it was, and that's what we dealt with. We were game devs, afterall. Terrible or not, we got to make games! What more could you ask for!? It was amazing and terrible and wonderful and the worst thing ever, all at the same time. (and no, I'm not sharing the company name, but it isn't EA or Nexon, surprisingly 😅)
Anyway, back to the story! My new leveling system also needed to migrate players' existing data, so... you can see where this is going.
I did as much testing and inspection of my code as I could, copied it from a personal dev script to the server's xp system, ... and debated if I really wanted to click [Apply]. Every time I considered it, I went back to check another part or do yet more testing. I ended up taking like 40 minutes to finally click it.
And when I did... that was the scariest button press of my life. And the scariest three seconds' wait afterwards. That one click could have ruined every single player's account, permanently lost us players ...
After applying it, I immediately checked my character to see if she was broken, checked the account data for corruption or botched flags, checked for broken interactions with the other systems....
Everything ended up working out perfectly, and the players loved all of the new features. They had no idea what went into building them, and certainly had no idea of what went into applying them, or what could have gone wrong -- which is probably a good thing.
Looking back, that entire environment was so fragile, it's a wonder things didn't go horribly wrong all the time. Really, they almost never did. Apocalypses did happen, but were exceedingly rare, and were ususally fixed quickly. I guess we were all super careful simply because everything was so fragile? or the decent devs were, at least. We never trusted the lessers with access 😅 at least on the main servers where it mattered. Some of the smaller servers... well, we never really cared about those.
But I'm honestly more surprised to realize I've never had nightmares of that button click. It was certainly terrifying enough.
But yay! Complete system overhaul and migration of stored and realtime player data! on prod! With no issues! And lots of happy players! Woooooo!
Thinking back on it makes me happy 😊1 -
We might achieve world peace one day and still won't have agreed over indentation.
Indentation = TAB. Just 1 character (N spaces = N characters = more disk space, duh!). And then each dev can chose their own TAB width (in spaces) in their IDE of choice. Beautiful.
11 -
Got rebuked by the Java teacher today at the University for using proper long names for variables in the code. She though I was just wasting time being lazy in the lab. "If something can be achieved by a single character, why type that long variable again and again?". *Everyone in class laughs*
Then, there was an error in my code [turned out to be long long int in Java is weird], and I had no clue what was going wrong [I'm a week old in Java]. So, I had initially called her to help. She made me change all private methods and attributes to public. When asked "why?", got trolled again.
Now, I know it's okay, and not that I really care about what my classmates think of me, but getting this kind of treatment really sucks. And if this is how future software developers are crafted today, maintainability is surely going to be an issue tomorrow.
Maybe staying in this stupid country was my worst career choice. I should have tried harder and gone abroad.11 -
In competitive games in which team composition matters and you have different playable classes and/or roles (tank, area damage, point damage, various kinds of healing, buffs/debuffs, etc) what kind of character do you like to play?
I guess this would apply to stuff like MMOs, Overwatch, TF2, DOTA, Diablo/PoE, and so on.21 -
Here is my idea for a time machine which can only send one bit of information back in time.
@Wisecrack has asked me about it and I didn’t want to write it in comments because of the character limit.
So here we go.
The DCQE (delayed-choice quantum eraser) is an experiment that has been successfully performed by many people in small scale.
You can read about it on wikipedia but I'll try to explain it here.
https://en.wikipedia.org/wiki/...
First I need to quickly explain the double slit experiment because DCQE is based on that.
The double slit experiment shows that a particle, like a photon, seems to go through both slits at the same time and interfere with itself as a wave to finally contribute to an interference pattern when hit on a screen. Many photons will result in a visible interference pattern.
However, if we install a detector somewhere between the particle emitter an the screen, so that we know which path the particle must have taken (which slit it has passed through), then there will be no interference pattern on the screen because the particle will not behave as a wave.
For the time machine, we will interpret the interference pattern as bit 1 and no interference pattern as bit 0.
Now the DCQE:
This device lets us choose if we know the path of the particle or if we want wo erase this knowledge. And we can make this decision after the particle hit the screen (that is the "delayed" part), with the help of quantum entanglement.
How does it work?
Each particle send out by the emitter will pass through a crystal which will split it into an entangled pair of particles. This pair shares the same quantum state in space and time. If we know the path of one of the particle "halves", we also know the path of the other one. Remember the knowledge about the path determines if we will see the interference pattern. Now one of the particle "halves" goes directly into the screen by a short path. The other one takes a longer path.
The longer path has a switch that we can operate (this is the "choice" part). The switch changes the path that the particle takes so that it either goes through a detector or it doesn't, determining if it will contribute to the intererence pattern on the screen or not. And this choice will be done for the short path particle-half because their are entangeld.
The path of the first half particle is short, so it will hit the screen earlier.
After that happened, we still have time to make the choice for the second half, since its path is longer. But making the choice also affects the first half, which has already hit the screen. So we can retroactively change what we will see (or have seen) on the screen.
Remember this has already been tested and verified. It works.
The time machine:
We need enough photons to distinguish the patterns on the screen for one single bit of information.
And the insanely difficult part is to make the path for the second half long enough to have something practical.
Also, those photons need to stay coherent during their journey on that path and are not allowed to interact with each other.
We could use two mirrors, to let the photons bounce between them to extend the path (or the travel duration), but those need to be insanely pricise for reasonable amounts of time.
Just as an example, for 1 second of time travel, we would need a path length about the distance of the moon to the earth. And 1 second isn't very practical. To win the lottery we would need at least many hours.
Also, we would need to build the whole thing multiple times, one for each bit of information.
How to operate the time machine:
Turn on the particle emitter and look at the screen. If you see an interference pattern, write down a 1, otherwise a 0.
This is the information that your future you has sent you.
Repeat this process with the other time machines for more bits of information.
Then wait the time which corresponds to the path length (maybe send in your lottery numbers) and then (this part is very important) make sure to flip the switch corresponsing to the bit that you wrote down, so that your past you receives that info in the past.
I hope that helps :)4
Top Tags
Weekly Rant
View