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
-
Worst dev team failure I've experienced?
One of several.
Around 2012, a team of devs were tasked to convert a ASPX service to WCF that had one responsibility, returning product data (description, price, availability, etc...simple stuff)
No complex searching, just pass the ID, you get the response.
I was the original developer of the ASPX service, which API was an XML request and returned an XML response. The 'powers-that-be' decided anything XML was evil and had to be purged from the planet. If this thought bubble popped up over your head "Wait a sec...doesn't WCF transmit everything via SOAP, which is XML?", yes, but in their minds SOAP wasn't XML. That's not the worst WTF of this story.
The team, 3 developers, 2 DBAs, network administrators, several web developers, worked on the conversion for about 9 months using the Waterfall method (3~5 months was mostly in meetings and very basic prototyping) and using a test-first approach (their own flavor of TDD). The 'go live' day was to occur at 3:00AM and mandatory that nearly the entire department be on-sight (including the department VP) and available to help troubleshoot any system issues.
3:00AM - Teams start their deployments
3:05AM - Thousands and thousands of errors from all kinds of sources (web exceptions, database exceptions, server exceptions, etc), site goes down, teams roll everything back.
3:30AM - The primary developer remembered he made a last minute change to a stored procedure parameter that hadn't been pushed to production, which caused a side-affect across several layers of their stack.
4:00AM - The developer found his bug, but the manager decided it would be better if everyone went home and get a fresh look at the problem at 8:00AM (yes, he expected everyone to be back in the office at 8:00AM).
About a month later, the team scheduled another 3:00AM deployment (VP was present again), confident that introducing mocking into their testing pipeline would fix any database related errors.
3:00AM - Team starts their deployments.
3:30AM - No major errors, things seem to be going well. High fives, cheers..manager tells everyone to head home.
3:35AM - Site crashes, like white page, no response from the servers kind of crash. Resetting IIS on the servers works, but only for around 10 minutes or so.
4:00AM - Team rolls back, manager is clearly pissed at this point, "Nobody is going fucking home until we figure this out!!"
6:00AM - Diagnostics found the WCF client was causing the server to run out of resources, with a mix of clogging up server bandwidth, and a sprinkle of N+1 scaling problem. Manager lets everyone go home, but be back in the office at 8:00AM to develop a plan so this *never* happens again.
About 2 months later, a 'real' development+integration environment (previously, any+all integration tests were on the developer's machine) and the team scheduled a 6:00AM deployment, but at a much, much smaller scale with just the 3 development team members.
Why? Because the manager 'froze' changes to the ASPX service, the web team still needed various enhancements, so they bypassed the service (not using the ASPX service at all) and wrote their own SQL scripts that hit the database directly and utilized AppFabric/Velocity caching to allow the site to scale. There were only a couple client application using the ASPX service that needed to be converted, so deploying at 6:00AM gave everyone a couple of hours before users got into the office. Service deployed, worked like a champ.
A week later the VP schedules a celebration for the successful migration to WCF. Pizza, cake, the works. The 3 team members received awards (and a envelope, which probably equaled some $$$) and the entire team received a custom Benchmade pocket knife to remember this project's success. Myself and several others just stared at each other, not knowing what to say.
Later, my manager pulls several of us into a conference room
Me: "What the hell? This is one of the biggest failures I've been apart of. We got rewarded for thousands and thousands of dollars of wasted time."
<others expressed the same and expletive sediments>
Mgr: "I know..I know...but that's the story we have to stick with. If the company realizes what a fucking mess this is, we could all be fired."
Me: "What?!! All of us?!"
Mgr: "Well, shit rolls downhill. Dept-Mgr-John is ready to fire anyone he felt could make him look bad, which is why I pulled you guys in here. The other sheep out there will go along with anything he says and more than happy to throw you under the bus. Keep your head down until this blows over. Say nothing."11 -
I realize I've ranted about this before, but...
Fuck APIs.
First the fact that external services can throw back 500 errors or timeouts when their maintainer did a drunk deploy (but you properly handled that using caching, workers, retry handlers, etc, right? RIGHT?)...
Then the fact that they all speak a variety of languages and dialects (Oh fuck why does that endpoint return a JSON object with int keys instead of a simple array... wait the params are separated with pipe characters? And the other endpoint uses SOAP? Fuck I need to write another wrapper class around the client...)
But the worst thing: It makes developers live in this happy imaginary universe where "malicious" is not a word.
"I found this cloud service which checks our code style" — hmm ok, they seem trustworthy. Hope they don't sell our code, but whatever.
"And look at this thing, it automatically makes database backups, just have to connect to it to DigitalOcean" — uhhh wait...
"And I just built this API client which sends these forms to be OCR processed" — Fuck... stop it... there are bank accounts numbers on those forms... Where's that API even located? What company?
* read their privacy policy *
"We can not guarantee the safety of your personal data, use at your own risk [...] we are located in Russia".
I fucking hate these millennial devs who literally fail to get their head out of the cloud.
Somehow they think it's easier to write all these NodeJS handlers and layers around some API, which probably just calls ImageMagick + Tesseract on the other side.
If I wasn't so fucking exhausted, I'd chop of their heads... but they're like hydra, you seal one privacy breach and another is waiting to be merged, these kids just keep spewing their crap into easy packages, they keep deploying shitty heroku apps... ugh.
😖8 -
Start a development job.
Boss: "let's start you off with something very easy. There's this third party we need data from. They have an api, just get the data and place it on our messaging bus."
Me: "sure, sounds easy enough"
Third party api turns out to have the most retarded conversation protocol. With us needing a service to receive data on while also having a client to register for the service. With a lot of timed actions like, 'send this message every five minutes' and 'check whether our last message was sent more than 11 minutes ago'.
Due to us needing a service, we also need special permissions through the company firewall. So I have to go around the company to get these permissions, FOR EVERY DATA STREAM WE NEED!
But the worst of it all is... This whole api is SOAP based!!
Also, Hey DevRant!5 -
Why in God's name would anyone use SOAP over Rest......
Because it makes you cleaner hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha9 -
Hi,
I'm not a ranty person so I never actually thought I'd post anything here but here it goes.
From the beginning.
We use ancient technologies. PHP 5.2, Symfony 1.2 and a non RFC complient SOAP with NO documentation.
A year ago We've been thrown a new temporary project. An VOIP app for every OS.
That being iOS, Android, MAC, PC, Linux, Windows mobile. With a 3 month deadline. All that thrown at 4 PHP developers. The idea being that They'll take it, sign the delivery protocol, everyone happy. No more updates for the app needed. They get their funds they needed the app for and we get paid.
Fast forward to today...
Our dev team started the year with great news that We'll most likely have to create a new project. Since the amount of new features would be far greater than current feature set, we managed to finally force our boss to use newer technologies (ie. seperate backend symfony4 PHP7+/frontend react, rest api and so on). So we were ecstatic to say the least. With preestimates aimed at a minimum 3 month development period. Since we're comfortable with everything that needs to be done.
Two days later our boss came to me that one of our most annoying clients needs a new feature. Said client uses ancient version written on a napkin because They changed half of the specification 2 weaks before deadline in a software made not by a developer but some sysadmin who didn't know anything. His MVC model was practically VVV model since he even had sql queries in some views. Feature will take 3 days - fixing everything that will break in the meantime - 1-2 months.
F*** it, fine. A little overtime won't kill me.
Yesterday boss comes again... Apparently someone lost a delivery protocol for a project we ended that half a year ago. Whats even better at the time when we asked for hardware to test we never got any. When we asked about any testing enviornment - nothing. The app being SEMI-stable on everything is an overstatement but it was working on the os'es available at the time. Since the client started testing now again, it turns out that both Android app does not work on 8.1/9 and the iOS app does not work on ios12. The client obviously does not want to pay and we can do little with it without the protocol, other than rewriting the apps.
It will take months at least since all of those apps were written by people that didn't know neither the OS'es nor the languages. For example I started writing the iOS one in swift. Only to learn after half of the development time, that swift doesn't like working by C Library rules and I had to use ObjC also. With some C thrown in due to the library. 3 unknown languages, on an unknown platform in 3 months. I never had any apple device in my hand at that time nor do I intend to now. I'm astonished it worked out then. It was a clusterf**k of bad design and sticking everything together with deprecated apis and a gum. So I'll have to basically fully rewrite it.
If boss decides we'll take all those at the same time I'll f***ing jump of a bridge.8 -
Fuck me in the ass, but do it harder then this api just so I can feel some love 😖
it's one of those days where you have to migrate from soap to rest, only the rest api doesn't have the same structure or search parameters as the soap api, so there's this entire fucking application sending requests at a brick wall, and expecting a purple throbbing 12 inch cock of xml to be pushed into an multi dimensional array and pushed through to the views to derange the mess, only you have to create that fucking 12 inch cock from several 2 inch dipsticks that have a different hierarchy, different field names, and merge the shit together with a glue gun...
good thing it's only an unexpected prod problem... right? 🤷♂️
Ah, the woes of a Monday on the legacy app adventures.1 -
Advice to new coders? I got multiple, unrelated to each other.
1. Start with the FUCKING BASICS !! Invest some time with fundamentals, don't just directly jump on frameworks like React or Angular.
2. You and everyone else are always going to blame your technical skills if you're unable to land a job. But you have to realize that is not always the case. Your attitude and energy towards the interviewer plays a vital role too.
3. You're gonna have to take a hit to your salary expectations starting out. It's just the way this industry works.
4. Think of yourselves as a freelancer working for companies. Those who call themselves Employees get stagnant and dependent on their company pretty fast.
5. Your objective is either to learn or earn. If there is both, amazing job. If there is either it's good enough. If there is none, time to jump ship !!
6. HR is there to protect the company from you not the other way around. Be better at spotting crocodile tears.
7. Try to find a WFH job over a WFO job. If you have an urgency, then either works but keep applying to WFH jobs. It's the best thing.
8. Focus on what you're building instead of what you're building it with. Devs have a tendency to fight over what tech stack they should use instead of focussing on the larger picture.
9. You're gonna get overwhelmed at some point when you're gonna get terms thrown at you like XML, JSON, API, Figma, Git, SOAP, REST. Don't worry though you'll get there.
10. You should know how to google your solutions, like really. This is like 60% of the job.19 -
If ever you felt imposter syndrome, it's after your senior experienced colleague rewrites an API you built... You've been chipping away at it for months, making it faster but reaching the limits of the functional but flawed original design.
In one week he starts it as a side project, and fixes the whole thing, soap to nuts... I need to sit down with that guy more.3 -
So there’s this SOAP api I have to use (not by choice, and not the only one i have to use) that returns a bunch of XML nodes to confirm the data sent made it and checks out - pretty standard stuff yea.
Now every once in a while it doesn’t respond (as far as I could tell) so today I wrapped a debug around the soap call, error handler and responses and threw a bunch of messages it’s way to try and force it not to respond in order to be able to put some decent error handling in place.
Well it wouldn’t fail.
100 messages .... all responses good
100 more.... all responses good
And then 100 more.... all respond with “x”, plain text not XML as expected!
Wtf is this shit!!!!!6 -
Last year I changed jobs from a large multi-national to a small local agency (which happens to be run by friends of mine).
One of the reasons for doing this was that my work involved more office politics than *actual* software development, and had just plain stopped being fun.
Now, I am having fun again! An example?
For one of our clients we have to connect to (a lot) of third-party APIs. Often even SOAP APIs!
Now I hear you protest "But that is no fun at all! SOAP APIS SUCK!" Which is true, more often than not. 😔
BUT! My friend started an internal API-SNAFU Trello board. Every time you get bitten in the ass by some ill conceived fuck-up of an API, you get to add your complaint to the board.
Beside giving as something to reciprocally rant about, the board also serves a serious function: depending on the amount of fuck-ups an API has been known to make, the price for working with that API will go up.
Who said it doesn't pay to complain? 😀1 -
Programming against a SOAP api, developed by the client in Visual FoxPro. Their whole system is in the language.
10 seconds API calls are "normal".
Luckely our backend rarely needs to talk to it 🎉1 -
Things that make you regret you are not a normal grunt in any other fucking job outside of software development...
Few years back we had the biggest customer ever close to signing contact with us (b2b). They had a CRM they wanted to connect to our CRM because their users didn't want to use IE with ActiveX anymore, the old software was a fucking RDP over IE to a server behind a VPN.
Boss brags how we can implement every API on Earth with our team and gets the contract signed. Technically not a lie but we agreed on a company meeting a few month prior to not implement each API for every customer but expose one ourselves because we had enough big customers on that one software to not want 100+ unique API connectors in our code.
So we apparently agreed to not only build our side of the API but also pay 2/3 of the bill of the other company for implement their shitty excuse of an API...
Fast forward a few month, talking to the other companies dev daily to get their API up and running, our part is long done. Finally get things set up and data flows... suddenly shit hits the fan. That shitty excuse of CRM can't expose the created and modified timestamps to the API. Webhooks never got implement and now we have no way of knowing which data changed because their side is completely passive.
Fast forward to a few weeks back. Still no solution. Shit is running, barely. Data inconsistency is low because everyone knows they should never change things in the old CRM because the changes might not be synced. (Only one indictor is a custom modified date on the main customer data that only updates if the main data was changed but there are 20+ different possible subsets. Can't get changes in subsets detected, like ever)
One fucking grunt updated 129 customer-profiles in the old CRM. Nothing was synced.
They still use the old shit for billing.
Their it-crowd-guy calls me up:
"Sorry but we need to generate the bills tomorrow and there seems to be some kind of desynchronization between the databases"
No shit? Someone did exactly what we told you not to do and now that one thing we warned you about happened but now it's our fault? Use the fucking force sync button we built for that purpose and that purpose alone. It will only take 7 days because that fucking SOAP API is slow as fuck and you have millions of datasets to sync...
Fml I might just try and jump out the window, sounds like a lot of fun in days like this.
tl;dr never implant against dynamics ax aif soap API if you want to keep some basic level of sanity2 -
I was asked what are the disadvantages of using RESTful over SOAP, I couldn’t think of any - maybe having to access a legacy system? Any ideas?7
-
We have to use a 20 year old API that is half assed and doesn't even work right every time.
Every three months the same discussion comes up why something doesn't work that relies on that API. I have to explain the situation over and over again... And then my boss starts to give 'solutions' which we already use or are utterly stupid... >.<
In case someone is wondering: SOAP API on a Windows Server 2003 with timeouts every few minutes and XML output in a language that is not English (even the tags!).3 -
anyone else, when reading documentation to some API, and you come across section titled "doing [whateveritis] via SOAP", you just laugh "hahaha, no way, sweety", and scroll past that section as fast as possible? =D1
-
I'm currently between jobs and have a few rants about my previous job (naturally). In retrospect, it's somewhat therapeutic to range about the sheer brainfuckery that has taken place. Enjoy!
First, let me set the scene: legacy B2B web app made with LEMP stack and sencha ext.js 3 + 4 (don't ask) and a lot of madness. Let's call that app "Alpha".
Alpha is a self made CMS build for typical ERP stuff. Yes, a self made CMS: entities are containers, containers have types and fields and values. Like so many legacy PHP apps, it does not have a dedicated FE: the HTML is rendered on the server and then spewed out to the browser.
Easy right? Coding like it's 1999! But there was a twist: Because everything is basically a container, the HTML-templates are saved in the DB. Along with the nessary JS and the CSS. And the translation variables. Why? Because fuck you! That's why. Who needs a git history anyways.
For some reason, Alpha was kinda slow.
There was also an editor, that allowed you to modify templates (web, mail, pdf) on the fly in prod. Because templates contain repeating data (header/footer), one template could contain additional templates. Much confusion. You could change templates via migration (slow, boring) or just ctrl-c/ctrl-v that sucker (fast, much excitement).
Did I mention Alpha was slow?
On with the rant: e-mails! How do they work? Noone knows. How to send mails asynchronous in PHP? Witchcraft is the only possible answer to that riddle. Here is your enterprise™ solution:
1. create mail
2. insert mail into DB
3. WAIT UP TO 59 SECONDS FOR A FUCKING CRON TO SEND MAIL
Why? "Because that way, we can resend mails in case the network is down :)"
Same procedure for the SOAP-API (db-queue + cron). You read that right: all requests to various other systems are processed once a minute.
Alpha slow.
Alpha was only one of several systems. Imagine a bunch of monolithic php apps, interconnected via SOAP, REST and GraphQL like a godamn intergalactic orgy. Image having to debug that cluster fuck.
Let's say there is a bad request. These things happen. No biggie. Remember the db-queue? Let's try to send the bad request a second time! And a third time! Still no luck? How odd. Let's create a specific file in a specific directory: a LOCK-file. Now, "the db-queue is on hold and no request gets processed :)"
Golly gee thanks Alpha.
Anyhow, did you know that MySQL has a join limit of 61 tables?
3 -
How can a shitty student information system that already costs $20k/yr have an optional shitty SOAP API module, that only allows read access to records, that has an initial setup fee of $5k plus $5k/yr?!5
-
Requests to a soap server were failing randomly. In order to contact the API provider, I tried to provide an curl example with the same payload and the error response. Yet when sending the payload over curl, the request worked just fine. When my application was building the request, it failed.
What. The. Fuck.
I checked and double-checked the request body and headers. They were identical.
Of course, no error response was returned by the API provider and, of course, they could not tell me how what error I caused in my request.
So I created a basic dummy server, installed wireshark and compared the payload when sending a request from my application and from curl to my dummy server.
It turns out: curl, if called in a certain way, automagically strips out newlines. The soap client kept them.
So that that shitty soap server crashed due to newlines in the message body!
Stripping out the newlines was rather easy.
Shame on you, your house, and entire family for letting it crash due to them!1 -
Had to work with a SOAP API that was described by its WSDL to have a property called "ShoppingCart". Wasted two days trying to figure out what's wrong. The customer sent a screenshot of their backends input mask. It was then that I noticed that the corresponding label read "ShopppingCart". Yes, that's what the property was actually named.1
-
I am forced to work with a client's notoriously slow SOAP api. Slow in this case is 1.5-2s per request.
The api is structured rather... creatively... at the same time. So we have to bombard it with thousands of requests to build our data base with historical SOAP data. Also the data sometimes is a couple of hours late, giving a flat line (all values at 0) until retroactively fixing the output for the same requests.
So to fill one dev data base with a year's worth of historical data (nice to have when testing a dashboard application) we hammer the api with ~20k requests (~1 million if we want to be thorough).
Best thing about that: There is no staging/test api and the prod api seems not to handle lots of requests at the same time very well...
Latest thought: Maybe we could put a varnish cache in front of the SOAP for testing. Better have wrong data, than nothing at all and we don't kill the prod clients every time we ramp up a new instance.
Also that would dramatically decrease the 4.2 hours of data pumping to about 7 minutes after the first run. -
I been using digital ocean to host my server for a project, but they seem to get shutdown because of DoS behaviour. I have no idea why. The server is doing some soap and rest communication and controlling a database.
To be fair the password was poor, but it was meant to be a fast way for four people to work on it at the same time.
But after the first shutdown, we rebuild the server and work on functions. Finish the work and went home. But in the server 9 hours of uptime with 2 of them unsupervised it was detected as DoS behaving server.
💻🔪2 -
Who in their right mind would do this / think of this....
Salesforce has the option use their API. Either via SOAP or Rest. At my work we currently use SOAP and I wanted to rewrite that to Rest. Fine, you would say.
Their Rest API uses oAuth, nothing fancy you would think. But those motherfuckers, per default have the option enabled that the refresh tokens you get via the necessary API calls are being marked expired the moment the API gives them to you... Then why the hell give them in the first place.
It took me 2 hours of my life to figure out, why in godsname all my refresh tokens were marked as expired. Fuck you Salesforce, I want those 2 hours back! God fucking damn it... I really fed up with this type of bullshit!! -
Many months into the project, we discovered that the client doesn't have a REST API for the data we needed from their side available at all - it's a legacy SOAP service.
I somehow got our Node.JS backend to do SOAP calls and use the XML results.
I'm not sure if I should feel proud or dirty at this point.3 -
I am implementing an API. How do I know what to do? Read the docs! Unless... there's none on the website. Asked by email and they could provide a PDF, which contains some graphics which you're free to interpret ...
Machine readable description? Nope.
How do I get to know about updates to the API? *blank stare*4 -
eTime Xpress by Celayix Software
Quite possibly the worst time and attendance software on the market. The only reason the company is still using it is because the big cheese refuses to pay any per user fees for any product whatsoever.
It requires an installation of Ericom because all supervisors must log in to schedule employees and record hours for payroll.
Printing is a nightmare to support because you're essentially printing through RDP and all print drivers for everyone's assortment of crappy printers must be installed on the server.
The software supports SOAP API calls, but it can't handle more than three concurrent requests without barfing, so you have to code your application around that...
I could go on... -
Enterprise projects can go to fucking hell. Clients are stupid ass morons. Zero fucking humanity in their money veins. OH LOOK THIS BUTTON DOESN’T WORK WITH OUR PROVIDED SOAP SHIT API. Oh really? I don’t give a flying fuck. Get that fucking soap from the ground and tell your external company to fucking start communicating like human beings. Fuck. A day will come when I will tell the fucking truth and I don’t care if that will cost me a workplace.
-
Previous job I worked, we had a system for taking bookings. I may have made a slight miscalculation in implementing the payment api. Which resulted in people being double charged, undercharged etc. Tbh the payment gateway was ancient and we had to grapple with their SOAP API not fun. But just shows we all made mistakes, suppose it's how you deal with them, when they crop up that defines us as devs.
-
Where have i been?
school > home > school > home > school > home
every day for 7 days a week.
Learning the Java Android API just finished learning about checkboxes and switches
my first school i started in when i was little got hit with rona (covid)
my sister's school 4th grade class got hit with rona (the whole class tested positive except for my sister's friend which tested negative Lucky by a strand of hair. if he wasn't in the morning annoucements then he would be sick)
didn't shut down the school to at least clean or did contact tracing just resumed normal work stuff
wearing a mask everyday to get a face breakout
the bathrooms and schools itself are getting damaged by devious licks which includes stealing and or damaging school property even taking bathroom toilets and soap / towel dispensers and selling or using them hmmm anyone else have anything thats worse than mine?2 -
Anyone knows if it is possible to do SOAP API with Javascript and bypass CORS, or work with it? if not **** this4
-
Im going to shove their soapy WordPress plugin up their ass sideways.
Just had to reverse engineer a WordPress plugin communicating with a SOAP API.
Why? Because the stupid fucking retard company thinks "we do not support custom integrations at this time, only plugins for certain CMS and some external providers" IS IN ANY WAY AN OK THING? IT IS NOT.
And i am feeling ashamed for having purchased a WordPress plugin (100 bucks) just for reversing it. My server even has to Report to them as wordpress to get access.
So fucking typical for swiss companies
Edit: also, they state they DO support custom integrations on their main website :/ -
working on simple crud is hell of boring thing now, gimme more challenges SoS, apis, payment gateways stuff...I need them like narcos
Top Tags
Weekly Rant
View