We spend more money on the military than every other country on earth combined. This with an existing nuclear arsenal that could destroy any country 10 times over. We should be slashing military spending to the bone- its just not needed. How about reducing military spending to even just say triple what China (the number 2 country) spends? We're fucking ridiculous.
He wasn't trying to spend his way out of debt. He was trying to spend his way out of recession- something that does work if you borrow (or use savings) the money you do it on and the cause of the recession was lack of consumer confidence/demand or lack of capital (which this was in part). The trick is that you have to make up for it in good times by repaying the debt, something we've been bad at. Also, it helps if the extra money being spent is on things with long term results like infrastructure and R&D. Spending it on things like wars will give a short term bump but no long term advantages.
THe fact is right now our debt not only doesn't matter, any business leader in the world would be telling us to take on more of it. We're borrowing at about 1% interest. That means if we have anything to invest in that would pay better than 1% return, we ought to borrow to pay for it. Since the rate of inflation is higher than that, anything with any real long term value is a good buy, as the principal will be less when due than it is now. Debt really isn't a short term problem for us.
I understand and acknowledge that this Agreement is not intended to require assignment of any of my rights in an invention that I develop entirely on my own time without using the Company's equipment, supplies, facilities or trade secret information except for those inventions that either: (1) relate at the time of conception or reduction to practice of the invention to the Company's business, or actual or demonstrably anticipated research or development of the Company; or (2) result from any work performed by me for the Company.
That's what I have now, or close enough (I googled for a similar clause so I could copy-paste). I also had one once that had this and further spelled out that minor uses of company time/resources (such as answering a related email while at work) did not count as using work resources, but case law has established that as well.
Typically not working for a competitor is a separate item in the contract. That's a reasonable restraint. But if I'm writing something not related to my job at your company? God damn right that's mine. I've heard of contracts that are more restrictive, but I've never been handed one and I'd refuse to sign if asked.
1)Because wrapping also would have broken the UI. Printed page, remember? It would have pushed data off the page. And in that particular app, the printed page was a scantron, changing line positions would have moved bubbles and broken the parser. But even in a normal printed page there's a hard bottom and sides you can't write past.
2)Wrapping might take care of it- if there's room to wrap. And if you don't care about an ugly result. And if there's a place to wrap- you can't just wrap mid-word. And if you're in a wrappable language (can you wrap chinese/japanese?). And then we can deal with left to right vs right to left languages and how they'd have to be handled differently.
Translations aren't simple. There's good rules of thumb that will reduce problems, but just saying "oh, do this one thing and you're good" shows you don't understand the problem. Flexible sized fields in particular only work if either the screen scrolls (and you're ok with scrolling) or if you have lots of empty space in the design. A busy design and you're fucked, text will overrun each other.
Works great for some applications. Doesn't work when using or previewing a printed page (as was my case). Doesn't work if it pushes other data off the screen. Life isn't that simple, unfortunately.
And a lot of them aren't. You can get a much cleaner, better UI in a native app than HTML, and you don't have to deal with the horrible GUI editing language that is XML or the utter pile of shit that is Javascript. So the user and programmer get better experiences. Native apps are always better, its just a matter of if its worth the cost to make one.
I think he was lookign at websites- rentacoder, freelancer.com, elance, etc. The hourly rates there are very low, because they're used to hire people in 3rd world countries and by people who have no real respect for your work. And plenty of high school/college kids who bid low thinking it will lead to future work. Freelancing pays well, but only if you drum up the work yourself.
If an employer asks you to do this, don't fucking sign it. I've had many employers over the years. Every agreement I've ever signed has said anything done on my time with my equipment is mine. Done on work time with work equipment is theirs. Don't accept anything more restrictive than that, its not worth it. Make them change it or find another job, they'll get the idea pretty quickly.
I've done a bit of traveling and found that in most of Europe its the opposite- almost everyone I talked to in eastern europe spoke at least basic English. Many of them were fluent. They teach it in elementary schools out there.
Not always possible. I once has a string that said "double". It was translated into about 20 languages just fine- until it went to polish where the string from the translater was a 16 character long word. There wasn't enough room on the control, or even in the control's parent to make it fit. We ended up rebasing just that language to use "2" instead of double. Always leave some extra room, but understand that we can't work miracles, and that translaters can't use completely different terms guessing what we need for a string (they don't know how its used in the app).
Wouldn't matter. The problem is more political than technical. Carriers are the ones who push updates, and they don't care especially in the US. Check EU versions of US phones and you'll see many more updates that never make it out here.
Some of that is for a good reason. Carriers put phones through very rigorous acceptance testing that takes weeks to finish. It tests the phone as a whole, not individual modules. Trying to push out partial updates would screw with their process and cost tens of millions. It would also lead to people having versions of modules that were never tested together, an increased possibility of bricking your phone. When your device is seen as a consumer utility that just really isn't an option.
I'm not. Google and Amazon are bigger industry names, look better on a resume. And are more likely places a young person would target, so they can pay less and still get quality choices.
Then his string terminates sooner than the data stream he types. Which won't break anything. The key is you don't rely on the user to enter the terminating null, just like you don't rely on them to enter a length field.
Crashing is NEVER acceptable. And you cannot assume its ever an option in a production system- when you crash cleanup code is not necessarily run, and you can leave the system in an unrecoverable state. Fucking amateur.
Then instead of an assert you should have a return error (or throw exception) statement. You should NEVER have an assert that doesn't also cause an error return. That's fucking programming 101- because the asserts WILL be compiled out in release builds, and because crashing could leave the system in an unrecoverable state- you ALWAYS kick the error up to a level that can deal with it.
The user never types in a null terminated string. They type in a sequence of bytes and the program turns it into a null terminated string. Strings with separate lengths work the same way- would you trust a length field coming straight from a user?
Asserts in testing are a good thing. Crashes in release are not. Asserts should be removed and you either process a sane default or abort the function returning an error, depending on the situation. That may even trickle up to the top level which may decide to exit gracefully telling the user what the problem was. But you do NOT crash.
Totally and completely fucking wrong. A well written program should not crash for any reason. It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.
The one thing I can think of that would be useful is a shopping list- scan a bar code when you use up an item, have it synch to the cloud, and be able to see the list on your phone when you shop. Or a reverse shopping list- a list of items you have. I'm always wondering if I already have spice/seasoning X when I'm at the store.
But other than that I don't really see much I want automated. I don't want automatic purchasing, I don't use enough food being single. Maybe preheat the over for me as I drive home? But chances are I don't want to cook as soon as I walk in the door anyway. What else is there?
Android now supports multiple users as of 4.2. I don't know how much control that gets you for that level of use. I also don't know how willing users would be to log into different accounts (or understand the concept). But its an interesting idea.
Because the big feature of Blackberrys was always business features, like exchange integration and email encryption. Iphone and Android have been eating away at this market. This advice is to tie them up again. Too little too late, but it would have been sound advice 4 years ago.
I'll say never. The slight advantage it can give you through not having to 0 base an array (for example you may want your calendar to be labeled days 1-31) is far offset by the loss of readability by anyone else who ever has to maintain your code, especially since not all of them will be perl masters.
Slashdot Mirror
We spend more money on the military than every other country on earth combined. This with an existing nuclear arsenal that could destroy any country 10 times over. We should be slashing military spending to the bone- its just not needed. How about reducing military spending to even just say triple what China (the number 2 country) spends? We're fucking ridiculous.
He wasn't trying to spend his way out of debt. He was trying to spend his way out of recession- something that does work if you borrow (or use savings) the money you do it on and the cause of the recession was lack of consumer confidence/demand or lack of capital (which this was in part). The trick is that you have to make up for it in good times by repaying the debt, something we've been bad at. Also, it helps if the extra money being spent is on things with long term results like infrastructure and R&D. Spending it on things like wars will give a short term bump but no long term advantages.
THe fact is right now our debt not only doesn't matter, any business leader in the world would be telling us to take on more of it. We're borrowing at about 1% interest. That means if we have anything to invest in that would pay better than 1% return, we ought to borrow to pay for it. Since the rate of inflation is higher than that, anything with any real long term value is a good buy, as the principal will be less when due than it is now. Debt really isn't a short term problem for us.
I understand and acknowledge that this Agreement is not intended to require assignment of any of my rights in an invention that I develop entirely on my own time without using the Company's equipment, supplies, facilities or trade secret information except for those inventions that either: (1) relate at the time of conception or reduction to practice of the invention to the Company's business, or actual or demonstrably anticipated research or development of the Company; or (2) result from any work performed by me for the Company.
That's what I have now, or close enough (I googled for a similar clause so I could copy-paste). I also had one once that had this and further spelled out that minor uses of company time/resources (such as answering a related email while at work) did not count as using work resources, but case law has established that as well.
Typically not working for a competitor is a separate item in the contract. That's a reasonable restraint. But if I'm writing something not related to my job at your company? God damn right that's mine. I've heard of contracts that are more restrictive, but I've never been handed one and I'd refuse to sign if asked.
1)Because wrapping also would have broken the UI. Printed page, remember? It would have pushed data off the page. And in that particular app, the printed page was a scantron, changing line positions would have moved bubbles and broken the parser. But even in a normal printed page there's a hard bottom and sides you can't write past.
2)Wrapping might take care of it- if there's room to wrap. And if you don't care about an ugly result. And if there's a place to wrap- you can't just wrap mid-word. And if you're in a wrappable language (can you wrap chinese/japanese?). And then we can deal with left to right vs right to left languages and how they'd have to be handled differently.
Translations aren't simple. There's good rules of thumb that will reduce problems, but just saying "oh, do this one thing and you're good" shows you don't understand the problem. Flexible sized fields in particular only work if either the screen scrolls (and you're ok with scrolling) or if you have lots of empty space in the design. A busy design and you're fucked, text will overrun each other.
Works great for some applications. Doesn't work when using or previewing a printed page (as was my case). Doesn't work if it pushes other data off the screen. Life isn't that simple, unfortunately.
And a lot of them aren't. You can get a much cleaner, better UI in a native app than HTML, and you don't have to deal with the horrible GUI editing language that is XML or the utter pile of shit that is Javascript. So the user and programmer get better experiences. Native apps are always better, its just a matter of if its worth the cost to make one.
I think he was lookign at websites- rentacoder, freelancer.com, elance, etc. The hourly rates there are very low, because they're used to hire people in 3rd world countries and by people who have no real respect for your work. And plenty of high school/college kids who bid low thinking it will lead to future work. Freelancing pays well, but only if you drum up the work yourself.
If an employer asks you to do this, don't fucking sign it. I've had many employers over the years. Every agreement I've ever signed has said anything done on my time with my equipment is mine. Done on work time with work equipment is theirs. Don't accept anything more restrictive than that, its not worth it. Make them change it or find another job, they'll get the idea pretty quickly.
I've done a bit of traveling and found that in most of Europe its the opposite- almost everyone I talked to in eastern europe spoke at least basic English. Many of them were fluent. They teach it in elementary schools out there.
Not always possible. I once has a string that said "double". It was translated into about 20 languages just fine- until it went to polish where the string from the translater was a 16 character long word. There wasn't enough room on the control, or even in the control's parent to make it fit. We ended up rebasing just that language to use "2" instead of double. Always leave some extra room, but understand that we can't work miracles, and that translaters can't use completely different terms guessing what we need for a string (they don't know how its used in the app).
Just get a Google TV. Its already an Android device.
Wouldn't matter. The problem is more political than technical. Carriers are the ones who push updates, and they don't care especially in the US. Check EU versions of US phones and you'll see many more updates that never make it out here.
Some of that is for a good reason. Carriers put phones through very rigorous acceptance testing that takes weeks to finish. It tests the phone as a whole, not individual modules. Trying to push out partial updates would screw with their process and cost tens of millions. It would also lead to people having versions of modules that were never tested together, an increased possibility of bricking your phone. When your device is seen as a consumer utility that just really isn't an option.
I'm not. Google and Amazon are bigger industry names, look better on a resume. And are more likely places a young person would target, so they can pay less and still get quality choices.
Then his string terminates sooner than the data stream he types. Which won't break anything. The key is you don't rely on the user to enter the terminating null, just like you don't rely on them to enter a length field.
You can remove asserts because your program is NEVER supposed to rely on them. The following code:
assert(foo!=null); //do something
is WRONG. Because it depends on the assert. The correct way to code it is
if(foo == null){ //do something
assert(false);
return some_error_value;
}
Crashing is NEVER acceptable. And you cannot assume its ever an option in a production system- when you crash cleanup code is not necessarily run, and you can leave the system in an unrecoverable state. Fucking amateur.
Then instead of an assert you should have a return error (or throw exception) statement. You should NEVER have an assert that doesn't also cause an error return. That's fucking programming 101- because the asserts WILL be compiled out in release builds, and because crashing could leave the system in an unrecoverable state- you ALWAYS kick the error up to a level that can deal with it.
The user never types in a null terminated string. They type in a sequence of bytes and the program turns it into a null terminated string. Strings with separate lengths work the same way- would you trust a length field coming straight from a user?
Asserts in testing are a good thing. Crashes in release are not. Asserts should be removed and you either process a sane default or abort the function returning an error, depending on the situation. That may even trickle up to the top level which may decide to exit gracefully telling the user what the problem was. But you do NOT crash.
Totally and completely fucking wrong. A well written program should not crash for any reason. It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.
The one thing I can think of that would be useful is a shopping list- scan a bar code when you use up an item, have it synch to the cloud, and be able to see the list on your phone when you shop. Or a reverse shopping list- a list of items you have. I'm always wondering if I already have spice/seasoning X when I'm at the store.
But other than that I don't really see much I want automated. I don't want automatic purchasing, I don't use enough food being single. Maybe preheat the over for me as I drive home? But chances are I don't want to cook as soon as I walk in the door anyway. What else is there?
Android now supports multiple users as of 4.2. I don't know how much control that gets you for that level of use. I also don't know how willing users would be to log into different accounts (or understand the concept). But its an interesting idea.
Because the big feature of Blackberrys was always business features, like exchange integration and email encryption. Iphone and Android have been eating away at this market. This advice is to tie them up again. Too little too late, but it would have been sound advice 4 years ago.
I'll say never. The slight advantage it can give you through not having to 0 base an array (for example you may want your calendar to be labeled days 1-31) is far offset by the loss of readability by anyone else who ever has to maintain your code, especially since not all of them will be perl masters.
Not to be done, period. There is no reason to really need to, and it garuntees that nobody will ever understand your code.