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 - "cast away"
-
Oh yes, today was a fugly nice day.
Fuck you my dear boss.
Your mindless way of taking a dump onto my code, moving my classes (CSS) away and adding new classes to refuck my unfucked fuckery clearly shows how much brain is left in your hollow skull of nothingness.
It took me only 2.5 hours of my precious time to unfuck your refucked fuckery and implement the fix you wanted me to do because you fucked up my code.
Go eat a bag of segfaults and get cast to void* (void pointer).
I am also very thankful having spent the whole day today to fix cross browser fuckups, hacks and #!&$+@.
Normally I really like my boss. He is a cool guy and an innovative and mostly intelligent person.
BUT FUCK HIS CODE.16 -
I need some opinions on Rx and MVVM. Its being done in iOS, but I think its fairly general programming question.
The small team I joined is using Rx (I've never used it before) and I'm trying to learn and catch up to them. Looking at the code, I think there are thousands of lines of over-engineered code that could be done so much simpler. From a non Rx point of view, I think we are following some bad practises, from an Rx point of view the guys are saying this is what Rx needs to be. I'm trying to discuss this with them, but they are shooting me down saying I just don't know enough about Rx. Maybe thats true, maybe I just don't get it, but they aren't exactly explaining it, just telling me i'm wrong and they are right. I need another set of eyes on this to see if it is just me.
One of the main points is that there are many places where network errors shouldn't complete the observable (i.e. can't call onError), I understand this concept. I read a response from the RxSwift maintainers that said the way to handle this was to wrap your response type in a class with a generic type (e.g. Result<T>) that contained a property to denote a success or error and maybe an error message. This way errors (such as incorrect password) won't cause it to complete, everything goes through onNext and users can retry / go again, makes sense.
The guys are saying that this breaks Rx principals and MVVM. Instead we need separate observables for every type of response. So we have viewModels that contain:
- isSuccessObservable
- isErrorObservable
- isLoadingObservable
- isRefreshingObservable
- etc. (some have close to 10 different observables)
To me this is overkill to have so many streams all frequently only ever delivering 1 or none messages. I would have aimed for 1 observable, that returns an object holding properties for each of these things, and sending several messages. Is that not what streams are suppose to do? Then the local code can use filters as part of the subscriptions. The major benefit of having 1 is that it becomes easier to make it generic and abstract away, which brings us to point 2.
Currently, due to each viewModel having different numbers of observables and methods of different names (but effectively doing the same thing) the guys create a new custom protocol (equivalent of a java interface) for each viewModel with its N observables. The viewModel creates local variables of PublishSubject, BehavorSubject, Driver etc. Then it implements the procotol / interface and casts all the local's back as observables. e.g.
protocol CarViewModelType {
isSuccessObservable: Observable<Car>
isErrorObservable: Observable<String>
isLoadingObservable: Observable<Void>
}
class CarViewModel {
isSuccessSubject: PublishSubject<Car>
isErrorSubject: PublishSubject<String>
isLoadingSubject: PublishSubject<Void>
// other stuff
}
extension CarViewModel: CarViewModelType {
isSuccessObservable {
return isSuccessSubject.asObservable()
}
isErrorObservable {
return isSuccessSubject.asObservable()
}
isLoadingObservable {
return isSuccessSubject.asObservable()
}
}
This has to be created by hand, for every viewModel, of which there is one for every screen and there is 40+ screens. This same structure is copy / pasted into every viewModel. As mentioned above I would like to make this all generic. Have a generic protocol for all viewModels to define 1 Observable, 1 local variable of generic type and handle the cast back automatically. The method to trigger all the business logic could also have its name standardised ("load", "fetch", "processData" etc.). Maybe we could also figure out a few other bits too. This would remove a lot of code, as well as making the code more readable (less messy), and make unit testing much easier. While it could never do everything automatically we could test the basic responses of each viewModel and have at least some testing done by default and not have everything be very boilerplate-y and copy / paste nature.
The guys think that subscribing to isSuccess and / or isError is perfect Rx + MVVM. But for some reason subscribing to status.filter(success) or status.filter(!success) is a sin of unimaginable proportions. Also the idea of multiple buttons and events all "reacting" to the same method named e.g. "load", is bad Rx (why if they all need to do the same thing?)
My thoughts on this are:
- To me its indentical in meaning and architecture, one way is just significantly less code.
- Lets say I agree its not textbook, is it not worth bending the rules to reduce code.
- We are already breaking the rules of MVVM to introduce coordinators (which I hate, as they are adding even more unnecessary code), so why is breaking it to reduce code such a no no.
Any thoughts on the above? Am I way off the mark or is this classic Rx?16 -
Fuck it. Two big releases plus all the minor shit raining down on our team with only three active devs. A new team member who's unfortunately more of a burden and nuisance while the whole ship burns so beautifully....
And stupid me? I fucking break my arm, is in a cast now for four weeks. So I can mostly watch, while everything sinks.4 -
Most of us have scary stories about professors that think that they know about what they are talking about when it comes to teaching comp sci subjects. Shit is so backwards in most parts of the world with teachers showing outdated or completely pointless tech.
A friend called me the other day asking for classic ASP help because it was being used in his web class. Another was asking me about flipping c cgi web scripting. Wtf are schools teaching? Having the drive to LEARN actuall useful topics that are relevant on the market is hard enough as it is...shouldn't schools help at least a little bit? I was lucky, we were thaught Java, Python, cpp, js, sql, html5, css3, php, ruby and we had classes for node (for those interested) and asp.net mvc. Those were RELEVANT and good classes and while some outdated tech was good the rest is just bullshit. Specially since most teachers have 0 market value as develpers...but hey!! Wtf do I know! Of course my word is shit against all them doctorate and master degrees.
Gimme a break. School can be great. But a lot of the leadership there is toxic af for our industry. And while I appreciate the effort in me being thaught modern languages (and thaught is a hard word since I already knew how to program way before going to school) i still remember a teacher taking points away from an assignment for not using switch statements in Python...despite my explaining that there was no such thing (you can go around it by using a lil technique using functions, its pretty cool..pero no mames)
Or what about the time I mentioned to a fellow student how he could use markup for having more control with his windows forms while the very same teacher contradicted me saying that shit was not possible. Or the guy at the school in which I work teaching intro to programming using fucking vba...fk man if you are going the BASIC route at least teach them b4j or something fuuuuck.
I had good teachers, but they were always cast asside by dptmnt heads as if they knew better. I just hate pendejo teachers I really do.
Chinguen a su madre, bola de babosos.rant remembering uni yes asshole gnu linux is a viable alternative i still love coding fuck bad teachers fk the system11 -
A long time ago in a decision poorly made:
Past me: hmm we're having trouble getting IT to give us a new build machine with the new compilers.
Past me: I know we'll just use one of the PCs that belongs to a member of the team to tide us over.
[2 months pass]
Present me: that's odd, Jenkins is really slow today.
[Several minutes pass]
Present me: holly shit fuck; it's building the whole weekends worth of builds at 9am on a workday and eating licenses like a cast away that suddenly teleported to an all you can eat buffet.
Present me: [abort, abort, for the love of fuck abort]
Present me: contacts IT, they can't find any problems, wtf happened.
Present me: discovers team member turned off his machine on Friday and builds had been stacking up all weekend.
Lessons learnt: disable power button on team members pc and hire a tazer guy to shoot whenever someone goes near the wall socket.
1 hour lost and no build results for the last 3 days.
It's looking like a bad morning -
So I thought I had a basic, high level understanding of C++ STL strings, pointers, copy constructors and stuff. In comes a dirname, a -D_GLIBCXX_USE_CXX11_ABI=0 and... Toto, I've a feeling we're not in Kansas anymore.
So what is happening? I copy a string expecting a deep copy, but then I do the dirname or manipulation on the copy and it messes up *both* strings. gcc/C++ I know you're a beast, but what's going on there? Thing is only possible if I cast away const from c_str - which of course is a doubtful operation - but there also seems to be some strange copy on write logic that the data pointers initially point to same memory location and only with first manipulation on the copy they start to point to different addresses.
I had no clue. And still don't have.4 -
The bug: Some string values for an identifier property in the data objects are being sent from our frontend prefixed with a '0'. Sometimes. When it happens, it usually gets stripped away again by the time it's passed to our backend. But not always.
This 0 is never explicitly set anywhere. I even searched for a few variants of " = 0" in both the frontend and backend projects without receiving any results. You might already be suspecting where this is going.
So it turns out.
The data object which holds this value is being initialized in the aspnet (don't ask) backend and passed to the frontend, which then hydrates it. This value is always an integer number, albeit incidentally so which is why string is used as the actual type. When this object is initialized, it's hardcoded with an anonymous type where this property is set as int because I guess someone figured "it's always an int though". Being a typed language, primitive scalars can't be null objects which means the property's value becomes the concrete int 0.
Okay weird. I can think of better ways of doing this but let's just set it to string as I can't start overhauling things right now. Let's just go find where this value is somehow concatenated into the incoming parameter.
You see, this happens because at the point where the frontend sets this value, it may be an int or string depending on where it came from, and I guess someone figured that in order to cast it to string you just go prop += arg seeing as the prop is empty string and all. Because explicitly casting it or - as much as I get a rash whenever I see it - going prop = "" + arg would be too verbose and unoriginal.
Bonus round: How come the 0 only sometimes made it all the way to our backend? The thing is that this bug has been fixed before. The fix is that because this string is "always" an int, you can parse it to int before passing it to the backend in case it has leading zeroes. This path is only taken in certain views because someone forgot to copypaste their fix into all the places this is repeated.
Sometimes you find a bug and you are just somehow more grumpy after fixing it.1