The ER has to stabilize you. If you're dieing quickly- a stab wound, a heart attack, a bullet wound- they'll patch you up. They don't have to try to give you chemo, give you follow-up care for infections to the wounds (unless thhe infections become life threatening), or give you a bypass to prevent the next heart attack. That's not health care.
Funny- my most frequent jam on the break is leaving too much space on a highway, someone jumps into my lane and then slams on their break. Happens once a week in winter minimum. Apparently you either do all your driving on a private race track, or you're just flat out lying.
And by not breaking when the tires are locked, they recover faster, allowing you to break again sooner. Combined with sensors that test for locking and return results far faster than a human being can (which is how all modern ABS systems are made) they are better than you.
Bullshit. I'll bet you 1K that you can't stop on an icy road within 10% of the distance ABS can with 95% confidence. A human being is just not capable of making that judegement fast enough, and it doesn't have the sensors to tell the small differences the car can in traction. The very fact you think you can means that you're completely fucking incompetent as a driver.
The reason race cars don't have it is that races are canceled if the conditions out are going to be unsafe. They don't have races in sub-optimal conditions, so special safety equipment for it is unneccessary. In the real world, we can't stop going to work because of ice or rain.
Because we don't have to. The addition of these features is a minor percentage of the cost, probably saves more than it costs in terms of serious injury medical costs, and saves lives in addition.
And really, ABS not a safety feature? In the 2/3 of the US where it snows, it's probably a more important safety feature than the seatbelt. In Chicago as early as 96, I was taught drivers ed assuming that every car I'd ever used would have it, because it was that fucking common. I doubt even 25% of the population knows how to use non-ABS breaks. Even those of us who do would probably blank out in an emergency- when I had the breaks totally fail on my car a few years ago my thought was to break harder, not to pump the break.
Power steering isn't as important, but easier steering allows for faster reactions in an emergency. It most definitely is a safety feature. And I sure as hell don't want to share the road with a new car without it- even if the car I buy has it, their car not having it increases my risk of an accident.
Technology moves forward. As things become cheaper and as we get better ideas to improve safety, things that were previously considered too expensive to mandate become cheap enough to require them, and everyone becomes safer. This is called progress, and its a damn good thing.
You have tons of experience. If you're any good at all, you don't need a class, in fact a class will go far too slow. You need to get your hands dirty. Just pick something that you think would be fun, pick an existing app for it, and copy it. You learn more by doing than reading.
Depends on what your goals are. If your goals are to be used by as many people as possible, you're right. If your goals are to promote free software, you're wrong. I disagree that its a hollow victory though- I'd call it a hollow victory if you sold out your goals and views in exchange for shinier graphics.
I do agree that some things should be LGPLed, that's a strategic call. I'm not sure if I'd agree on this piece of code though.
If they want to duplicate the functionality, that's their choice. They can then pay for doing that.
If we end up with worse drivers because of it, that's something I'm completely willing to accept. On this issue the philosophical points far outweigh practical to me.
I'll use BSD code. I respect the people who choose to write it. But I have not and never will contribute to a BSD project- if I release code as open, I want it to stay open in all its derivations. I explicitly do not want someone to ever use it without keeping their derivations open. I'll consider something like the LGPL, depending on the code, where changes to the code I wrote need to be contributed but not to code that links to it. But never a purse BSD.
The best is update when I say to. Unless its adding a feature that I personally will use, I don't want the UI to change AT ALL. When I'm ready for a new major version I'll learn it all at once. Until then, I want it static. That's the reason I'm using SeaMonkey and not Chrome or Firefox.
No, this is why it's GOOD, and why many developers, myself included, will not work on non-GPL projects. Without the GPL, they would have taken this code and added it to their proprietary code bases and we'd never have seen future improvements of it. That's not a good thing, ever.
May depend on the age of the programmer. 32 years old, self taught then a degree. I taught myself C++ at 15. I didn't teach myself everything right (I had a so-so grasp on pointers, for example. Took a C++ course in college to explain them, and took an assembly course in college to truly grok them). I went to college with a bunch of self-taught coders, they all used C++. May be different for the current batch in their lower 20s, but it didn't used to be the case.
I've never seen a contract that pays more than what I make as a full time employee. Most make less. Some pay the same per hour, but pay no vacation, holidays, or health benefits. For the best contract I've ever been offered it would have been a big pay cut. Maybe as a *consultant* you can make more money, but not as a contractor.
Do the math. A decent senior dev job pays 100-150K, unless you live out in the boonies (this would be a standard rate in Seattle, Bay area, or DC for example). You have 2 weeks of company holidays and 3 of vacation a year. Divide that out, and its an hourly rate of 53-80/hr. That's before factoring in insurance and other benefits like 401K matching, stock, bonuses, etc. Add in $10/hr to cover that, at least. You never see hourly contract rates that high. Oh, and don't forget to save extra for in between contracts.
There's a small fraction of people who just want to be their "own boss" no matter what (although I think contracting doesn't really qualify for that, you just change bosses every few months). Some of them do contracting. Most of them end up forming or working for a startup. But I don't know anyone who idolizes contractors. If anything it's the opposite- contractors are treated like shit because they're not real employees, get all the boring work, get lower pay.
Don't get me wrong, I hope it works out for you. But your opinions of contracting are 100$ polar opposite of what everyone in my realm of experience thinks. Out of curiosity, are you government right now? The one person I know who loves contractors and thinks they're great is a manager for the federal government.
Except most good programmers won't take a contract job, especially once they're experienced. Doubly so if they have to move to take the job. If you aren't willing to commit to me and give me benefits, then I'm not taking the job. I don't know any good programmer who's worked a contract gig after being in the industry a few years. The few who do are people who don't want full time jobs, they want to be their own boss.
If you're on a tech website and reading an article about cell phones without knowing what an IMEI is, you're hopeless to begin with. It's a common enough acronym that no, they shouldn't spell it out- you should stop being a dumbass.
You miss my point. These are examples of common use cases (except perhaps for the compass sensor) that almost every Android developer ends up writing on their own. They ought to be handled by the framework or by common libraries but they aren't. Its also not meant to be an exclusive list, or even a list of the most important issues (although I think you drastically underestimate the importance of convenience methods). This is what I've found deficient in the last month as I transitioned from working on one mega-app (Swype) full time to churning out small apps for myself and freelance gigs between now and my new job starting.
1)Splash screens- who says that I wasn't doing something useful in the background? You still need to display something to the user while waiting for that web request to load. It's an extremely frequent use case (popping up a dialog for either x time or until a condition) and ought to be a standard widget.
2)Common intents- the point here is to make it easy to write simple apps. These again are common use cases. And I can't say I've ever had problems because of the different hardware decoders.
3)WebImageView- you seem to miss the point. These are examples of simple things that ought to be handled by framework or common libraries but aren't, causing every developer to waste time and effort writing their own. Oh, and my version does optionally cache it and look for a cached version first.
4)Convenince methods- You'd be insulted if they heralded it as an improvement? I'm insulted that they waste our time with an overly complex API. Of course it does follow the Java standard for IO in that respect- 4 levels of inheritance too much and 5 useless classes thrown in. In reality, when you make a web request you want to do one of a few things with it- write it to a file, or read it in as one of a half dozen common data types. Providing a power user interface for those who need it is great, but not providing the simple method for the 99% of usecases where that's all you need is fucking stupid.
5)JSON parsing- I've heard decent things about GSON. I'm just leery of using it unless Android is a supported platform, I don't want to self-maintain it. I don't doubt GSON probably performs better than my home grown solution (I know my home grown solution right now doesn't support nulls or allow field names matching java keywords). But half the reason I wrote it was to understand JSON and reflection better, so mission accomplished there. Still, if you're making a massive framework rather than a thin SDK, this ought to be part of it.
Back then most compilers didn't even do templates. We're talking 1996- Borland was still one of the most popular compilers, and if it ever had templates it was the last version.
Yes, but this entire discussion is about using new features. So you're going to make calls to functions/classes that don't exist in older versions. This is ok for a graphical difference or two, but not for major work.
Yeah, but to get it to compile with conditional execution you have to wrap everything in reflection. Which bloats the code and reduces readability significantly. Better than nothing, but nowhere near as convenient.
As for the UI backports- some do. Most don't, or have half working solutions. I haven't looked into them in a while, maybe things have changed. But even for the limited usecases we had at my last job we decided the support library was just not feasible.
Slashdot Mirror
The way to game that is to get to be the man making those decisions. Sometimes, there's just no way to win. You pick the least bad route.
The ER has to stabilize you. If you're dieing quickly- a stab wound, a heart attack, a bullet wound- they'll patch you up. They don't have to try to give you chemo, give you follow-up care for infections to the wounds (unless thhe infections become life threatening), or give you a bypass to prevent the next heart attack. That's not health care.
Funny- my most frequent jam on the break is leaving too much space on a highway, someone jumps into my lane and then slams on their break. Happens once a week in winter minimum. Apparently you either do all your driving on a private race track, or you're just flat out lying.
And by not breaking when the tires are locked, they recover faster, allowing you to break again sooner. Combined with sensors that test for locking and return results far faster than a human being can (which is how all modern ABS systems are made) they are better than you.
Doesn't matter- nobody reads the tests. They go on gut feelings- and gut feelings say a tiny little car hit by an SUV is going to go splat.
Bullshit. I'll bet you 1K that you can't stop on an icy road within 10% of the distance ABS can with 95% confidence. A human being is just not capable of making that judegement fast enough, and it doesn't have the sensors to tell the small differences the car can in traction. The very fact you think you can means that you're completely fucking incompetent as a driver.
The reason race cars don't have it is that races are canceled if the conditions out are going to be unsafe. They don't have races in sub-optimal conditions, so special safety equipment for it is unneccessary. In the real world, we can't stop going to work because of ice or rain.
Because we don't have to. The addition of these features is a minor percentage of the cost, probably saves more than it costs in terms of serious injury medical costs, and saves lives in addition.
And really, ABS not a safety feature? In the 2/3 of the US where it snows, it's probably a more important safety feature than the seatbelt. In Chicago as early as 96, I was taught drivers ed assuming that every car I'd ever used would have it, because it was that fucking common. I doubt even 25% of the population knows how to use non-ABS breaks. Even those of us who do would probably blank out in an emergency- when I had the breaks totally fail on my car a few years ago my thought was to break harder, not to pump the break.
Power steering isn't as important, but easier steering allows for faster reactions in an emergency. It most definitely is a safety feature. And I sure as hell don't want to share the road with a new car without it- even if the car I buy has it, their car not having it increases my risk of an accident.
Technology moves forward. As things become cheaper and as we get better ideas to improve safety, things that were previously considered too expensive to mandate become cheap enough to require them, and everyone becomes safer. This is called progress, and its a damn good thing.
Switch to SeaMonkey. They have the same renderer, don't change their UI every week, and actually seems to use less memory.
You have tons of experience. If you're any good at all, you don't need a class, in fact a class will go far too slow. You need to get your hands dirty. Just pick something that you think would be fun, pick an existing app for it, and copy it. You learn more by doing than reading.
These jokes are real turkeys
Depends on what your goals are. If your goals are to be used by as many people as possible, you're right. If your goals are to promote free software, you're wrong. I disagree that its a hollow victory though- I'd call it a hollow victory if you sold out your goals and views in exchange for shinier graphics.
I do agree that some things should be LGPLed, that's a strategic call. I'm not sure if I'd agree on this piece of code though.
If they want to duplicate the functionality, that's their choice. They can then pay for doing that.
If we end up with worse drivers because of it, that's something I'm completely willing to accept. On this issue the philosophical points far outweigh practical to me.
I have two for them. Fuck off.
I'll use BSD code. I respect the people who choose to write it. But I have not and never will contribute to a BSD project- if I release code as open, I want it to stay open in all its derivations. I explicitly do not want someone to ever use it without keeping their derivations open. I'll consider something like the LGPL, depending on the code, where changes to the code I wrote need to be contributed but not to code that links to it. But never a purse BSD.
The best is update when I say to. Unless its adding a feature that I personally will use, I don't want the UI to change AT ALL. When I'm ready for a new major version I'll learn it all at once. Until then, I want it static. That's the reason I'm using SeaMonkey and not Chrome or Firefox.
No, this is why it's GOOD, and why many developers, myself included, will not work on non-GPL projects. Without the GPL, they would have taken this code and added it to their proprietary code bases and we'd never have seen future improvements of it. That's not a good thing, ever.
May depend on the age of the programmer. 32 years old, self taught then a degree. I taught myself C++ at 15. I didn't teach myself everything right (I had a so-so grasp on pointers, for example. Took a C++ course in college to explain them, and took an assembly course in college to truly grok them). I went to college with a bunch of self-taught coders, they all used C++. May be different for the current batch in their lower 20s, but it didn't used to be the case.
I've never seen a contract that pays more than what I make as a full time employee. Most make less. Some pay the same per hour, but pay no vacation, holidays, or health benefits. For the best contract I've ever been offered it would have been a big pay cut. Maybe as a *consultant* you can make more money, but not as a contractor.
Do the math. A decent senior dev job pays 100-150K, unless you live out in the boonies (this would be a standard rate in Seattle, Bay area, or DC for example). You have 2 weeks of company holidays and 3 of vacation a year. Divide that out, and its an hourly rate of 53-80/hr. That's before factoring in insurance and other benefits like 401K matching, stock, bonuses, etc. Add in $10/hr to cover that, at least. You never see hourly contract rates that high. Oh, and don't forget to save extra for in between contracts.
There's a small fraction of people who just want to be their "own boss" no matter what (although I think contracting doesn't really qualify for that, you just change bosses every few months). Some of them do contracting. Most of them end up forming or working for a startup. But I don't know anyone who idolizes contractors. If anything it's the opposite- contractors are treated like shit because they're not real employees, get all the boring work, get lower pay.
Don't get me wrong, I hope it works out for you. But your opinions of contracting are 100$ polar opposite of what everyone in my realm of experience thinks. Out of curiosity, are you government right now? The one person I know who loves contractors and thinks they're great is a manager for the federal government.
Except most good programmers won't take a contract job, especially once they're experienced. Doubly so if they have to move to take the job. If you aren't willing to commit to me and give me benefits, then I'm not taking the job. I don't know any good programmer who's worked a contract gig after being in the industry a few years. The few who do are people who don't want full time jobs, they want to be their own boss.
That was supposed to be "<word> define". Fuck slashcode, I posted it at plain old text.
If you type " define" its almost always the first result. Works well for acronyms too.
If you're on a tech website and reading an article about cell phones without knowing what an IMEI is, you're hopeless to begin with. It's a common enough acronym that no, they shouldn't spell it out- you should stop being a dumbass.
You miss my point. These are examples of common use cases (except perhaps for the compass sensor) that almost every Android developer ends up writing on their own. They ought to be handled by the framework or by common libraries but they aren't. Its also not meant to be an exclusive list, or even a list of the most important issues (although I think you drastically underestimate the importance of convenience methods). This is what I've found deficient in the last month as I transitioned from working on one mega-app (Swype) full time to churning out small apps for myself and freelance gigs between now and my new job starting.
1)Splash screens- who says that I wasn't doing something useful in the background? You still need to display something to the user while waiting for that web request to load. It's an extremely frequent use case (popping up a dialog for either x time or until a condition) and ought to be a standard widget.
2)Common intents- the point here is to make it easy to write simple apps. These again are common use cases. And I can't say I've ever had problems because of the different hardware decoders.
3)WebImageView- you seem to miss the point. These are examples of simple things that ought to be handled by framework or common libraries but aren't, causing every developer to waste time and effort writing their own. Oh, and my version does optionally cache it and look for a cached version first.
4)Convenince methods- You'd be insulted if they heralded it as an improvement? I'm insulted that they waste our time with an overly complex API. Of course it does follow the Java standard for IO in that respect- 4 levels of inheritance too much and 5 useless classes thrown in. In reality, when you make a web request you want to do one of a few things with it- write it to a file, or read it in as one of a half dozen common data types. Providing a power user interface for those who need it is great, but not providing the simple method for the 99% of usecases where that's all you need is fucking stupid.
5)JSON parsing- I've heard decent things about GSON. I'm just leery of using it unless Android is a supported platform, I don't want to self-maintain it. I don't doubt GSON probably performs better than my home grown solution (I know my home grown solution right now doesn't support nulls or allow field names matching java keywords). But half the reason I wrote it was to understand JSON and reflection better, so mission accomplished there. Still, if you're making a massive framework rather than a thin SDK, this ought to be part of it.
Back then most compilers didn't even do templates. We're talking 1996- Borland was still one of the most popular compilers, and if it ever had templates it was the last version.
Yes, but this entire discussion is about using new features. So you're going to make calls to functions/classes that don't exist in older versions. This is ok for a graphical difference or two, but not for major work.
Yeah, but to get it to compile with conditional execution you have to wrap everything in reflection. Which bloats the code and reduces readability significantly. Better than nothing, but nowhere near as convenient.
As for the UI backports- some do. Most don't, or have half working solutions. I haven't looked into them in a while, maybe things have changed. But even for the limited usecases we had at my last job we decided the support library was just not feasible.