Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "error logs on success"
-
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 wrote a database migration to add a column to a table and populated that column upon record creation.
But the code is so freaking convoluted that it took me four days of clawing my eyes out to manage this.
BUT IT'S FINALLY DONE.
FREAKING YAY.
Why so long, you ask? Just how convoluted could this possibly be? Follow my lead ~
There's an API to create a gift. (Possibly more; I have no bloody clue.)
I needed the mobile dev contractor to tell me which APIs he uses because there are lots of unused ones, and no reasoning to their naming, nor comments telling me what they do.
This API takes the supplied gift params, cherry-picks a few bits of useful data out (by passing both hashes by reference to several methods), replaces a couple of them with lookups / class instances (more pass-by-reference nonsense). After all of this, it logs the resulting (and very different) mess, and happily declares it the original supplied params. Utterly useless for basically everything, and so very wrong.
It then uses this data to call GiftSale#create, which returns an instance of GiftSale (that's actually a Gift; more on that soon).
GiftSale inherits from Gift, and redefines three of its methods.
GiftSale#create performs a lot of validations / data massaging, some by reference, some not. It uses `super` to call Gift#create which actually maps to the constructor Gift#initialize.
Gift#initialize calls Gift#pre_init (passing the data by reference again), which does nothing and returns null. But remember: GiftSale inherits from Gift, meaning GiftSale#pre_init supersedes Gift#pre_init, so that one is called instead. GiftSale#pre_init returns a Stripe charge object upon success, or a Gift (and a log entry containing '500 Internal') upon failure. But this is irrelevant because the return value is never actually used. Pass by reference, remember? I didn't.
We're now back at Gift#initialize, Rails finally creates a Gift object using the args modified [mostly] in-place by all of the above.
Another step back and we're at GiftSale#create again. This method returns either the shiny new Gift object or an error string (???), and the API logic branches on its type. For further confusion: not all of the method's returns are explicit, and those implicit return values are nested three levels deep. (In Ruby, a method will return the last executed line's return value automatically, allowing e.g. `def add(a,b); a+b; end`)
So, to summarize: GiftSale#create jumps back and forth between Gift five times before finally creating a Gift instance, and each jump further modifies the supplied params in-place.
Also. There are no rescue/catch blocks, meaning any issue with any of the above results in a 500. (A real 500, not a fake 500 like last time. A real 500, with tragic consequences.)
If you're having trouble following the above... yep! That's why it took FOUR FREAKING DAYS! I had no tests, no documentation, no already-built way of testing the API, and no idea what data to send it. especially considering it requires data from Stripe. It also requires an active session token + user data, and I likewise had no login API tests, documentation, logging, no idea how to create a user ... fucking hell, it's a mess.)
Also, and quite confusingly:
There's a class for GiftSale, but there's no table for it.
Gift and GiftSale are completely interchangeable except for their #create methods.
So, why does GiftSale exist?
I have no bloody idea.
All it seems to do is make everything far more complicated than it needs to be.
Anyway. My total commit?
Six lines.
IN FOUR FUCKING DAYS!
AHSKJGHALSKHGLKAHDSGJKASGH.7 -
!rant
Need some opinions. Joined a new company recently (yippee!!!). Just getting to grips with everything at the minute. I'm working on mobile and I will be setting up a new team to take over a project from a remote team. Looking at their iOS and Android code and they are using RxSwift and RxJava in them.
Don't know a whole lot about the Android space yet, but on iOS I did look into Reactive Cocoa at one point, and really didn't like it. Does anyone here use Rx, or have an opinion about them, good or bad? I can learn them myself, i'm not looking for help with that, i'm more interested in opinions on the tools themselves.
My initial view (with a lack of experience in the area):
- I'm not a huge fan of frameworks like this that attempt to change the entire flow or structure of a language / platform. I like using third party libraries, but to me, its excessive to include something like this rather than just learning the in's / out's of the platform. I think the reactive approach has its use cases and i'm not knocking the it all together. I just feel like this is a little bit of forcing a square peg into a round hole. Swift wasn't designed to work like that and a big layer will need to be added in, in order to change it. I would want to see tremendous gains in order to justify it, and frankly I don't see it compared to other approaches.
- I do like the MVVM approach included with it, but i've easily managed to do similar with a handful of protocols that didn't require a new architecture and approach.
- Not sure if this is an RxSwift thing, or just how its implemented here. But all ViewControllers need to be created by using a coordinator first. This really bugs me because it means changing everything again. When I first opened this app, login was being skipped, trying to add it back in by selecting the default storyboard gave me "unwrapping a nil optional" errors, which took a little while to figure out what was going on. This, to me, again is changing too much in the platform that even the basic launching of a screen now needs to be changed. It will be confusing while trying to build a new team who may or may not know the tech.
- I'm concerned about hiring new staff and having to make sure that they know this, can learn it or are even happy to do so.
- I'm concerned about having a decrease in the community size to debug issues. Had horrible experiences with this in the past with hybrid tech.
- I'm concerned with bugs being introduced or patterns being changed in the tool itself. Because it changes and touches everything, it will be a nightmare to rip it out or use something else and we'll be stuck with the issue. This seems to have happened with ReactiveCocoa where they made a change to their approach that seems to have caused a divide in the community, with people splitting off into other tech.
- In this app we have base Swift, with RxSwift and RxCocoa on top, with AlamoFire on top of that, with Moya on that and RxMoya on top again. This to me is too much when only looking at basic screens and networking. I would be concerned that moving to something more complex that we might end up with a tonne of dependencies.
- There seems to be issues with the server (nothing to do with RxSwift) but the errors seem to be getting caught by RxSwift and turned into very vague and difficult to debug console logs. "RxSwift.RxError error 4" is not great. Now again this could be a "way its being used" issue as oppose to an issue with RxSwift itself. But again were back to a big middle layer sitting between me and what I want to access. I've already had issues with login seeming to have 2 states, success or wrong password, meaning its not telling the user whats actually wrong. Now i'm not sure if this is bad dev or bad tools, but I get a sense RxSwift is contributing to it in some fashion, at least in this specific use of it.
I'll leave it there for now, any opinions or advice would be appreciated.question functional programming reactivex java library reactive ios functional swift android rxswift rxjava16