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
-
Sales employee Bob wants a clickable blue button.
Bob tells product owner Karen about his unstoppable desire for clickable blue buttons.
Karen assigns points for potential and impact (how much does a blue button improve Bob's life, how many people like Bob desire blue buttons)
Karen asks the button team how hard it is to build a button. The button team compares the request to a reference button they've built before, and gives an ease score, with higher score being easier (inverse of scrum points).
These three scores are combined to give a priority score. The global buttonbacklog is sorted by priority.
Once every two weeks (a "sprint") the button team convenes, uses the ease scores to assign scrum points. Difficult tasks are broken up into smaller tasks, because there is a scrum point upper limit. They use the average of the last 5 sprints to calculate each developer's "velocity".
The sprint is filled with tasks, from the top of the global button backlog, up to the team's capacity as determined by velocity. Approximate due dates are assigned, Bob is a happy Bob.
What if boss Peter runs into the office screaming "OUR IMPORTANT CLIENT WANTS A FUCKING PINK BUTTON WHICH MAKES HEARTS APPEAR"?
Devs tell boss to shut the fuck up and talk to Karen. Karen has a carefully curated list of button building tasks sorted by priority, can sedate boss with valium so he calms the fuck down until he can make a case for the impact and potential of his pink button.
Karen might agree that Peter's pink button gets a higher priority than Bob's blue button.
But devs are nocturnal creatures, easily disturbed when approached by humans, their natural rhythms thrown out of balance.
So the sprint is "locked", and Peter's pink button appears at the top of the global backlog, from where it flows into the next sprint.
On rare occasions a sprint is broken open, for example when Karen realizes that all of the end users will commit suicide if they don't have a pink heart-spawning button.
In such an event, Peter must make Bob happy (because Bob is crying that his blue button is delayed). And Peter must make the button team of devs happy.
This usually leads to a ritual involving chocolate or even hardware gift certificates to restore balance to the dev ecosystem.23 -
My first experience with Swift ended in me infecting myself with a virus (kinda). I wanted to create a macOS app that would listen for a global key event, catch it and then type a word.
During development I set it up to listen for ANY key event and to type "BALLS". So what happened? I compiled the code, everything looked good, I started the app and pressed a key which emitted a key event. The event was caught by my app and it typed "BALLS", just as expected. However, the typing of the word caused a NEW key event to be emitted, which the app also caught. The infinite loop was a fact. FUCK!
I tried closing down XCode but all I could see was "BALLS BALLS BALLS" everywhere. I tried everything I knew but it just kept typing "BALLS". I had to hold down my power button to make it stop.
I finally finished the app (which I named "The Balls App", I kept the word "BALLS"). I solved this issue by only listening for KeyUp and when emitting the "BALLS" word I just used KeyDown.7 -
This is my most ridiculous meeting in my long career. The crazy thing is I have witnessed this scenario play out many times during my career. Sometimes it sits in waiting for a few years but then BOOM there it is again and again. In each case the person that fell into the insidious trap was smart and savvy but somehow it just happened. The outcomes were really embarrassing and in some cases career damaging. Other times, it was sort of humorous. I could see this happening to me and I never want it to happen to you.
Once upon a time in a land not so far away there was a Kickoff Meeting for an offsite work area recovery exercise being planned for our Oklahoma locations. Eleven Oklahoma high ranking senior executives were on this webinar plus three Enterprise IT Directors (Ellen, Jim and Bob) who would support the business from the systems side throughout the exercise.
The plan was for Sam Otto, our Midwest Director of Business Continuity to host this webinar. Sam had hands-on experience recovering to our third party recovery site vendor and he always did a great job. He motivated people to attend the exercise with the coolest breakfasts and lunches you could imagine. Donuts, bagels, pizza, wings, scrumptious salads, sandwiches, beverages and desserts. He was great with people and made it a lot of fun.
At the last minute Charles 'Don't Call Me Charlie' Ego-Smith, the Global Business Continuity Senior Vice President, decided to grand-stand Sam. He demanded the reins to the webinar. Pulled a last-minute power-play and made himself the host and presenter. You have probably seen the move at some point in your career. I guess the old saying, 'be careful what you wish for' has some truth to it - read on and let me know if you devRanters agree...
So, Charlie, I mean Charles, begins hosting the session and greets all of the attendees. Hey, good so far! He starts showing some slides in the PowerPoint presentation and he fields a few questions, comments and requests from the Oklahoma executives. The usual easy to handle requests such as, 'what if we are too busy to do recover all systems', 'what if we recover all of our processes from home', 'what if we have high profile visitors that month?' Hey you can't blame them for trying. You are probably thinking to yourself, 'been there - heard that!' But luckily our experienced team had anticipated the push-back. Fortunately, Senior Management 'had our backs' and committed that all processes and systems must participate and test - so these were just softball requests, 'easy-peasy' to handle. But wait, we are just getting started!
Now the fireworks begin. Bob, one if the Enterprise IT directors started asking a bunch of questions. Well, Charles had somewhat of a history with Bob from previous exercises and did not take kindly to Bob's string of questions. Charles started getting defensive and while Bob was speaking Charles started IM'ing. He's firing off one filthy message after another to me and our teammate Sam.
'This idiot Bob is the biggest pain in the ass that I ever worked with'; 'he doesn't know shit', 'he never shuts the f up', 'I wanna go over to his office and kick his f'in ass...!'
Unfortunately...the idiot Charles had control of the webinar and was sharing his screen so every message he sent was seen by all of the attendees! Yeah, everyone including Bob and the Senior Oklahoma executives! We could not instant message him to stop as everyone would have seen our warnings, so we tried to call Charles' cell phone and text him but he did not pick up. He just kept firing ridiculously embarrassing dirty IM messages and I guess we were all so stunned we just sat there bewildered. We finally bit the bullet and IM'ed him to STOP ALREADY!!! Whoa, talk about an embarrassing silence!
I really felt sorry for Bob. He is a good guy. Deservedly, Charlie 'Yes I am going to call you CHARLIE' got in big time hot water after the webinar with upper management. For one reason or another he only lasted another year or so at our company. Maybe this event played a part in his demise.
So, the morale is, if you use IM - turn it off during a webinar if you are the host. If you must use it, be really careful what you say, who you say it to and pray nothing embarrassing or personal is sent to you for everyone to see.
Quick Update - During the past couple of months I participated on many webinars with enterprise software vendors trying to sell me expensive solutions. Most of the vendors had their IM going while doing webinars and training. Some very embarrassing things came flying across our screens. You learn a lot reading those messages when they pop-up on the presenters' screen, both personal and business related. Some even complaints from customers!
My advice to employees and vendors is to sign-out of IM before hosting a webinar. Otherwise, it just might destroy your credibility and possibly your career.5 -
Okay, story time.
Back during 2016, I decided to do a little experiment to test the viability of multithreading in a JavaScript server stack, and I'm not talking about the Node.js way of queuing I/O on background threads, or about WebWorkers that box and convert your arguments to JSON and back during a simple call across two JS contexts.
I'm talking about JavaScript code running concurrently on all cores. I'm talking about replacing the god-awful single-threaded event loop of ECMAScript – the biggest bottleneck in software history – with an honest-to-god, lock-free thread-pool scheduler that executes JS code in parallel, on all cores.
I'm talking about concurrent access to shared mutable state – a big, rightfully-hated mess when done badly – in JavaScript.
This rant is about the many mistakes I made at the time, specifically the biggest – but not the first – of which: publishing some preliminary results very early on.
Every time I showed my work to a JavaScript developer, I'd get negative feedback. Like, unjustified hatred and immediate denial, or outright rejection of the entire concept. Some were even adamantly trying to discourage me from this project.
So I posted a sarcastic question to the Software Engineering Stack Exchange, which was originally worded differently to reflect my frustration, but was later edited by mods to be more serious.
You can see the responses for yourself here: https://goo.gl/poHKpK
Most of the serious answers were along the lines of "multithreading is hard". The top voted response started with this statement: "1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is."
While I'll admit that my presentation was initially lacking, I later made an entire page to explain the synchronisation mechanism in place, and you can read more about it here, if you're interested:
http://nexusjs.com/architecture/
But what really shocked me was that I had never understood the mindset that all the naysayers adopted until I read that response.
Because the bottom-line of that entire response is an argument: an argument against change.
The average JavaScript developer doesn't want a multithreaded server platform for JavaScript because it means a change of the status quo.
And this is exactly why I started this project. I wanted a highly performant JavaScript platform for servers that's more suitable for real-time applications like transcoding, video streaming, and machine learning.
Nexus does not and will not hold your hand. It will not repeat Node's mistakes and give you nice ways to shoot yourself in the foot later, like `process.on('uncaughtException', ...)` for a catch-all global error handling solution.
No, an uncaught exception will be dealt with like any other self-respecting language: by not ignoring the problem and pretending it doesn't exist. If you write bad code, your program will crash, and you can't rectify a bug in your code by ignoring its presence entirely and using duct tape to scrape something together.
Back on the topic of multithreading, though. Multithreading is known to be hard, that's true. But how do you deal with a difficult solution? You simplify it and break it down, not just disregard it completely; because multithreading has its great advantages, too.
Like, how about we talk performance?
How about distributed algorithms that don't waste 40% of their computing power on agent communication and pointless overhead (like the serialisation/deserialisation of messages across the execution boundary for every single call)?
How about vertical scaling without forking the entire address space (and thus multiplying your application's memory consumption by the number of cores you wish to use)?
How about utilising logical CPUs to the fullest extent, and allowing them to execute JavaScript? Something that isn't even possible with the current model implemented by Node?
Some will say that the performance gains aren't worth the risk. That the possibility of race conditions and deadlocks aren't worth it.
That's the point of cooperative multithreading. It is a way to smartly work around these issues.
If you use promises, they will execute in parallel, to the best of the scheduler's abilities, and if you chain them then they will run consecutively as planned according to their dependency graph.
If your code doesn't access global variables or shared closure variables, or your promises only deal with their provided inputs without side-effects, then no contention will *ever* occur.
If you only read and never modify globals, no contention will ever occur.
Are you seeing the same trend I'm seeing?
Good JavaScript programming practices miraculously coincide with the best practices of thread-safety.
When someone says we shouldn't use multithreading because it's hard, do you know what I like to say to that?
"To multithread, you need a pair."18 -
Why the fuck this moron thought it was a good idea to set a global onClick event in a react component and make it have the desired behavior for EVERYTHING instead of the only click he wanted to get?
7 places you can click were triggering redux dispatch and ajax calls that should only work on one place... Fucking hell...4 -
Everyone and their dog is making a game, so why can't I?
1. open world (check)
2. taking inspiration from metro and fallout (check)
3. on a map roughly the size of the u.s. (check)
So I thought what I'd do is pretend to be one of those deaf mutes. While also pretending to be a programmer. Sometimes you make believe
so hard that it comes true apparently.
For the main map I thought I'd automate laying down the base map before hand tweaking it. It's been a bit of a slog. Roughly 1 pixel per mile. (okay, 1973 by 1067). The u.s. is 3.1 million miles, this would work out to 2.1 million miles instead. Eh.
Wrote the script to filter out all the ocean pixels, based on the elevation map, and output the difference. Still had to edit around the shoreline but it sped things up a lot. Just attached the elevation map, because the actual one is an ugly cluster of death magenta to represent the ocean.
Consequence of filtering is, the shoreline is messy and not entirely representative of the u.s.
The preprocessing step also added a lot of in-land 'lakes' that don't exist in some areas, like death valley. Already expected that.
But the plus side is I now have map layers for both elevation and ecology biomes. Aligning them close enough so that the heightmap wasn't displaced, and didn't cut off the shoreline in the ecology layer (at export), was a royal pain, and as super finicky. But thankfully thats done.
Next step is to go through the ecology map, copy each key color, and write down the biome id, courtesy of the 2017 ecoregions project.
From there, I write down the primary landscape features (water, plants, trees, terrain roughness, etc), anything easy to convey.
Main thing I'm interested in is tree types, because those, as tiles, convey a lot more information about the hex terrain than anything else.
Once the biomes are marked, and the tree types are written, the next step is to assign a tile to each tree type, and each density level of mountains (flat, hills, mountains, snowcapped peaks, etc).
The reference ids, colors, and numbers on the map will simplify the process.
After that, I'll write an exporter with python, and dump to csv or another format.
Next steps are laying out the instances in the level editor, that'll act as the tiles in question.
Theres a few naive approaches:
Spawn all the relevant instances at startup, and load the corresponding tiles.
Or setup chunks of instances, enough to cover the camera, and a buffer surrounding the camera. As the camera moves, reconfigure the instances to match the streamed in tile data.
Instances here make sense, because if theres any simulation going on (and I'd like there to be), they can detect in event code, when they are in the invisible buffer around the camera but not yet visible, and be activated by the camera, or deactive themselves after leaving the camera and buffer's area.
The alternative is to let a global controller stream the data in, as a series of tile IDs, corresponding to the various tile sprites, and code global interaction like tile picking into a single event, which seems unwieldy and not at all manageable. I can see it turning into a giant switch case already.
So instances it is.
Actually, if I do 16^2 pixel chunks, it only works out to 124x68 chunks in all. A few thousand, mostly inactive chunks is pretty trivial, and simplifies spawning and serializing/deserializing.
All of this doesn't account for
* putting lakes back in that aren't present
* lots of islands and parts of shores that would typically have bays and parts that jut out, need reworked.
* great lakes need refinement and corrections
* elevation key map too blocky. Need a higher resolution one while reducing color count
This can be solved by introducing some noise into the elevations, varying say, within one standard div.
* mountains will still require refinement to individual state geography. Thats for later on
* shoreline is too smooth, and needs to be less straight-line and less blocky. less corners.
* rivers need added, not just large ones but smaller ones too
* available tree assets need to be matched, as best and fully as possible, to types of trees represented in biome data, so that even if I don't have an exact match, I can still place *something* thats native or looks close enough to what you would expect in a given biome.
Ponderosa pines vs white pines for example.
This also doesn't account for 1. major and minor roads, 2. artificial and natural attractions, 3. other major features people in any given state are familiar with. 4. named places, 5. infrastructure, 6. cities and buildings and towns.
Also I'm pretty sure I cut off part of florida.
Woops, sorry everglades.
Guess I'll just make it a death-zone from nuclear fallout.
Take that gators!
5 -
Today, I made an event-based gamepad library.
Although, I was lazy. I am planning on only supporting one controller so the library only supports one controller at a time. Plus, it uses some global variables.
But still, kinda fun
2 -
Is everyone excited about Wednesday US and Thursday in many countries devRant livestream event? I know I am. I am counting the hours 😊 Is everyone attending this devRant global event?2
-
I think I finally, really, comprehend why secret societies have historically been created... I mean the potentially logical ones. This train of thought is logically terrifying.
I want a logic check.
I've been jokingly mentioning some of my totally true, practically useless in most scenarios, skills/specific fields of knowledge/ability under a moniker of 'extremely useful, assuming apocalyptic event' for years. Things like advanced knowledge of Coefficients of glass expansion, Fortran, various things that have caused friends to refer to me as MacGyver after the reboot came out.
In recent years, I've personally encountered several varieties of the ones defined by helplessness, self-victimisation, some version of a real disability... that theyve expounded into a personified personal nemesis-- to flashily battle yet never overcome, etc... the vast majority perplexing me as to why that's a valid form of life to them... it's not that they never consider some other way; the ball is just quickly dropped and never picked back up.
College?(not that I'm a big fan) they wish they could but so expensive... aide? The form was hard/confusing/past-due...
Lookup/learn something more indepth than a tiktok? *some self-deprecating bs*
Yet it's "I always wanted to do/be/learn X"
Shows like 'How It's Made' fascinate, but don't inspire enough for a 5min google query.
In the dev world its a clear, inverted pyramid-- one of the first posts I saw when I rejoined here was ostream's rant on Apple sucking because after they stop support/updates you "can't" load a different OS... ofc you can. But several comments down... no mention of that... i think it was @LensFlare who was the only one in ~15 respondents to point out the core logical fallacy.
Basic shit is totally forgotten... try asking some random adults what plastic is made from... or pay attention to how many people declare they have a gluten "allergy".
I get people frequently telling me that things im pointing out as differences don't matter because "it's just semantics"... semantics is literally the epitome of "significance", with roots in 'meaning' and 'truth'
Back to the main issue... We are in a world where DIY is typically something you pay more to do as a catered experience than actually learning anything, people destroy their own arguments hopes of validity unwittingly often by stating the arguement, get 'offended' or 'triggered' by factual statements, propagate misinformation and bastardise words until MW needs money enough to print a new version, likely adding the misuse as an actual definition and basic knowledge and the thought to actually learn is vetoed by the existence of google translate, the wisdom of tiktok and the pure brillance of troubleshooting every random linux issue you have from not knowing basic CLI and thinking linux makes you cool, with chmod 777 because so many other dumbasses on forums keep propagating misinformation. Ask them what 777 means, most have no clue... as they didnt consider googling that one before putting it in a terminal several times.
The number of humans that actually know the basic shit that the infrastructure of the world is built on keeps decreasing... and we aren't even keeping a running tally.
The structure of the internet has the right idea... dns- 13 active master root servers, with multiple redundancies if they start dropping... hell ICANN is like a secret society but publicly known/obfuscated... the modern internet hasnt had a global meltdown... aside from the lack of censorship and global availability changing the social definition of a valid use of braincells to essentially propagating spam as if it's factual and educational.
So many 'devs' so few understanding what a driver is, much less how to write one... irl network techs that don't know what dhcp is or that their equiptment has logs... professionals in deducated fields like Autism research/coping... no clue why it was called "autism", obesity and malnutrition simultaneously existing in the same humans... it's like we need to prepare a subterranean life-supporting vault and stock it like Noah's ark... just including the basic knowledge of things that used to be common/obvious. I've literally had 2 different, early 20s, female, certified medical assistants taking my medical history legitimately ask if not having a uterus made it harder to get pregnant...i wish i was joking.
Any ideas better than a subterranean human vault system? It's not like we can simply store detailed explanations, guides, media... unless we find a way to make them into obfuscated tiktok videos apparently on nonsense or makeup tutorials.11 -
That moment when a not so local native event handler is your first enemy...
Am I the only one who hate this stuff? it break things from a random place in a random time, with no reason...
2 -
!= rant
All devs Rise and show your creative prowess!
@ https://tadhack.com/2017/global/
Its a fun hackington where i have been before a few times, run only by volunteers.
I tink some people on devrant here also would be interested in this event.
i am also going and hope te see more devranters there! ID't by there laptop stickers!1 -
Has anyone used YouTube iFrame API?
I do ask first here before going on SO.
I am trying to play a YouTube video in sync from 2 different computers.
Luckily YouTube iFrameAPI has an event called `onStateChange` that is fired every time a video is paused, played, stopped etc.
This is the scenario...
1. Host creates a session and sends the link to guest.
2. Guest connects with the host.
3. Host plays/pauses/goes to specific time in the vide the video. The video is synced on guest session.
Now I have to figure out how to sync when Guest does an action. The thing is, every time an event is triggered in Host, it sends the command to Guest. The guest obeys BUT THEN the event `onStateChange` is triggered on guest and sends the command to Host. It is an infinite loop that I cannot seem to figure out if the onStateChange is triggered from API or from User interaction.
What I have tried so far...
1. Global variables. No luck.
2. Disable the event handler when the guest is gets data from host and after it finishes syncing, activate the event handler. But the handler still triggers.
3. Timeframe. (an ugly one) . Checks when the last time that event was triggered. If it was less than 1.5 seconds (or other second), it does not send the commands to host.6 -
Yesterday there was a DevOps event in my office. I had developed an Android and iOS app for the same. Basically the idea was along with things like Agenda for the day, speak and partners information, the app could scan QR of expo booths. If a user visits all booths he is eligible for lucky draw prizes. It ended up being really awesome event. Global heads were really impressed by tech and innovation from India. And in the end, there were 5 lucky draws, and I won JBL truly wireless headphones😆😆
-
Question directed to devs who know a bit about setting up middle sized architecture.
Prestory: Joined into development of a middle sized online game. Figured they created a monolith over the last 6 years up to a point where nothing works properly and nothing can be changed without wrecking the whole system. Figured a monolithic approach isn't such a great idea.
Current Situation: In a different, same scale online game development team, game itself working but team is struggling with architecture.
My job is to come up with an approach on how to set up masterserver/matchmaking/database etc. Reading through various articles about common principles (SOLID etc.), i figured that a microservice+event-/servicebus architecture may work for that kind of project.
The idea would be to have a global interface in which microservices can be hooked. So a client registers to a client handler on startup, then starts to queue for a game, the client handler throws an event on the bus to register the user to matchmaking. The matchmaker happens to listen to those events (Observer Pattern) and adds him to matchmaking, when a match is found it throws an event on the bus to connect the user to the server, etc. One can easily imagine a banhandler throwing in a veto to cancel such an action, metrics and logging is fairly simple to add (just another service listening to all events), additionally Continuous Delivery, FRP and such are also beneficial advantages and it is said to scale well.
The question is, would you do the same, is there maybe something i might be overlooking? Do you have better ideas?
Keep in mind that we are not too experienced and are bound to different languages (python, C++ and java mostly) and are a small (4 Devs) Team with different strengths.
Thank you for your feedback and criticism!1 -
i always get sucked into this "cute code" hell whenever i am working with a b2c codebase, and especially with kotlin code.
here's a scenario:
task : build a debounce logic for an input view where each user input is currently triggerring an api call.
my steps
1. read what debouncing is.
2. see if any code is available on the internet
=> found a code piece on the internet with some level of abstraction ( basically a simple final class that implements the input event callback and encapsulates the debounce logic)
3) copy it, run it , it wokrs
------
for any sane coder, these steps are hardly 10-30 mins and they can move on with life. but its your truly that made this task into a 6hour research only to come up at similar solution. my curiosity led me to stupid places
1) why this class is final? what if someone else wanna use it but with a different behaviour? lets try open(non final class) .
2) why even use a class? it extends an interface, lets try to wrap the logic in interface itself (kotlin supports interfaces that don't require implementation)
3) umm , the interface works but it looks ugly, with all its global overridden variables. what about we make it extension?
4) yeah the extension approach is also not very good, lets go back to open class.
5) but extend is super nice to look! lets keep the extension and open class too
6) can we optimise the implementation? why it uses an additional handler? what if we provided everything in constructor? how about builder pattern?
FUCK MY BRAIN! there are so much fucking options that i forgot that i spent 4 hours on this small thing
the simplest approach would have been tk just shove all the listeners and everything in activity and forget about it :/
senior devs on this platform, how do you stop yourself from adding every concept that you know into the smallest possible task?6
Top Tags
Weekly Rant
View