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
-
Hey everyone,
First off, a Merry Christmas to everyone who celebrates, happy holidays to everyone, and happy almost-new-year!
Tim and I are very happy with the year devRant has had, and thinking back, there are a lot of 2017 highlights to recap. Here are just a few of the ones that come to mind (this list is not exhaustive and I'm definitley forgetting stuff!):
- We introduced the devRant supporter program (devRant++)! (https://devrant.com/rants/638594/...). Thank you so much to everyone who has embraced devRant++! This program has helped us significantly and it's made it possible for us to mantain our current infrustructure and not have to cut down on servers/sacrifice app performance and stability.
- We added avatar pets (https://devrant.com/rants/455860/...)
- We finally got the domain devrant.com thanks to @wiardvanrij (https://devrant.com/rants/938509/...)
- The first international devRant meetup (Dutch) with organized by @linuxxx and was a huge success (https://devrant.com/rants/937319/... + https://devrant.com/rants/935713/...)
- We reached 50,000 downloads on Android (https://devrant.com/rants/728421/...)
- We introduced notif tabs (https://devrant.com/rants/1037456/...), which make it easy to filter your in-app notifications by type
- @AlexDeLarge became the first devRant user to hit 50,000++ (https://devrant.com/rants/885432/...), and @linuxxx became the first to hit 75,000++
- We made an April Fools joke that got a lot of people mad at us and hopefully got some laughs too (https://devrant.com/rants/506740/...)
- We launched devDucks!! (https://devducks.com)
- We got rid of the drawer menu in our mobile apps and switched to a tab layout
- We added the ability to subscribe to any user's rants (https://devrant.com/rants/538170/...)
- Introduced the post type selector (https://devrant.com/rants/850978/...) (which will be used for filtering - more details below)
- Started a bug/feature tracker GitHub repo (https://github.com/devRant/devRant)
- We did our first ever live stream (https://youtube.com/watch/...)
- Added an awesome all-black theme (devRant++) (https://devrant.com/rants/850978/...)
- We created an "active discussions" screen within the app so you can easily find rants with booming discussions!
- Thanks to the suggestion of many community members, we added "scroll to bottom" functionality to rants with long comment threads to make those rants more usable
- We improved our app stability and set our personal record for uptime, and we also cut request times in half with some database cluster upgrades
- Awesome new community projects: https://devrant.com/projects (more will be added to the list soon, sorry for the delay!)
- A new landing page for web (https://devrant.com), that was the first phase of our web overhaul coming soon (see below)
Even after all of this stuff, Tim and I both know there is a ton of work to do going forward and we want to continue to make devRant as good as it can be. We rely on your feedback to make that happen and we encourage everyone to keep submitting and discussing ideas in the bug/feature tracker (https://github.com/devRant/devRant).
We only have a little bit of the roadmap right now, but here's some things 2018 will bring:
- A brand new devRant web app: we've heard the feedback loud and clear. This is our top priority right now, and we're happy to say the completely redesigned/overhauled devRant web experience is almost done and will be released in early 2018. We think everyone will really like it.
- Functionality to filter rants by type: this feature was always planned since we introduced notif types, and it will soon be implemented. The notif type filter will allow you to select the types of rants you want to see for any of the sorting methods.
- App stability and usability: we want to dedicate a little time to making sure we don't forget to fix some long-standing bugs with our iOS/Android apps. This includes UI issues, push notification problems on Android, any many other small but annoying problems. We know the stability and usability of devRant is very important to the community, so it's important for us to give it the attention it deserves.
- Improved profiles/avatars: we can't reveal a ton here yet, but we've got some pretty cool ideas that we think everyone will enjoy.
- Private messaging: we think a PM system can add a lot to the app and make it much more intuitive to reach out to people privately. However, Tim and I believe in only launching carefully developed features, so rest assured that a lot of thought will be going into the system to maximize privacy, provide settings that make it easy to turn off, and provide security features that make it very difficult for abuse to take place. We're also open to any ideas here, so just let us know what you might be thinking.
There will be many more additions, but those are just a few we have in mind right now.
We've had a great year, and we really can't thank every member of the devRant community enough. We've always gotten amazingly positive feedback from the community, and we really do appreciate it. One of the most awesome things is when some compliments the kindness of the devRant community itself, which we hear a lot. It really is such a welcoming community and we love seeing devs of all kind and geographic locations welcomed with open arms.
2018 will be an important year for devRant as we continue to grow and we will need to continue the momentum. We think the ideas we have right now and the ones that will come from community feedback going forward will allow us to make this a big year and continue to improve the devRant community.
Thanks everyone, and thanks for your amazing contributions to the devRant community!
Looking forward to 2018,
- David and Tim
48 -
This story is 100% true.
I got hired onto a team of construction workers to build a house. We set up a meeting with Management to find out what kind of house they wanted us to build, where’s the floor plan, what it’s going to be used for, who it’s for, etc. Management said that they didn’t know all that, we should just get started. They told us that we were going to use “Agile” which means that we just work on small deliverables and build the thing incrementally.
The developer team lead argued that we at least need to know how big the thing is going to be so that we can get started pouring the foundation, but Management told him they just don’t know. “What we do know,” Management said, “is that the house is going to have a bathroom. Just start there, and we’ll know more when it’s done. You have two weeks.”
So we just bought a port-a-potty, and screwed around on the internet for two weeks. Management was outraged. “You call this a house? This is the worst house ever! It doesn’t even have a tv!”
So we bought a tv and put it in the port-a-potty, attached to an outdoor generator. We were going to buy a a dvd player and get it hooked up to cable, but Management rejected the expense request, saying that they didn’t know if we needed it, and we’d come back to that later.
Management decided that we definitely need storage space, so we bought a boxcar and duct-taped the port-a-potty to it. Then to our horror they set up some desks and put a few miserable business interns in there. It went on like this…
After a few years the boxcar grew into a huge, ramshackle complex. It floods, leaks, it’s frozen in the winter and an oven in the summer. You have to get around in a strange maze of cardboard tubes, ladders and slides. There are two equally horrible separate buildings. We’re still using just the one outdoor generator for all power, so electricity is tightly rationed.
Communication between the buildings was a problem. For one of them, we use a complex series of flag signals. For the other we write notes on paper, crumple the paper up, and toss it over. Both of these methods were suggested as jokes, but Management really liked them for some reason. The buildings mostly talk to each other but they have to talk through us, so most of what we do is pass messages on.
It was suggested that we use paper airplanes instead of crumpled up balls, but the fat, awkward fingers of the Business Majors who inevitably take those jobs couldn’t be trained to make them. I built an awesome automatic paper airplane folder, but once again they couldn’t be trained to use it, so they just went back to crumpling the notes up in balls.
The worst part of all this is that it’s working. Everyone is miserable, but the business is making money. The bright side is that this nightmare complex is done so now we know what kind of building they actually needed in the first place, so we can start work on it. Obviously we can’t tell Management anything about what we’re doing until it’s finished. They noticed the gigantic hole in the ground where the foundation is coming in, but we told them that it’s a cache reset, and they mostly ignore it except when the occasional customer falls in.
I’ll probably be out of here before the new building gets finished. I could get a 50% raise by switching jobs, but Management still doesn’t think I should get a raise because I missed a couple sprints.7 -
It's maddening how few people working with the internet don't know anything about the protocols that make it work. Web work, especially, I spend far too much time explaining how status codes, methods, content-types etc work, how they're used and basic fundamental shit about how to do the job of someone building internet applications and consumable services.
The following has played out at more than one company:
App: "Hey api, I need some data"
API: "200 (plain text response message, content-type application/json, 'internal server error')"
App: *blows the fuck up
*msg service team*
Me: "Getting a 200 with a plaintext response containing an internal server exception"
Team: "Yeah, what's the problem?"
Me: "...200 means success, the message suggests 500. Either way, it should be one of the error codes. We use the status code to determine how the application processes the request. What do the logs say?"
Team: "Log says that the user wasn't signed in. Can you not read the response message and make a decision?"
Me: "That status for that is 401. And no, that would require us to know every message you have verbatim, in this case, it doesn't even deserialize and causes an exception because it's not actually json."
Team: "Why 401?"
Me: "It's the code for unauthorized. It tells us to redirect the user to the sign in experience"
Team: "We can't authorize until the user signs in"
Me: *angermatopoeia* "Just, trust me. If a user isn't logged in, return 401, if they don't have permissions you send 403"
Team: *googles SO* "Internet says we can use 500"
Me: "That's server error, it says something blew up with an unhandled exception on your end. You've already established it was an auth issue in the logs."
Team: "But there's an error, why doesn't that work?"
Me: "It's generic. It's like me messaging you and saying, "your service is broken". It doesn't give us any insight into what went wrong or *how* we should attempt to troubleshoot the error or where it occurred. You already know what's wrong, so just tell me with the status code."
Team: "But it's ok, right, 500? It's an error?"
Me: "It puts all the troubleshooting responsibility on your consumer to investigate the error at every level. A precise error code could potentially prevent us from bothering you at all."
Team: "How so?"
Me: "Send 401, we know that it's a login issue, 403, something is wrong with the request, 404 we're hitting an endpoint that doesn't exist, 503 we know that the service can't be reached for some reason, 504 means the service exists, but timed out at the gateway or service. In the worst case we're able to triage who needs to be involved to solve the issue, make sense?"
Team: "Oh, sounds cool, so how do we do that?"
Me: "That's down to your technology, your team will need to implement it. Most frameworks handle it out of the box for many cases."
Team: "Ah, ok. We'll send a 500, that sound easiest"
Me: *..l.. -__- ..l..* "Ok, let's get into the other 5 problems with this situation..."
Moral of the story: If this is you: learn the protocol you're utilizing, provide metadata, and stop treating your customers like shit.22 -
I really fucking loathe StackExchange. Some poor soul had the nerve (THE NERVE!) to ask a question about something they didn't understand (HOW DARE THEY!):
"What is the difference between a ping and a get request? The goal is to see if the site is up."
And par for the course over at smarmy-fucking-smug-pedant-land, in less than three hours, the question was closed: "[C]losed as not a real question... It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form.
Allow me to indulge in some pedantic, "well actually" fuckery of my own...
Well actually, that actually is a 'real' question, because it's, you know, a fucking question. There's a question mark in there and everything! The person is asking what the difference is between two different things, and we can tell it's actually two different things because the person uses two different fucking nouns. And not only is this person asking to know what the difference is between these two different things, they even give us a use-case for why they're asking the question: they're pretty sure that they think they might know there's at least two different ways to check that their website is up, they just want to know what the difference is between those two methods -- hence the two different fucking nouns. It's almost like they're trying to give us some contextual information about why they're asking so that even if there is some vagueness to their question -- which is bound to happen IF YOU KNOW YOU DON'T KNOW EVERYTHING ABOUT THE SUBJECT, WHICH IS PROBABLY WHY YOU'RE FUCKING ASKING -- then a reasonable, decent, helpful person who is making a good-faith effort to be helpful can infer from that context enough information that clarifies the question enough to remove any vagueness or ambiguity and thus provide a helpful answer. AND THAT'S WHAT FUCKING HAPPENED!
And what just fucking galls me to no end... the question was answered (SUCCINTLY, INFORMATIVELY, SIMPLY, AND CORRECTLY!) and even marked as accepted in less than fifteen minutes after being asked.
And that didn't stop some smug fuck from being an asshole and closing the question because "fucking scrub noobfags need to git gud."
https://serverfault.com/questions/...
If MySpace was a place for friends,
then StackExchange is the place for insufferably elitist smug cunts.4 -
Dear Developers,
A. Please put your fucking functions in files with names related to the purpose of the functions.
B. Don't define your database management methods in your goddamn configuration file.
C. In addition, fucking document your shit at the top of the file if you refuse to abide by request A.
Someone is going to maintain or modify this code after you, and that person will have a hell of a time with it.3 -
Ahem ahem.
*clears throat*
Front end bois, listen that carefully.
YOU DONT FUCKIN TELL THE BACKEND HOW TO ACCEPT REQUESTS.
Backend creates the fuckin methods, the parameters and the responses, AND YOU FUCKIN ADAPT TO IT.
This guy at my work, we are both from Uni but i picked backend because i suck at frontend and i like using backend languages, sends me a message and tells me he can't make the project work.
At this time i have almost finished my part, i have made the method, have checked that they work, and i closed the work computer.
And now he tells me he wants to make a GET request instead of POST. LISTEN HERE MOTHERFUCKER. The methods are ready, adapt to them and shut the fuck up.
And before you tell me some methods don't work, make fuckin sure your part is correct because if i boot up the work laptop again to check why the method you have told me doesn't work, and it still does the job it was intented to do but you can't fix your part, i will fuckin cut your throat.
Sucker.
I do my part, and have to study for uni exams, since you don't have to because you have passed them, do your self a favor and fuckin learn to do things.
It's not my fault that i got experience on my own while you were just only doing our uni retarded projects and didn't bother to learn anything on your own.
I don't mean by any needs that i'm better than you but fuckin accept that i have learned something else that you have not and i would like to share the knowledge with you since you didn't bother.14 -
There was maybe one of the coolest methods of apply for a job. There was a company in Sydney on linkedin on the apply href for the job was pointing to localhost (might of been a accident) so you had to find their website and with the trailing url get to the page then they said to send OPTIONS request to a endpoint here you got a link to a api doc to where you send a POST to apply for a job they had a example body to use. So sending the Post request with with postman required headers so looking more into the doc it gave the headers needed. Now the example body for the post had some errors in it and once they are fixed you can then submit the request.
NOW thats the way to find competent developers shame I'm not one of the.5 -
"I'm almost done, I'll just need to add tests!"
Booom! You did it, that was a nuke going off in my head.
No, you shouldn't just need to add tests. The tests should have been written from the get go! You most likely won't cover all the cases. You won't know if adding the tests will break your feature, as you had none, as you refactor your untested mess in order to make your code testable.
When reading your mess of a test case and the painful mocking process you went through, I silently cry out into the void: "Why oh why!? All of this suffering could have been avoided!"
Since most of the time, your mocking pain boils down to not understanding what your "unit" in your "unit test" should be.
So let it be said:
- If you want to build a parser for an XML file, then just write a function / class whose *only* purpose is: parse the XML file, return a value object. That's it. Nothing more, nothing less.
- If you want to build a parser for an XML file, it MUST NOT: download a zip, extract that zip, merge all those files to one big file, parse that big file, talk to some other random APIs as a side-effect, and then return a value object.
Because then you suddenly have to mock away a http service and deal with zip files in your test cases.
The http util of your programming language will most likely work. Your unzip library will most likely work. So just assume it working. There are valid use cases where you want to make sure you acutally send a request and get a response, yet I am talking unit test here only.
In the scope of a class, keep the public methods to a reasonable minimum. As for each public method you shall at least create one test case. If you ever have the feeling "I want to test that private method" replace that statement in your head with: "I should extract that functionality to a new class where that method public. I then can create a unit test case a for that." That new service then becomes a dependency in your current service. Problem solved.
Also, mocking away dependencies should a simple process. If your mocking process fills half the screen, your test setup is overly complicated and your class is doing too much.
That's why I currently dig functional programming so much. When you build pure functions without side effects, unit tests are easy to write. Yet you can apply pure functions to OOP as well (to a degree). Embrace immutability.
Sidenote:
It's really not helpful that a lot of developers don't understand the difference between unit, functional acceptance, integration testing. Then they wonder why they can't test something easily, write overly complex test cases, until someone points out to them: No, in the scope of unit tests, we don't need to test our persistance layer. We just assume that it works. We should only test our businsess logic. You know: "Assuming that I get that response from the database, I expect that to happen." You don't need a test db, make a real query against that, in order to test that. (That still is a valid thing to do. Yet not in the scope of unit tests.)8 -
Data Engineering cycle of hell:
1) Receive an "beyond urgent" request for a "quick and easy" "one time only" data need.
2) Do it fast using spaghetti code and manual platforms and methods.
3) Go do something else for a time period, until receiving the same request again accompanied by some excuse about "why we need it again just this once"
4) Repeat step 3 until this "only once" process is required to prevent the sun from collapsing into a black hole
5) Repeat steps 1 to 4 until it is impossible to maintain the clusterfuck of hundreds of "quick and simple" processes
6) Require time for refactoring just as a formality, managers will NEVER try to be more efficient if it means that they cannot respond to the latest request (it is called "Panic-Driven Development" or "Crappy Diem" principle)
7) GTFO and let the company collapse onto the next Data Engineering Atlas who happens to wander under the clusterfuck. May his pain end quickly.2 -
While this wasn't technically a real client, it's still one of the most insane requests I've ever had.
I chose to specialize in software engineering for the last year and a half of my degree, which meant a lot of subjects were based around teamwork, proper engineering practises, accessibility, agile methods, basically a lot of stuff to get us ready to work in a proper corporate dev environment. One of our subjects was all about project management, and the semester-long coursework project (that was in lieu of a final exam) was to develop a real project for a real client. And, very very smartly, the professors set up a meeting with the clients so that the clients could tell us what they wanted with sixty-odd students providing enough questions. They basically wanted a management service for their day-center along with an app for the people there. One of the optional requirements was a text chat. Personally not something I'm super interested in doing but whatever, it's a group project, I'll do my part.
The actual development of the project was an absolute nightmare, but that's a story for another day. All I'll say is that seven juniors with zero experience in the framework we chose does not make a balanced dev team.
Anyway, like three months into the four-month project we've got a somewhat functional program, we just need to get the server side part running and are working our asses off (some more than others) when the client comes in and says that 'hey, nice app, nobody else has added the chat yet, but could you do voice recognition okay thanks?'.
Fucking.
Voice.
Recognition.
This was a fucking basic-ass management app with the most complicated task being 'make it look pretty' and 'hook up a DB to an API' and they want us to add voice recognition after sitting on their ass for three months??? The entire team collectively flipped its shit the second they were out of earshot. The client would not take no for an answer, the professor simply told us that they asked for it and it was up to us whether we delivered or not. Someone working on the frontend had the genius idea of 'just get them to use google voice recognition' so we added the how-to in the manual and ticked the requirement box.
What amazes me about all that is how the client probably had no idea that their new last-minute request was even a problem for us, let alone it being in a completely different ballpark in terms of implementing from scratch.9 -
> raw http request injected in the model
> 400 lines long method, followed by three 300 lines long methods
> no autocomplete, no comments
> code called by the whole application, I mess up once there's at least 150 other components that might break
> no documentation, no tests
> pyramid of doom, 13 levels of indentation
Those are the same people getting all puffed up because the cat dared to sit on my shoulder during a call. Management focused on the real fucking problems, no doubt.4 -
WTF freelancer, just won a design contest and it’s so fucking hard to withdraw the money to my bank account.
“There is some invalid bank details in your withdraw request, please confirm with your bank”
I never withdraw money before so i have to wait 15 days for my first withdrawal for each withdrawal methods.
The first method (express withdrawal with no fees) was failed because the bank details issue, talk with the cs and they told me to confirm to my bank, confirmed and tried again (only 1 or 2 days waiting time) but still failed, been trying this 3 times.
Trying the second method a.k.a wire transfer, i have confirmed the bank about what details are required to receive money from overseas first so i can prevent some stupid errors.
Wait another 15 days and ...
STILL FAILED WITH SAME PROBLEM
FUCK
This is the first time i regret when i won something.
ＦＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵＵ5 -
After a few weeks of being insanely busy, I decided to log onto Steam and maybe relax with a few people and play some games. I enjoy playing a few sandbox games and do freelance development for those games (Anywhere from a simple script to a full on server setup) on the side. It just so happened that I had an 'urgent' request from one of my old staff member from an old community I use to own. This staff member decided to run his own community after I sold mine off since I didn't have the passion anymore to deal with the community on a daily basis.
O: Owner (Former staff member/friend)
D: Other Dev
O: Hey, I need urgent help man! Got a few things developed for my server, and now the server won't stay stable and crashes randomly. I really need help, my developer can't figure it out.
Me: Uhm, sure. Just remember, if it's small I'll do it for free since you're an old friend, but if it's a bigger issue or needs a full recode or whatever, you're gonna have to pay. Another option is, I tell you what's wrong and you can have your developer fix it.
O: Sounds good, I'll give you owner access to everything so you can check it out.
Me: Sounds good
*An hour passes by*
O: Sorry it took so long, had to deal with some crap. *Insert credentials, etc*
Me: Ok, give me a few minutes to do some basic tests. What was that new feature or whatever you added?
O: *Explains long feature, and where it's located*
Me: *Begins to review the files* *Internal rage wondering what fucking developer could code such trash* *Tests a few methods, and watches CPU/RAM and an internal graph for usage*
Me: Who coded this module?
O: My developer.
Me: *Calm tone, with a mix of some anger* So, you know what, I'm just gonna do some simple math for ya. You're running 33 ticks a second for the server, with an average of about 40ish players. 33x60 = 1980 cycles a minute, now lets times that by the 40 players on average, you have 79,200 cycles per minute or nearly 4.8 fucking cycles an hour (If you maxed the server at 64 players, it's going to run an amazing fucking 7.6 million cycles an hour, like holy fuck). You're also running a MySQLite query every cycle while transferring useless data to the server, you're clusterfucking the server and overloading it for no fucking reason and that's why you're crashing it. Another question, who the fuck wrote the security of this? I can literally send commands to the server with this insecure method and delete all of your files... If you actually want your fucking server stable and secure, I'm gonna have to recode this entire module to reduce your developer's clusterfuck of 4.8 million cycles to about 400 every hour... it's gonna be $50.
D: *Angered* You're wrong, this is the best way to do it, I did stress testing! *Insert other defensive comments* You're just a shitty developer (This one got me)
Me: *Calm* You're calling me a shitty developer? You're the person that doesn't understand a timer, I get that you're new to this world, but reading the wiki or even using the game's forums would've ripped this code to shreds and you to shreds. You're not even a developer, cause most of this is so disorganized it looks like you copy and pasted it. *Get's angered here and starts some light screaming* You're wasting CPU usage, the game can't use more than 1 physical core, and after a quick test, you're stupid 'amazing' module is using about 40% of the CPU. You need to fucking realize the 40ish average players, use less than this... THEY SHOULD BE MORE INTENSIVE THAN YOUR CODE, NOT THE OPPOSITE.
O: Hey don't be rude to Venom, he's an amazing coder. You're still new, you don't know as much as him. Ok, I'll pay you the money to get it recoded.
Me: Sounds good. *Angered tone* Also you developer boy, learn to listen to feedback and maybe learn to improve your shitty code. Cause you'll never go anywhere if you don't even understand who bad this garbage is, and that you can't even use the fucking wiki for this game. The only fucking way you're gonna improve is to use some of my suggestions.
D: *Leaves call without saying anything*
TL;DR: Shitty developer ran some shitty XP system code for a game nearly 4.8 million times an hour (average) or just above 7.6 million times an hour (if maxed), plus running MySQLite when it could've been done within about like 400 an hour at max. Tried calling me a shitty developer, and got sorta yelled at while I was trying to keep calm.
Still pissed he tried calling me a shitty developer... -
Oh I have quite a few.
#1 a BASH script automating ~70% of all our team's work back in my sysadmin days. It was like a Swiss army knife. You could even do `ScriptName INC_number fix` to fix a handful of types of issues automagically! Or `ScriptName server_name healthcheck` to run HW and SW healthchecks. Or things like `ScriptName server_name hw fix` to run HW diags, discover faulty parts, schedule a maintenance timeframe, raise a change request to the appropriate DC and inform service owners by automatically chasing them for CHNG approvals. Not to mention you could `ScriptName -l "serv1 serv2 serv3 ..." doSomething` and similar shit. I am VERY proud of this util. Employee liked it as well and got me awarded. Bought a nice set of Swarowski earrings for my wife with that award :)
#2 a JAVA sort-of-lib - a ModelMapper - able to map two data structures with a single util method call. Defining datamodels like https://github.com/netikras/... (note the @ModelTransform anno) and mapping them to my DTOs like https://github.com/netikras/... .
#3 a @RestTemplate annptation processor / code generator. Basically this dummy class https://github.com/netikras/... will be a template for a REST endpoint. My anno processor will read that class at compile-time and build: a producer (a Controller with all the mappings, correct data types, etc.) and a consumer (a class with the same methods as the template, except when called these methods will actually make the required data transformations and make a REST call to the producer and return the API response object to the caller) as a .jar library. Sort of a custom swagger, just a lil different :)
I had #2 and #3 opensourced but accidentally pushed my nexus password to gitlab. Ever since my utils are a private repo :/3 -
Colleagues cannot seem to grasp that allowing a user to manually update a field via an Api, that only business process should update is a bad idea.
The entire team of around 10 'software developers' cannot grasp that just because the frontend website won't set it doesn't mean its secure. I have tried many times now...
Just an example honestly... Our project follows a concrete repository pattern using no interfaces or inheritance, returning anaemic domain models (they are just poco) that then get mapped into 'view models' (its an api). The domain models exist to map to 'view models' and have no methods on them. This is in response to my comments over the last 2 years about returning database models as domain transfer objects and blindly trusting all Posts of those models being a bad idea due to virtual fields in Ef.
Every comment on a pull request triggers hours of conversation about why we should make a change vs its already done so just leave it. Even if its a 5 minute change.
After 2 years the entire team still can't grasp restful design, or what the point is.
Just a tiny selection of constant incompetence that over the years has slowly warn me down to not really caring.
I can't really understand anymore if this is normal.3 -
Had to extend the platform of a customer. For one part of my task (generating an encrypted string) there already was a class with encryption and decryption methods. This class is used in a gazillion places all over the code, so I thought it might be a good idea to re-use already existing stuff... Until I saw that the encryption method using basic Java methods (all fine with that) wrapped in a try-catch block, 'cause the Java methods may throw, returning err.getMessage() in the catch block...
Yeah...sure...makes sense... Instead of throwing an error or returning null just remove the possibility to handle the error.
So I decided to basically copy the methods and return null so I can work with that.
Created a merge request and was told by another dev of that company to remove my own impelemtation of the encryption method and use the already existing. Arguing that I won't have a possibility to prevent my code, that returns an URI containing the encrypted string, from generating something like "http://..../Encryption failed because of null" without success.
So I had to use the already existing crappy code...5 -
The frontend developers in my company are the reason why I have anxiety. Here are few things that grinds my knees:
1) for a long time in projects, they deleted the auth token from their storage without integrating the logout api. They thought why use an API for that. :)
2) most of them had no clue that form fields could accept javascript as inputs and work as XSS vulnerabilities. This actually happened with a client, he got so fucking pissed.
3) One of them asked me to convert a PATCH request to DELETE cos fuck REST and HTTP methods.
For fuck’s sake. I need to get out of this place.4 -
I once had to write an http interceptor for a distributed api. The interceptor needed to use the request context and the user profile to work out if a particular type of content had previously been accessed. Anyway there were two methods to get the user profile getUserC and getUserD, turns out C stood for cache D stood for database. Of course I called getUserD I effectively wrote a database distributed denial of service tool into our app 😬 we got a call from our customer complaining that their exadata servers where grinding to a complete halt2
-
So i'm workin on a wrapper for an api, and it has authenticated endpoints. My request function has a check to see if the user has a token before making the authed request, but guess who forgot to actually mark like 20-40 different methods as authed : D2
-
My day is basically request methods going to my endpoint '/api/v33/nfwg/WHATDOYOUWANT'
Response '{ "primaryResp":"sorry no fucks were given"} -
Question regarding android. I am having a problem with retrofit (I am using moshi converter factory) and hope that you can help.
Basically I have a screen with 3 checkboxes. User is able to select any of these checkboxes, and also user is allowed to select none of them.
When user doesn't select any checkboxes and click complete button, I send a PATCH request to backend with a model which contains 3 null values.
Problem here is that PATCH request which is being sent doesn't include any properties which have been nulled.
I spent some time researching why retrofit/moshi doesn't serialize nulled properties and I found a fix.
So I have this line
.addConverterFactory(MoshiConverterFactory.create(moshi))
Which I replaced with
.addConverterFactory(MoshiConverterFactory.create(moshi).withNullSerialization())
Now nulls are serialized and I am able to send a PATCH request model with nulled values. However now I'm facing another problem. Across my app I'm using only one retrofit client and I don't want to serialize nulls for all requests. Also I don't want to create another retrofit client.
How can I fix this problem? As far as I've researched it seems that I need to add an adapter with toJson() and fromJson() methods and then somehow enable nullSerialization only for that adapter. However I don't completely understand that solution and not even sure how to handle it.1 -
TLDR: Wrote a custom class for writing apibtest cases for a project with zero code test coverage.
We have a project with zero test coverage. Recently, i was tasked with writing api test cases for said project, it might have taken me months to write tests for all endpoint, plus the main issue was that each endpoint needed to tested for all available user roles and permissions.
I tried the main stream approach of writing api tests, but ended up running into a lot of issues directly linked to our projects roles/permissions architecture (cherry on top some endpoint are apikey specific). Don't get me wrong in my opinion this is by far one of the best user roles architecture out there, but writing test cases keeping it in mind is pain in ***.
After trying out different testing methods and frameworks, i decided to write my own class by extending django test framework (which uses unitest)
- It has generator and validators for request and response.
- Supports testing for user roles and permissions.
- We won't have to make any changes to code after user role or permissions changes
- I just have to copy and past request and responses from postman api collection.😂
1 -
I feel like the "DEL | PUT | PATCH" verb are overrated. I still cannot see it's usefulness to this day.16
Top Tags
Weekly Rant
View