The problem is that the types in Javascript + dependency injected AngularJS services are hidden. If you forget that "auth.loggedIn" is a value-type, you might unconsciously assume it's a reference type. This is one reason I prefer statically-typed languages -- it's much more difficult to make this sort of mistake since the type information is always visible even if you have the most basic IDE.
1. This tightly couples the service to the view. Changes in the view and/or service will potentially result in nasty surprises and spaghetti code. For instance, what happens if the business processes change one day and "login" needs to return "logged in but email address unconfirmed"? You want the rules to deal with that scenario confined to a LoginController, not scattered around through each view (consider: an omnipresent login box view vs. a login/signup form view used when a user performs an action that potentially requires login, e.g. "Checkout")
2. In reality, this simple sample obscures what happens in the real world when you add an input for the user key & password:
a. you will need to pass the parameters to the auth service. At that point hopefully you will won't do anything crazy and will simply e.g. bind the user key & password to $scope properties, and pass the scope properties through to the auth service.
b. As stated in (1), your login & logout controller functions need to consider the result of their auth calls and map that result back to a meaningful state for the view -- in the simplest case, it'll just be "logged in" or "logged out", but it can also be e.g. "logged in but email address unconfirmed", which could require a message to be displayed to the user. The best place for this state is again a $scope property.
So, in practice you would just use a $scope.loggedIn or $scope.user property maintained by the controller login() and logout() functions to resolve this issue.
Is it not ok to have all of that state you're talking about down in the service? In my experience any state you have in the controllers can be problematic in bigger apps. When I started out I used to proxy everything through the controller but I've found that you end up with a lot of duplication that doesn't ever seem to pay off.
When you're talking about the various auth states you might have - they could be changed by more than just this view. That state could also be exposed in different controllers / views in different ways. Sort of seems like the state that each of those would use is the same (that in the service) - so is it ok for the views to just reference that state in the service directly?
Interested in hearing where that falls down. I'm fairly new to developing rich interfaces and I've struggled to find completely deinitive information on how best to architect these patterns. Lots of examples out there bind the views to the services but that may be shortsighted.
I'm mostly a back-end developer and I don't have much experience with rich front-end interfaces other than my own little side projects and a WPF project from about a year back - however, I do believe the same principles apply to both front- and back-end design.
Specifically, you should be following the SRP - duplicated code is a symptom that you are not. Without seeing your code that you feel doesn't pay off, it's difficult to answer your question more directly.
I will say there's no reason you can't design your server-side services to be consumed directly by the view, in which case I wouldn't see a problem referencing the service directly from the view (e.g. the UserService exposed by the server implements (a) normal login, (b) login as part of checkout and (c) registration).
Alternatively, you could build a client-side service to wrap the server-side service and reference that directly from your views (e.g. a UserController that wraps the UserService and is consumed by (a) the omnipresent login view, (b) a login/signup view, and (c) the registration view).
Over and above this, there is some middle-ground where you reuse structures. For example, a User structure (with IsAuthenticated, UserName, FullName etc.) would be assigned to a $scope.CurrentUser property for the views. Consequently you don't reimplement the User object the service implements, and you don't vaguely depend on the entire UserService, but the data contract the view does depend on from the controller is still explicit by looking at the $scope definition in the controller. Similarly, the operation contract is defined by the controller functions. This improves maintainability and readability IMO.
It's a problem I have in Angular since I've started using it. You put your data/model in a service, but you need some GUI elements to display the various states of these data, so you put html in the view, some helpers in the controller, maybe you create some custom filters too. At that point you start to think a directive would be better.
Maybe the solution is to make separate modules ?
I'm not good enough in Angular or Javascript to have figured out the best solution yet.
These people are using Facebook with the expectation it works like email. Why do you feel the two are so different? In my experience, the average computer user doesn't like fiddling with email addresses - Facebook is far more friendly (opportunity for a new email client?).
Email is not immune to these issues, either. This scenario is the equivalent to sending an email and having it end up in your friend's spam folder (although arguably Facebook should be more heavily invested in getting this right!)
A middle class salary they can survive on for how long? When that source of income dries up they'll be unable to continue working on their passion without spending time and effort finding an additional source of income.
Alternatively, if they open themselves up to a strategy enabling a greater income they could potentially retire in a very short time with indefinite financial security and the option to pursue their passion as long as they like.
Taking the decision of living short-term in terms of salary can be a really liberating step in anyone's life. Especially if it is because of something you love passionately.
>A middle class salary they can survive on for how long?
Most middle class people aren't really financially independant either. 76% of people don't have any means to support themselves 6+ months out if they lose employment. Why should they?
> Most middle class people aren't really financially independant either.... Why should they?
Those people aren't really middle class. They just think they are.
"Middle class" has political and functional meanings beyond just "having near-average income". Nobody living paycheck-to-paycheck, no matter how big those paychecks are, can really function within the middle class.
The difference between lower class and middle class isn't income, it's assets. Because only assets beget independent economic and political power.
As recently as mid-20th century, an American talking about being "middle class" would have been referring to ownership of assets. Originally, of course, middle class was anyone who was neither a serf or a noble.
If you can't afford to tell your employer "fuck you" today, then you're a serf, and you have very little leverage.
You can be middle class and live paycheck-to-paycheck. There is nothing about that arrangement that prevents some folks from having assets, there is a reason the term "house poor" exists and there is a reason why foreclosure rates shot up for middle class people in the 2009 housing collapse.
Someone who is house poor has liabilities nearly as big as their assets, so their net assets are still nearly zero.
Nobody who actually owned their house free and clear got foreclosed on.
Again, if your existence is so tenuous, you are not middle class. At least not if the word still means what it meant for the past several hundred years.
My machine is always on. Subjectively, having 24GB of RAM made far more of a performance difference than my Plextor PX-256M3P, presumably because with 24GB of RAM pretty much everything of importance ends up being cached in RAM sooner or later.
I'm a contractor for two reasons: (1) money and (2) because I don't buy into the corporate PR. People who work in these places have to buy into the corporate values system.
I look at corporate values with great skepticism; perhaps I'm just cynical but in big companies it always seems to end up (in performance reviews) as being a way for the company to come back and justify why your bonus, increase, etc. will fall short of expectations this year.
> People who work in these places have to buy into the corporate values system.
Nope, it doesn't really go beyond some lip service. For most guys who do the actual work it's not even that - not shouting that the emperor has no clothes is absolutely enough to get by.
There are few high paid contractors in games, usually brought in to save a failing title. All these I know are engineers, not artists, high profile artists are usually commissioned (i.e. they sell their art without ever showing on site and probably don't even know what studio is buying their work).
Normally a contractor is a "employee -1" - same low pay but no benefits and even less job security. They don't get invited to meetings and are less privy of the internal politics. Most of them are working hard to become an FTE.
Let's dig into these numbers. Assuming the R40m value is correct over 3 years, then:
- since there are 248 working days in a South African year on average, the average daily cost ran to ~R53,763 or ~R6,720 per hour
- at the banks I've worked at, that'll buy you 10 intermediate on-site contract developers, or 6 senior developers, from an average consulting house which factors in all of these overhead expenses (including travel, etc.) you mention... and that's doing skilled development; this is WordPress work, but let's be generous and say they bill the same
It's hard to believe they required anywhere near that many developers (designers are much cheaper and I can't imagine they hired more than 1 or 2), or that hardware/service contracts would have cost much more.
How do you come to this conclusion? It doesn't appear she had much of a choice. Her two successful lawyers in a fancy, shiny, expensive office gave her this advice:
"I asked my lawyers to refuse, and we fought about it, repeatedly. They brought up things from my past that could be used against me; not criminal behavior per se, even they admitted, but they wanted me to have immunity."
Different people have different situations; no single piece of advice can apply to all people. Speaking for myself, if somebody placed me in a tricky position where my past could be used against me I would always put myself first if it meant protecting myself and my family.
Being a single mother is tough enough; being a single mother, struggling with money, involved in things you don't understand, being threatened by people with significant amounts of power (is it hard to believe eventually they would have done something to threaten her daughter?) would be enough to convince most normal people to speak. Given the information she had at the time she made a rational (debate-fully wrong) choice.
While there may be strong arguments for the case that the prosecutor's actions are unethical, ultimately Aaron's actions put her into this situation. His blaming her for her actions after being caught up in his battle, while wanting to protect herself and her child, is offensive to me.
It's sad that she beats herself up - she lost in a game she was not trained or skilled enough to win, a game somebody else forced her to play.
1) She ended up deciding those lawyers were crap, right?
2) Her lawyers didn't care at all about protecting Aaron, they cared about protecting her -- because that's 'officially' what lawyers are supposed to do, throw everybody but their client under the bus. (If you WANT to do this too, and you're being offered immunity, well, that's different).
3) Non-political laywers will often not have good advice in political cases, in part but not entirely because of #2 above. And probably related to her deciding #1 above in the end.
YES, being involved in things you don't understand, being threatened by peopel with power, etc., YES, that is enough to convince most normal people to speak. I am NOT blaming those who are duped into speaking, again, the cops are EXPERTS at duping you. Which is why I'm saying, when you hear about this happening to someone else, the more people that learn from it the better: don't talk to the cops.
Now, if you actually _want_ to accept an immunity deal to 'snitch' on someone else (say, because you think they ought to go to jail), then okay. But, other than that, if you think you can actually make things better for you or someone else by talking to the police -- well, like I said, we can't say in 100% of cases that won't work, never say never: We can say that you are unqualified to have any idea if it will work or not, and that usually it won't. Don't talk to the cops.
There are plenty of successful founders who didn't quit their jobs immediately to work on their startup. Not everybody has that luxury. Maybe you meant to limit your comment specifically to YC startups?
I partially agree with Pytrin. While its true not everyone quits their job to dive into a startup immediately, its arguable whether or not those are even startups yet or just projects.
That said, if you aren't at the stage where you can commit to doing a startup, you probably shouldn't be applying to YC.
I wouldn't say plenty - succeeding while working on a startup part-time is definitely the exception, and not the rule. I would love to hear some examples of those successful founders who succeeded while working part-time on their venture.
