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 - "am i reacting well?"
-
You know. I have mixed feelings on the way people have been reacting to senzory's rant regarding the way he deals with clients. Some people believe that he is unethical, some people see it as just business(me included) but to see what the community says is somewhat interesting.
First, let me be clear on something: i have been fucked over by clients many times for being a nice guy and trying to play it nicely.
Because of this I am selective of who deserves good treatment and who gets to fuck off. But regardless of the client I do the same thing: regardless of who it is, nice or otherwise. If a project will take 1 week to complete then I tell them that it will take 3 to 4 weeks. Why? Well because I have many things on my plate, I am married and have two children, one lives with me and I try to spend as much time with them as I can. I work from 8 to 6, sometimes later and when I get home I sometimes don't do shit since at work I maintain the web services of 2 fucking college campuses.
I don't look for my clients. Through word of mouth they come to me. And being in a privileged position(there are about 5 devs here and they all suck) they can either do with my times and fees or can fuck off over the border where Pedro will do their shit on vbscript and classic ASP(which I like, but you know why this is not an option in 2018)
Apps can be sold for large quantities of money, regardless of what their use case is, if a company wants to outsource their apps to an external developer(such as yours truly) that means that they are willing to play the game. And that is what business is: a game, a survival game.
Where I live, a company will not think twice of firing a single mother for whatever reason. In the U.S of A, and specially in Texas, you can be fired for whatever reason. I have automated people's jobs without knowing it, I have made people lose their jobs and saved companies thousands with my apps. Things like that were not know to me, had I known that someone would have lost their jobs I would have tried differently.
If a company is willing to tell employees(loyal employees) to fuck off, then i do not regret charging what I do and hustling the way I do with rat faced dickheads that care not for people. If I could I would destroy entire companies here. But that is for another story.
I have been used, insulted, gambled with and have been lied to, to my face by these companies. Which has left me jaded.
Oh now, trust me. I am still highly optimistic and nice. And if someone has a small business and I can help them out, then I will lower my rate and give positive vibes in the hopes of making things better through karma. I want to see the best in people. But this does not stop me from being a shark and giving quotes the way I do.
Because companies, as an overall entity are not people with the best intentions(sometimes) and they will not take your kindness, they will take advantage if possible in an effort to save money. Its just dickhead business.
So why, as a professional and privileged developer that obtained his skills through intense study and practice, a wizard by all means, should lower to these nameless, Faceless entities?
Why should i give them the fairness they do not give others? Why should I play the high morale game and come out as a loser?
At the end of the day, I get to swim in my own pool of success, knowing that they did not get the chance to fuck me over
So if you tell me that you took advantage of your hard earned skillset, and built a cross platform app(which compiles to native binaries) and sold 2 products for one, I will tell you that you are an excellent player at their game. If you tell me that you finished before and got to charge for 2 weeks of work doing just 2 days I will say that you are an excellent time manager. And if you tell me that at the end of the day you managed to keep said customer I will tell you that you are a true professional.
There is a difference lads, in selling a product to big momma jamma's cajun restaurant, to the largest logistics company around.
Be nice to those that desserve it.6 -
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