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
-
Seniors: Welcome to the team. Feel free to ask anything if you need help. There is no such thing as stupid questions.
New Dev: Sure. Thanks.
*a few minutes later*
New Dev: How to comment a code?
Seniors: Google it....and please don't ask stupid questions.11 -
Marketing : Do you think we can implement this feature in a system?
Dev : Hmm....*checking specs*...This will...
Marketing : *interrupts* we have already signed a contract with a client.
Dev : ugh......7 -
People with "I am a senior, only I have to be right" mindset are really fustrating to work it.
It is not that hard to accept the truth. No one can be right all the time and no one gonna look down on you for that. You don't have to shove off-topic stuffs down the other people's throat when you realize you might be wrong.4 -
So, I had to listen very badly in a scrum about my poor code quality. Just because I haven't used the latest version of the library in my gradle build file, I haven't used DTO in the response of few endpoints in the controller class instead I used entity,... Etc was the mistake.
I admit that I have a long way to improve myself and there is a lot to learn, but there should be a proper way to escalate the situation rather than publicly pointing out mistakes rudely.
He is a senior with 10+ years of experience who badly told me in the scrum and not only that whenever there is a change needed in my PR he takes the screenshot and puts it in our dev team group and shows the mistakes and gives the suggestions instead of writing comments on the github PR.
Not only that, if I inform in the daily updates that I took 2 hours for this and that task, he says it should be done in 20 to 30 minutes.
Upper management has given him a lot of respect because he is knowledgeable and knows the stuff but it doesn't mean he is entitled to behave like this and demoralise other juniors.
The matter is cool now but this incident happened to me a few months back and those days were really toxic for me at work.5 -
This is the story of the API documentation.
Which btw I couldn't find on the producent's website anywhere. I had the pdf shared with me by a coworker.
I knew the api was fucked up the moment I looked at endpoint documentation.
GET params? WHERE, ORDERBY etc. Literally make a SQL select in a GET request.
Returned stuff? The whole thing. Not some DTO, you literally get everything you can get.
Eg if you get IP in your response, you get it in several formats: dotted form, as hex, and as int. In 3 different json fields.
Oh, and regarding IP - one would imagine you can use masks or prefixes for subnets, right? Nope. The only param you can use there is the subnet size. So you have to calculate the power of 2 every time you want to make a request.
That's from the endpoint documentation. But what about some general info on the API, before all that?
As I was looking for something, I decided to read that intro and general info about the API.
Okay, so there was a change log between API versions. "removed [endpoint which sounds like correct REST design], please use [this generic thing with SQL-like GETs]"... Several of them.
And there was also this sentence which said that the API is not restful, "it's REST-like". <facepalm>
If it was a bad attempt at REST API, I would let it go. But this sentence clearly showed they knew they did everything wrong. And the changelog showed they didn't stop there, they were actively making it worse.1 -
Initialize List ✔️
Initialize and hydrate DTO ✔️
Forget to add DTO to List and wonder why my list is returning empty?
Every fucking time!2 -
Company has a severe lack of fresh blood.
"let's recruit everyone who has an IQ over room temperature and barely passes the mark".
Me protesting bloody murder cause I know that the idea is not just profoundly dumb, but frustration from high staff turnover takes a toll on *everyone*.
"nah can't be that bad".
Then the discussion started who could do monitoring and mentoring, so we can sort out the bad apples *quickly*.
Me reminding again that this is exactly what leads to a high staff turnover, as this is nothing else than "hire, hire - quickly fire".
Guess who won the award of being the mentor / monitor ....
*drum roll*
Come on, I know you would NEVER expect this.
Let me surprise you: M E.
Yeah. They chose the person that was absolutely against this idea...
Because that person is "most qualified for the task at hand and has the necessary qualifications".
Today was the first 4 h workshop with a new recruit.
The Lord has had zero mercy on me.
I started to mute myself after 30 minutes in regular intervals to just scream and curse the world.
How profound dumb a person can be amazes me.
Person has had a "very expensive 6 month boot camp course".
I was close asking if the boot camp course was in watching porn and wanking their brain cells out....
Git... Yeah he knew what he was doing...
Except that he messed up every commit by either not sticking to the companies format or - what I found funny the first 2 times, then not so much anymore - just writing a git commit message like a 15 year old teenage girl would write to their diary.
Programming. Oh yeah. He should be a programmer.
He had much Bootcamp.
Bootcamp expensive. Bootcamp good.
If someone is unable to iterate over an iterator... And instead starts creating an integer based array of a map's key name to then fetch the map value in an for loop based on the created key array.
Yeah. Bootcamp much good.
Creating DTOs...
It took an hour to write a DTO with him... Cause constructors are hard and it's even harder when you have to explain primitive datatypes in Java, null safety, constructors, NPEs, final, ...
Like really no experience at all.
The next week's will be amazing.
Either I get a valium drop or I'm gonna blow my head off, cause mentoring will drain the last bit of hope I had left in me.
Note that I do not blame the recruit (yeah he's dumb. But he has ZERO work experience, so it's not unexpected), I'm just too fed up with getting the poo crown despite being against the whole process.
I think the recruit could make it..........
But that I got the shittiest job ever is really haunting me.
I dunno how I survive the next weeks.
And this is just the first recruit... There will be more.2 -
Worst part of coding lang I love?
C# being case-sensitive.
Not a C# language thing, but I hate the vilification and anti-coding standard of not 'allowing' prefixes. Interfaces are allowed (ex. IUpdateCustomer), why not classes? Why can't I have a DTO and declare it a TCustomer and the zealots not scream "HE'S USING HUNGARIAN NOTATION!!! TAKE HIM TO THE STAKE!!"?24 -
Don't people learn the basics of how things work anymore ?!
I am cleaning this project, where some juniors have implemente a lot of the code.
Apparently, the way of deleting an entity from the database is:
1) SELECT the entire row and cast it to a model class
2) CONVERT that model class to a DTO class
3) READ the Id property from the DTO class
4) SELECT the entire row, again, and this time cast it to a DTO class
5) CONVERT that DTO class to a model class
6) Use you pancy-pants ORM delete method using the entire model class as input argument..
FUCK YOU !
inb4 what about reference checks ?
- Nope. That is done separately using only the Id
inb4 what about checking if someone else has altered it before deleting
- Nope, the entire entity is not used for that either.3 -
I keep forgetting about Ctrl+space so I always end up trying all the letters on my keyboard to see a complete list of properties on a config DTO.
-
Asked us to build a car and later complain because it cannot fly.
And then, expect us to turn into a plane in 3days? -
Allright, so now I have to extend a brand new application, released to LIVE just weeks ago by devs at out client's company. This application is advertised as very well structured, easy to work on, µservices-based masterpiece.
Well either I lack a loooot of xp to understand the "µservices", "easy to work on" and "well structured" parts in this app or I'm really underpaid to deal with all of this...
- part of business logic is implemented in controllers. Good luck reusing it w/o bringing up all the mappings...
- magic numbers every-fucking-where... I tried adding some constants to make it at least a tiny bit more configurable... I was yelled at by the lead dev of the app for this later.
- crud-only subservices (wrapped by facade-like services, but still.. CRUD (sub)services? Then what's a repository for...?). As a result devs didn't have a place where they could write business logic. So business logic is now in: controllers (also responsible for mapping), helpers (also application layer; used by controllers; using services).
- no transactions wrapping several actions, like removing item from CURRENT table first and then recreating it in HISTORY table. No rollback/recovery mechanism in service layers if things go South.
- no clean-code. One can easily find lines (streams) 400+ cols long.
- no encapsulation. Object fields are accessed directly
- Controllers, once get result from Services (i.e. Facade), must have a tree of: if (result instanceof SomeService.SomeSubservice1.Item1) {...} else if (result instanceof SomeService.SomeSubservice2.Item4) {...} etc. to build a proper DTO. IMO this is not a way to make abstraction - application should NOT know services' internals.
- µservices use different tables (hats off for this one!) but their records must have the same IDs. E.g. if I order a burger and coke - there are 2 order items in my order #442. When I make a payment I create an invoice which must have an id #442. And I'm talking about data layer, not service or application (dto)! Shouldn't µservices be loosely coupled and be able to serve independently...? What happens if I reuse InvoiceµService in some other app?
What are your thoughts?1 -
Fucking dto hell...
Dear C#/.NET developers or any other developers, do you have a fucking smart approach/technique to handle the fucktons of dto classes throughout your webapi and not having to go to 5 different classes if you change some validation attributes ??
Seriously, that is the only thing I like about JS. It just does not fucking care...
EDIT: This rant came across and just fits perfectly: https://devrant.com/rants/68633811 -
Writing code at work be like:
Hmm okay so if I call this facade looking for an order with a code, and the order can't be found, it will return null. Thank God this bit of code is documented...
Ten minutes later
Why is this not throwing an exception when I pass invalid parameters in...?
Two minutes later
Oh, so this never returns null. If the order isn't found, it returns an empty DTO. Fucking docs.
Seriously, the only thing worse than no documentation is documentation that lies. And that's all I get for my first project at the company, which I am having to do alone. Either no docs, or misleading docs. -
Responding to a numb sales guys joke with "do you know the best about UDP jokes? - I don't care if you don't get it! " ...turnin around left the hallway... Unbeatable
-
Maybe someone can help me there.
I have to make a DDD project and I can't figure out in which layer I should put classes that - for example - convert objects from DAO to DTO or the Serializing functions.
Does someone who already made some. DDD help me?2 -
Don't you just hate it when there seems to be nothing but in some ways lacking solutions to a definite task in your capability arsenal? Or rather, I don't really know how I should feel about it... I've been developing this solution to receive a 3DES encrypted Azure Service Bus message, decrypting it and chewing the output XML down so as to be digestible to the PHP application whose API the message gets delegated to... but there just seems to be no perfect solution: subscribing to the event topic straight from the target app just... doesn't seem to work properly, a Python implementation.... well, let's just leave it at that... a Node.js implementation would require TS and completely rewriting a proprietary library with 100+ complex types - also, there's some hiccups with both the subscription and the decryption...
I started with an F# implementation (after deeming the PHP one flawed), and it seems it's still the best. But goddamn it I had problems with it on the dotnet core side of thing (decryption output incorrect), so I had to switch to dotnet framework... Now finally everything crucial is peachy, but I can't seem to be able to implement a working serialized domain model pipeline to validate the decrypted message and convert it to something easier to digest for the target application (so that I could use the existing API endpoint instead of writing a new one / heavily modifying the existing implementation and fear breaking something in the process...). I probably could do it in C#, I don't know, but for the love of Linus I'm not going to do it if I can avoid it, when implementing the same functionality I have now without the Dto and Domain type modules would take 3x LoC than the current F# implementation incl. the currently unused modules!
And then there's the problem of deployment... I have no idea what's the best way to deploy a dotnet framework module to an app completely based on MAMP running on a mostly 10yo AWS cloud solution. If I implemented a PHP or Node.js solution, it'd be a piece of cake, but... Phew, I don't know. This is both frustrating, overwhelming and exciting at the same time.7 -
JUST HAPPEND
tariner and coworker: when getting a dto lets make sure to get the object by a query before the function then pass only the object found
<couple of lines later>
see her the thing again....
me: this function you did it.
tariner and coworker: um.....mmmmm.
yeah this thing is wrong you should never do this...
(as if he made a mistake and covering it by telling me not to do it) -
So I'm new to NestJS, Node, etc. and I just noticed that the guy working on the API made every request call a different service class, instead of using a single service class. For example.
get() {
return await this.getObj.run()
}
post(myDto){
return await this.storeObj.run()
}
update(myDtoUpdate){
return await this.updateObj.run()
}
And I'm not sure why. He's also injecting the request into those classes, instead of passing the DTO to the method call. I mean, it's still injecting the data into it I guess, but it seems so roundabout. Something like this:
public constructor(
@Inject(REQUEST) private request: Request,
){}
I'm scared, but I'm not sure if it's just my own ignorance or a sixth sense telling me that this is gonna be a mess.
Have you seen APIs implemented this way? I can see the benefit of dividing the code into smaller classes, but it just seems overkill to me, specially when there's a big chance that code will be repeated (getting an entity by ID when updating it, for example).
I'm still in time to kill this with fire before a new monster is born though, so that's something.1 -
Since HR does job postings on StackOverflow I'm aware that they have a landing page. ...did not expect that. 😀😀
-
When do you use parameters in your Dto/ViewModel constructors?
I'm trying to explain to a senior developer, that we don't need to have all parameters for all properties,
we only need it to set default/private fields.3
Top Tags
Weekly Rant
View