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
Search - "similarity"
-
As a developer, sometimes you hammer away on some useless solo side project for a few weeks. Maybe a small game, a web interface for your home-built storage server, or an app to turn your living room lights on an off.
I often see these posts and graphs here about motivation, about a desire to conceive perfection. You want to create a self-hosted Spotify clone "but better", or you set out to make the best todo app for iOS ever written.
These rants and memes often highlight how you start with this incredible drive, how your code is perfectly clean when you begin. Then it all oscillates between states of panic and surprise, sweat, tears and euphoria, an end in a disillusioned stare at the tangled mess you created, to gather dust forever in some private repository.
Writing a physics engine from scratch was harder than you expected. You needed a lot of ugly code to get your admin panel working in Safari. Some other shiny idea came along, and you decided to bite, even though you feel a burning guilt about the ever growing pile of unfinished failures.
All I want to say is:
No time was lost.
This is how senior developers are born. You strengthen your brain, the calluses on your mind provide you with perseverance to solve problems. Even if (no, *especially* if) you gave up on your project.
Eventually, giving up is good, it's a sign of wisdom an flexibility to focus on the broader domain again.
One of the things I love about failures is how varied they tend to be, how they force you to start seeing overarching patterns.
You don't notice the things you take back from your failures, they slip back sticking to you, undetected.
You get intuitions for strengths and weaknesses in patterns. Whenever you're matching two sparse ordered indexed lists, there's this corner of your brain lighting up on how to do it efficiently. You realize it's not the ORMs which suck, it's the fundamental object-relational impedance mismatch existing in all languages which causes problems, and you feel your fingers tingling whenever you encounter its effects in the future, ready to dive in ever so slightly deeper.
You notice you can suddenly solve completely abstract data problems using the pathfinding logic from your failed game. You realize you can use vector calculations from your physics engine to compare similarities in psychological behavior. You never understood trigonometry in high school, but while building a a deficient robotic Arduino abomination it suddenly started making sense.
You're building intuitions, continuously. These intuitions are grooves which become deeper each time you encounter fundamental patterns. The more variation in environments and topics you expose yourself to, the more permanent these associations become.
Failure is inconsequential, failure even deserves respect, failure builds intuition about patterns. Every single epiphany about similarity in patterns is an incredible victory.
Please, for the love of code...
Start and fail as many projects as you can.30 -
The programmer and the interns part 3.
Many of you asked me to keep posting about the interns that I'm responsible for.
I had the intention but never had the time or the energy. Since the interns only kept doing stupid, unthinkable things and just filtering out the good ones is a task of its own.
Time has passed, some interns left us by their choice, others were fired (for obvious reasons). Some stayed loyal and were given permanent positions. New ones joined. I no longer am directly responsible for their wellbeing, yet, somehow I am still their tech-lead and the developer of their tools.
Without further delay,
Case 0:
New guy get's into the internship, has his LinkedIn title set to ‘HTML Technician’.
Didn’t know about the existence of HTML5.
Been building static web pages in the early 2000s. The kind with embedded, inline CSS.
Claims that he is about to finish an engineering degree (sadly I believe him).
Fails the entry level Linux test. Complains about the similarity of the answer options.
Fails the basic web-standars test because "they change so fast, but the foundation is HTML and it's rock-solid!".
Get's caught taking home onions and milk from the kitchen.
Is spotted eating in a restaurant under our offices in his day off. Thrice. He lives a 30 minute drive away and comes here on a bicycle or by bus.
Apparently didn't know that the scrolling wheel on the mouse is clickable.
Said that his PC experience is mostly from his PlayStation (PC = PlayCtation apparently).
Get's fired, says that he'll go to the press. Never does.
Case 1:
Yet another new intern. He seems very eager to learn and work, capable, even charismatic. Has an impressive CV.
Does nothing.
Learns from the "case 0" guy and spends time with him until he is fired.
Comes to work at 8:00 AM and immediately goes to sleep on an office puff. In front of everyone.
Keeps dining alone, without a notice, at different times, for hours. Sometimes brings food into the office and loudly eats it there.
On his evening shifts keeps disappearing for long periods of time. Apparently drinking in the nearby bars and hitting on girls.
Keeps bragging about his success with getting their numbers and rants about those who reject him.
For over a year he fails his final training test and remains a trainee, without the ability to work on a real case.
Not fired yet.
Case 2:
Company retreat. Beautiful, exotic views, warm sun beams, all inclusive package for everyone on a huge half-island.
Simon (he's still with us, now as a true engineer!) brings his MacBook to the beach in order to work and impress all others.
Everybody get's drunk and start throwing huge inflatable balls at each other. One hits his laptop and it immediately is flattened.
Upset Simon is going in circles and ranting about the situation, looking for a solution.
Loses his phone on the beach.
Takes his broken laptop with him while searching for the phone.
Dips the laptop in the river while drunkenly ducking in order to pick a clam.
Case 3:
Still company retreat.
Drunk intern makes out with an employee's drunk wife.
Huge verbal fight. The husband says that he files for a divorce. Intern get's fired.
Case 4:
Still company retreat.
Three interns each take an inflatable swimming mattress and drift with the current. Get found on the other side of the resort three hours later, with red skin and severely dehydrated.
Case 5:
Still company retreat.
The 'informally fired' intern gets drunk again, climbs through a window into a room and makes out with an employee's drunk wife.
Again, gets caught when the husband returns to find a locked door but can see them though the window.
Case 6:
Still company retreat.
We all get ferociously drunk and wander off to the unknown in search of more booze.
Everybody does something stupid and somebody finds Simon's phone.
Simon is lost.
Frenzied horde of drunks is roaming the half-island in search of ethanol and the lost comrade.
Simon's phone get's permanently lost.
Five people step on sea urchins but find that out only hours later and then are unable to walk.
The mob, now including more drunk people who joined voluntarily, finds the sexually active intern making out with the enraged employee's wife yet again.
Surprisingly Simon is found sleeping in a room nearby.24 -
Ever notice the similarity between Flat Earthers and people who believe HTML is a programming language?
You can present them with all the reason and logic in the world and they won’t change their minds.13 -
OMFG I don't even know where to start..
Probably should start with last week (as this is the first time I had to deal with this problem directly)..
Also please note that all packages, procedure/function names, tables etc have fictional names, so every similarity between this story and reality is just a coincidence!!
Here it goes..
Lat week we implemented a new feature for the customer on production, everything was working fine.. After a day or two, the customer notices the audit logs are not complete aka missing user_id or have the wrong user_id inserted.
Hm.. ok.. I check logs (disk + database).. WTF, parameters are being sent in as they should, meaning they are there, so no idea what is with the missing ids.
OK, logs look fine, but I notice user_id have some weird values (I already memorized most frequent users and their ids). So I go check what is happening in the code, as the procedures/functions are called ok.
Wow, boy was I surprised.. many many times..
In the code, we actually check for user in this apps db or in case of using SSO (which we were) in the main db schema..
The user gets returned & logged ok, but that is it. Used only for authentication. When sending stuff to the db to log, old user Id is used, meaning that ofc userid was missing or wrong.
Anyhow, I fix that crap, take care of some other audit logs, so that proper user id was sent in. Test locally, cool. Works. Update customer's test servers. Works. Cool..
I still notice something off.. even though I fixed the audit_dbtable_2, audit_dbtable_1 still doesn't show proper user ids.. This was last week. I left it as is, as I had more urgent tasks waiting for me..
Anyhow, now it came the time for this fuckup to be fixed. Ok, I think to myself I can do this with a bit more hacking, but it leaves the original database and all other apps as is, so they won't break.
I crate another pck for api alone copy the calls, add user_id as param and from that on, I call other standard functions like usual, just leave out the user_id I am now explicitly sending with every call.
Ok this might work.
I prepare package, add user_id param to the calls.. great, time to test this code and my knowledge..
I made changes for api to incude the current user id (+ log it in the disk logs + audit_dbtable_1), test it, and check db..
Disk logs fine, debugging fine (user_id has proper value) but audit_dbtable_1 still userid = 0.
WTF?! I go check the code, where I forgot to include user id.. noup, it's all there. OK, I go check the logging, maybe I fucked up some parameters on db level. Nope, user is there in the friggin description ON THE SAME FUCKING TABLE!!
Just not in the column user_id...
WTF..Ok, cig break to let me think..
I come back and check the original auditing procedure on the db.. It is usually used/called with null as the user id. OK, I have replaced those with actual user ids I sent in the procedures/functions. Recheck every call!! TWICE!! Great.. no fuckups. Let's test it again!
OFC nothing changes, value in the db is still 0. WTF?! HOW!?
So I open the auditing pck, to look the insides of that bloody procedure.. WHAT THE ACTUAL FUCK?!
Instead of logging the p_user_sth_sth that is sent to that procedure, it just inserts the variable declared in the main package..
WHAT THE ACTUAL FUCK?! Did the 'new guy' made changes to this because he couldn't figure out what is wrong?! Nope, not him. I asked the CEO if he knows anything.. Noup.. I checked all customers dbs (different customers).. ALL HAD THIS HARDOCED IN!!! FORM THE FREAKING YEAR 2016!!! O.o
Unfuckin believable.. How did this ever work?!
Looks like at the begining, someone tried to implement this, but gave up mid implementation.. Decided it is enough to log current user id into BLABLA variable on some pck..
Which might have been ok 10+ years ago, but not today, not when you use connection pooling.. FFS!!
So yeah, I found easter eggs from years ago.. Almost went crazy when trying to figure out where I fucked this up. It was such a plan, simple, straight-forward solution to auditing..
If only the original procedure was working as it should.. bloddy hell!!8 -
I find it interesting to see how scenarios sometimes flip.
30 years ago, the generally accepted "best" thing to do when when interacting with a person of colour was to "not see colour" - to treat them as you would anyone else. Meanwhile the similarly accepted "best" thing to do when interacting with a physically disabled person was to recognise their disability, help them if appropriate, give them a boost, encourage them, etc.
Today it seems very much like the opposite. The correct thing to do when interacting with an ethnic minority is to see their colour, recognise their struggle, help them if appropriate, etc. - whereas with disabilities, that approach generally seems to have been labelled "inspiration porn", and the correct thing to do is simply not to see the disability, treating them like you would anyone else.
Not entirely comparable of course, but there's enough similarity there that I find the situation interesting.rant not trying to be ableist what are these tags for anyway i wonder how many tags i can add hmm tags dont stay in order long tags seem to be truncated not trying to be racist almond shut up random5 -
I am this die hard fan of House, MD. A medical Based Drama TV series.
I find soo many similarity between how doctor House diagnosis patients and how we coders debug code.
Why the flying-fuck is there not a similar show for engineers?
Where engineer is followed closes as he debugs a problem? And saves the day?
Why god why.
I just pray for this miracle to happen.
(To start with Dr.House abused vicodin, we coders abuse caffeine and sudo chmod 777 :P )9 -
!rant
Yesterday someone asked the similarity between political science and IT. Fair enough as a call like that is always subjective. But I think I finally have a sufficient answer.
Uneducated users, fuck up untold numbers of things because they think they know everything. Average users argue about nuance only experts would understand due to anecdotal experience. They can be really similar, I think.
Thank you for getting those interestimg thoughts in my head. -
that moment when you're very proud of yourself, spending almost a week making a workaround for a problem with a plugin but as you double check the plugin for similarity with what you want to accomplish, it already has a frickin method for it
fml1 -
Headsup: if you're making a game, or want to, a good starting point is to ask a single question.
How do I want this game to feel?
A lot of people who make games get into it because they play and they say I wish this or that feature were different. Or they imagine new mechanics, or new story, or new aesthetics. These are all interesting approaches to explore.
If you're familiar with a lot of games, and why and how their designs work, starting with game
feel is great. It gives you a palette of ideas to riff on, without knowing exactly why it works, using your gut as you go. In fact a lot of designers who made great games used this approach, creating the basic form, and basically flew-blind, using the testing process to 'find the fun'.
But what if, instead of focusing on what emotions a game or mechanic evokes, we ask:
How does this system or mechanic alter the
*players behaviors*? What behaviors
*invoke* a given emotion?
And from there you can start to see the thread that connects emotion, and behavior.
In *Alien: Isolation*, the alien 'hunts' for the player, and is invulnerable. Besides its menacing look, and the dense atmosphere, its invincibility
has a powerful effect on the player. The player is prone to fear and running.
By looking at behavior first, w/ just this one game, and listing the emotions and behaviors
in pairs "Fear: Running", for example, you can start to work backwards to the systems and *conditions* that created that emotion.
In fact, by breaking designs down in this manner, it becomes easy to find parallels, and create
these emotions in games that are typically outside the given genre.
For example, if you wanted to make a game about vietnam (hold the overuse of 'fortunate son') how might we approach this?
One description might be: Play as a soldier or an insurgent during the harsh jungle warfare of vietnam. Set ambushes, scout through dense and snake infested underbrush. Identify enemy armaments to outfit your raids, and take the fight to them.
Mechanics might include
1. crawl through underbrush paths, with events to stab poisonous snacks, brush away spiders or centipedes, like the spiders in metro, hold your breathe as armed enemy units march by, etc.
2. learn to use enfilade and time your attacks.
3. run and gun chases. An ambush happens catching you off guard, you are immediately tossed behind cover, and an NPC says "we can stay and fight but we're out numbered, we should run." and the system plots out how the NPCs hem you in to direct you toward a series of
retreats and nearest cover (because its not supposed to be a battle, but a chase, so we want the player to run). Maybe it uses these NPC ambushes to occasionally push the player to interesting map objectives/locations, who knows.
4. The scouting system from State of Decay. you get a certain amount of time before you risk being 'spotted', and have to climb to the top of say, a building, or a tower, and prioritize which objects in the enemy camp to identity: trucks, anti-air, heavy guns, rockets, troop formations, carriers, comms stations, etc. And that determines what is available to 'call in' as support on the mission.
And all of this, b/c you're focusing on the player behaviors that you want, leads to the *emotions* or feelings you want the player to experience.
Point is, when you focus on the activities you want the player to *do* its a more reliable way of determining what the player will *feel*, the 'role' they'll take on, which is exactly what any good designer should want.
If we return back to Alien: Isolation, even though its a survival horror game, can we find parallels outside that genre? Well The Last of Us for one.
How so? Well TLOU is a survival third-person shooter, not a horror game, and it shows. Theres
not the omnipresent feeling of being overpowered. The player does use stealth, but mostly it's because it serves the player's main role: a hardened survivor whos a capable killer, struggling through a crapsack world. The similarity though comes in with the boss battles against the infected.
The enemy in these fights is almost unstoppable, they're a tank, and the devs have the player running from them just to survive. Many players cant help but feel a little panic as they run for their lives, especially with the superbly designed custom death scenes for joel. The point is, mechanics are more of a means to an end, and if games are paintings, and mechanics are the brushes, player behavior is the individual strokes and player emotion is the color. And by examining TLOU in this way, it becomes obvious that while its a third person survival shooter, the boss fights are *overtones* of Alien: Isolation.
And we can draw that comparison because like bach, who was deaf, and focused on the keys and not the sound, we're focused on player behavior and not strictly emotions.1 -
Cunts I want to punch in the face: (in order of priority, grouped by similarity.)
1. Anyone who uses the words 'doggo' or 'pupper'.
2. Rapists, masogynists, Scientologists.
3. Anyone with news about their latest Linux distro.
4. Kanye West, Fred West, John West.
5. Trump, Maybot, Bojo.
6. Friends of Trump, Maybot, Bojo.
7. Kevin Bacon (since the EE ads)
8. That child on the bus.
9. The parents of that child on the bus.
10. Anybody who disagrees with any item on this list.15 -
Is ECMAScript a dialect of Lisp?
"JavaScript has much in common with Scheme. It is a dynamic language. It has a flexible datatype (arrays) that can easily simulate s-expressions. And most importantly, functions are lambdas. Because of this deep similarity, all the functions in [recursive programming primer] 'The Little Schemer' can be written in JavaScript."
— Douglas Crockford
An interesting discussion on SO (https://stackoverflow.com/questions...)2