I agree with you that this sort of publication of charges instead of convictions sucks.
However, your characterization of drunk drivers is just wrong. They ARE incredibly dangerous. They ARE reckless, and while they may not intentionally be seeking out people to mow down, they are showing a tremendous disregard for those same people.
Buying Chocolate when you wanted Strawberry is a bad decision. Getting behind the wheel while drunk shows a fundamental contempt for human life.
Attempting to trivialize it in the way you have is honestly quite disturbing.
Royalties for a text-book, yes. However writing a text book is not an expected part of a university professors job.
Creating lesson plans, however, is a very different animal. It's an expected and required part of your job. We (the taxpayers) pay teachers to create these plans. For a teacher to claim ownership of these plans doesn't make a lick of sense to me. Just because you 'do it at home' doesn't change it. If I write software for a company at home, I'm still being paid for that work and have no right to claim it as my own. There is no difference here.
Denver is currently piloting a meter that is really nice. It looks like a traditional meter, but it accepts credit cards instead of just coins. Convenient, easy, and apparently not very difficult to retrofit.
How does this generate extra revenue for the city over the traditional system? The real problem these systems solve (and they are very widespread) is making it easier to support credit cards for payment. That's a huge convenience for most folks who don't generally carry change. I get that cynicism is ultra-cool these days, but it's hardly warranted in this case. This is an attempt to alleviate a real problem for folks (like me) who rarely have change. I've used the system in Portland, Denver, and several other cities both here and abroad and I see no issues with it.
That article had no statistics, just a guy who has had articles buried. It was all based on 'talking to his buddies' who have also had articles buried.
It may very well be happening, but that article/blog-entry thing provides no insight into what is going on at all.
Simply not true. Nokia S60 has a veritable ton of apps available. Palm has roughly a billion.
It's not quantity, it's quality of experience. Neither Nokia nor Palm have really made the process of locating and buying apps very easy. The iPhone has.
Google has built a promising system for Android, and as they get more phones to market you'll see more and more applications built for it. I think this battle is going to be fought on balancing 'open' versus 'reliable'. Is apple right? Can developers not be trusted to build high quality applications if the phone is largely open?
The point is you don't have to do even that. The routine would look something like:
- User initiates action with the floppy drive - Run the auto-detection routine to see what answer you get - Spin up the drive and check to see if something is in the drive - Compare that with the pre-spun result to see what answer you get.
Something along those lines. There are several variations on this that would work and never require you to interact with the user at all.
Taxes is EXTREMELY important here. Those shares are going to be taxed as income, even though they have no cash value (they will be taxed at the current valuation of the company at the time of the award). This can be a very significant amount of cash..
You should be looking for options, which allow you to defer much of that tax burden till at least they are liquid (but be careful how the contract is worded in terms of vesting and term of availability.
You sir have master (with incredible (and absolute)) skill the art of parenthetical (the use of parenthesis to denote (or markup (or provide additional detail))) writing.
It's always interesting when I consider the number of hard-core Republicans I know that happily take government welfare. Rural areas are FILLED with people who don't want to work (they're "contractors"), yet live on 5 acres and have 11 horses (real example). They need food stamps to get by. They depend on government medical coverage for their children.
Yet come election time they are red as red can be.
Literally every single Windows user I know has been infected with this. I removed it several times over the holidays. My wife (and many of her coworkers) where infected...
I know it's not necessarily a representative sample, but I'd be shocked if it was only 400k machines in total.
How do you identify "good code"? That's one of the great problems we have as software developers. Quantifying 'good' code is extraordinarily difficult. Code reviews do an excellent job of identifying clever code, but rarely capture the full utility of what is being written. You may think you know good code when you see it, but over the course of my career I've become convinced that is not true at all.
Really the problem is that the only way to truly measure code quality is by seeing how it runs in a production environment. Even then I can easily quantify the quality of the teams overall output (does it work? does it work consistently?), but tracing that back to an individual programmer is often nearly impossible. Systems tend to interact with each other, and placing blame is not an exact science. The gulf between 'good' and 'good enough' is not nearly as wide as it seemed when I was a novice programmer.
Great code almost never breaks. Good code works most of the time. Poor code is another matter.
Poor code is easy to spot. Poor code never works. It's ugly. It's complex. It's stateful. It's jump off of the screen and practically begs to be put out of its misery.
That's precisely why companies have processes and checks. They are an attempt to catch marginal code and make it 'good enough'. The problem, as the article points out, is that in the process they often inspire great coders to deliver marginal code themselves.
The secret is to spot (through some mixture of science and art) great programmers and provide them with the freedom to write great code. If circumstance requires you to hire marginal programmers, then by all means put the process in place to make sure that what they do doesn't detract from the work your best and brightest are doing. Separate them as best you can. Limit how their systems interact.
But whatever you do... don't limit your best programmers, as they are far more valuable than hundreds of poor ones.
Unless you open the phone via something like telnet. Theres a simple piece of social engineering here. Come up with a sob story about how you need to make a phone call and you don't have a phone. Find a kind G1 owner to let you borrow theres to make a call. Have a friend distract them.Quickly run the exploit and open up remote access...
You could potentially download a little thing that calls home to help you locate the phone on the network, and get pretty much whatever you want off of it and since it's a keylogger that might include passwords.
This is identical to a fairly widespread attack in which someone 'borrows' your phone and then signs you up for some premium SMS service that charges you for a stupid joke every day or something like that.
Commenting should be reserved only for especially complex algorithms (describe the algorithm itself) and class level descriptions (what the class or module does). Decipherable code has much more to do with good variable naming, good indentation habits, and consistent well thought out use of flow control structures.
I can't count how many times I've been tripped up by a 'helpful' comment that had been left when code was refactored or changed over time. Dangling comments are a real problem. It's one thing to have to actually read the code (a skill good programmers universally have) and another to have a comment tell you one thing and then have to grok that the code is actually doing something quite different.
Along the various stops in my career I have had to man many booths at various trade shows and conferences. Typically at these shows you need to bring lots of different things on to the floor with your booth, like boxes of schwag that your going to give away. Its generally something that you could totally carry yourself, but can you? Nope...Most of these conference halls and convention centers use union labor exclusively. So you end up having to pay some guy $125 to truck in 10-15 pounds of stuff that you could have easily carried in. Even if you TRY to take it in, your accosted by the guy the union pays to make sure no one gets around their labor stranglehold (I'm looking at you Moscone Center).
Its just dumb. The last time I dealt with this (web 2.0) I timed them. It took 5 minutes, cost: $125. That's $2500/hour for those keeping score at home.
Its not uncommon for someone to have a small breadcrumb of evidence that would not likely result in penalties in court. However you send an ominous letter threatening to sue counting on the fact that the defendant knows that he is guilty. They'll pay up now, rather than risk bigger problems and costs in a court trial. In this case your gambling: Do they have worthwhile evidence or not? They're not going to tell you one way or the other.
The most common mistake around precedent is confusing it with law. Just because something is a precedent, it does not mean that it is hard and fast law. Its an interpretation of law, at a specific time and place. As such, it carries no official weight.
Virtually any level of court can set a legal precedent that can (and will) be referenced by an arguing attorney. Certainly some precedents carry more weight than others (supreme court vs. a trial court), but lawyers will often cite trial law precedents in their arguments. The idea being that there is an established line of reasoning in the precedent that should be carried forward to whatever they are arguing. Thus, the only difference is that a supreme court precedent carries with it tremendous legal weight, particularly since that court has the right to overturn or amend decisions of the lower courts. Its hard to argue against a supreme court precedent when they will just turn around and shove it right back in your face after all.
However, at the end of the day, almost any court preceding can be referenced as a precedent for further argument.
More likely a bunch of fund managers are ticked off because Microsoft was offering like $7 per share over the trading price. They where planning on cashing out, and now with management blocking the deal their pretty ticked off.
I realize that this fantasy world in which Microsoft is pulling the strings in some cunning master plan is quite seductive, but in all probability is completely false. These types of lawsuits are incredibly common when a merger or buyout fails. They are also typically quite short-lived, rarely making it to trial or settlement.
The Android team has put out an SDK complete with emulator. They've held campfire events where they've disclosed details about their plans, and this article manages to get it wrong on almost every point.
For intance: the web-browser is based on Webkit (same as the iPhone) not Opera. In this sense Google 'owns' the browser they are developing. You can get that little gem of information from about 30 seconds of reading on the main android page (http://code.google.com/android).
GPS: While we fully expect most phones to have GPS on the phone, it's not a guarantee. Although all phones will support location via tower-triangulation, so every phone should have some level of location support. Something the article should probably mention.
Processor: The Android team has been forthcoming about the fact that they are developing the system to be more or less platform independent. Right now they have everything up and running only on ARM cores (OMAP included). They are providing multimedia support via acceleration interfaces (OpenGL ES), which means that yes it should run very well on an OMAP processor... but there is little preventing another architecture from being put into use. I fully expect to see OMAP gPhone's, but that is unlikely to be the only configuration in the wild.
Overall, the article was light on research. Very little meat here, and most of what they speculated about was just wrong.
Re:Nokia does develop software and lots of it
on
Nokia Buys Trolltech
·
· Score: 1
Not to mention Carbide the IDE for their fancy OS thingie:
Slashdot Mirror
I agree with you that this sort of publication of charges instead of convictions sucks.
However, your characterization of drunk drivers is just wrong. They ARE incredibly dangerous. They ARE reckless, and while they may not intentionally be seeking out people to mow down, they are showing a tremendous disregard for those same people.
Buying Chocolate when you wanted Strawberry is a bad decision. Getting behind the wheel while drunk shows a fundamental contempt for human life.
Attempting to trivialize it in the way you have is honestly quite disturbing.
Royalties for a text-book, yes. However writing a text book is not an expected part of a university professors job.
Creating lesson plans, however, is a very different animal. It's an expected and required part of your job. We (the taxpayers) pay teachers to create these plans. For a teacher to claim ownership of these plans doesn't make a lick of sense to me. Just because you 'do it at home' doesn't change it. If I write software for a company at home, I'm still being paid for that work and have no right to claim it as my own. There is no difference here.
I will absolutely not pay unless I can freely stream my Hulu content to my TV.
Denver is currently piloting a meter that is really nice. It looks like a traditional meter, but it accepts credit cards instead of just coins. Convenient, easy, and apparently not very difficult to retrofit.
How does this generate extra revenue for the city over the traditional system? The real problem these systems solve (and they are very widespread) is making it easier to support credit cards for payment. That's a huge convenience for most folks who don't generally carry change. I get that cynicism is ultra-cool these days, but it's hardly warranted in this case. This is an attempt to alleviate a real problem for folks (like me) who rarely have change. I've used the system in Portland, Denver, and several other cities both here and abroad and I see no issues with it.
That article had no statistics, just a guy who has had articles buried. It was all based on 'talking to his buddies' who have also had articles buried.
It may very well be happening, but that article/blog-entry thing provides no insight into what is going on at all.
Simply not true. Nokia S60 has a veritable ton of apps available. Palm has roughly a billion.
It's not quantity, it's quality of experience. Neither Nokia nor Palm have really made the process of locating and buying apps very easy. The iPhone has.
Google has built a promising system for Android, and as they get more phones to market you'll see more and more applications built for it. I think this battle is going to be fought on balancing 'open' versus 'reliable'. Is apple right? Can developers not be trusted to build high quality applications if the phone is largely open?
Time will tell.
The point is you don't have to do even that. The routine would look something like:
- User initiates action with the floppy drive
- Run the auto-detection routine to see what answer you get
- Spin up the drive and check to see if something is in the drive
- Compare that with the pre-spun result to see what answer you get.
Something along those lines. There are several variations on this that would work and never require you to interact with the user at all.
Taxes is EXTREMELY important here. Those shares are going to be taxed as income, even though they have no cash value (they will be taxed at the current valuation of the company at the time of the award). This can be a very significant amount of cash..
You should be looking for options, which allow you to defer much of that tax burden till at least they are liquid (but be careful how the contract is worded in terms of vesting and term of availability.
You sir have master (with incredible (and absolute)) skill the art of parenthetical (the use of parenthesis to denote (or markup (or provide additional detail))) writing.
My hat is off to you :)
It's always interesting when I consider the number of hard-core Republicans I know that happily take government welfare. Rural areas are FILLED with people who don't want to work (they're "contractors"), yet live on 5 acres and have 11 horses (real example). They need food stamps to get by. They depend on government medical coverage for their children.
Yet come election time they are red as red can be.
Just because sexuality has been overly criminalized by a prudish society is not the fault of those engaging in sexual acts.
Literally every single Windows user I know has been infected with this. I removed it several times over the holidays. My wife (and many of her coworkers) where infected...
I know it's not necessarily a representative sample, but I'd be shocked if it was only 400k machines in total.
How do you identify "good code"? That's one of the great problems we have as software developers. Quantifying 'good' code is extraordinarily difficult. Code reviews do an excellent job of identifying clever code, but rarely capture the full utility of what is being written. You may think you know good code when you see it, but over the course of my career I've become convinced that is not true at all.
Really the problem is that the only way to truly measure code quality is by seeing how it runs in a production environment. Even then I can easily quantify the quality of the teams overall output (does it work? does it work consistently?), but tracing that back to an individual programmer is often nearly impossible. Systems tend to interact with each other, and placing blame is not an exact science. The gulf between 'good' and 'good enough' is not nearly as wide as it seemed when I was a novice programmer.
Great code almost never breaks. Good code works most of the time. Poor code is another matter.
Poor code is easy to spot. Poor code never works. It's ugly. It's complex. It's stateful. It's jump off of the screen and practically begs to be put out of its misery.
That's precisely why companies have processes and checks. They are an attempt to catch marginal code and make it 'good enough'. The problem, as the article points out, is that in the process they often inspire great coders to deliver marginal code themselves.
The secret is to spot (through some mixture of science and art) great programmers and provide them with the freedom to write great code. If circumstance requires you to hire marginal programmers, then by all means put the process in place to make sure that what they do doesn't detract from the work your best and brightest are doing. Separate them as best you can. Limit how their systems interact.
But whatever you do... don't limit your best programmers, as they are far more valuable than hundreds of poor ones.
Unless you open the phone via something like telnet. Theres a simple piece of social engineering here. Come up with a sob story about how you need to make a phone call and you don't have a phone. Find a kind G1 owner to let you borrow theres to make a call. Have a friend distract them.Quickly run the exploit and open up remote access...
You could potentially download a little thing that calls home to help you locate the phone on the network, and get pretty much whatever you want off of it and since it's a keylogger that might include passwords.
This is identical to a fairly widespread attack in which someone 'borrows' your phone and then signs you up for some premium SMS service that charges you for a stupid joke every day or something like that.
http://en.wikipedia.org/wiki/NAMBLA
I'm not sure why others have been modded down, but that pretty much refutes the argument.
Disagree...
Commenting should be reserved only for especially complex algorithms (describe the algorithm itself) and class level descriptions (what the class or module does). Decipherable code has much more to do with good variable naming, good indentation habits, and consistent well thought out use of flow control structures.
I can't count how many times I've been tripped up by a 'helpful' comment that had been left when code was refactored or changed over time. Dangling comments are a real problem. It's one thing to have to actually read the code (a skill good programmers universally have) and another to have a comment tell you one thing and then have to grok that the code is actually doing something quite different.
My token union story:
Along the various stops in my career I have had to man many booths at various trade shows and conferences. Typically at these shows you need to bring lots of different things on to the floor with your booth, like boxes of schwag that your going to give away. Its generally something that you could totally carry yourself, but can you? Nope...Most of these conference halls and convention centers use union labor exclusively. So you end up having to pay some guy $125 to truck in 10-15 pounds of stuff that you could have easily carried in. Even if you TRY to take it in, your accosted by the guy the union pays to make sure no one gets around their labor stranglehold (I'm looking at you Moscone Center).
Its just dumb. The last time I dealt with this (web 2.0) I timed them. It took 5 minutes, cost: $125. That's $2500/hour for those keeping score at home.
Yay unions.
Its not uncommon for someone to have a small breadcrumb of evidence that would not likely result in penalties in court. However you send an ominous letter threatening to sue counting on the fact that the defendant knows that he is guilty. They'll pay up now, rather than risk bigger problems and costs in a court trial. In this case your gambling: Do they have worthwhile evidence or not? They're not going to tell you one way or the other.
That's just.. wrong.
The most common mistake around precedent is confusing it with law. Just because something is a precedent, it does not mean that it is hard and fast law. Its an interpretation of law, at a specific time and place. As such, it carries no official weight.
Virtually any level of court can set a legal precedent that can (and will) be referenced by an arguing attorney. Certainly some precedents carry more weight than others (supreme court vs. a trial court), but lawyers will often cite trial law precedents in their arguments. The idea being that there is an established line of reasoning in the precedent that should be carried forward to whatever they are arguing. Thus, the only difference is that a supreme court precedent carries with it tremendous legal weight, particularly since that court has the right to overturn or amend decisions of the lower courts. Its hard to argue against a supreme court precedent when they will just turn around and shove it right back in your face after all.
However, at the end of the day, almost any court preceding can be referenced as a precedent for further argument.
More likely a bunch of fund managers are ticked off because Microsoft was offering like $7 per share over the trading price. They where planning on cashing out, and now with management blocking the deal their pretty ticked off.
I realize that this fantasy world in which Microsoft is pulling the strings in some cunning master plan is quite seductive, but in all probability is completely false. These types of lawsuits are incredibly common when a merger or buyout fails. They are also typically quite short-lived, rarely making it to trial or settlement.
It's a contract, so yes it would be fair grounds for dismissal.
You'd also have to be an idiot to agree to it in the first place.
Nuh-uh.
Google develops everything in house from start to finish. Especially Google Docs, maps, Android, and Google Analytics.
The Android team has put out an SDK complete with emulator. They've held campfire events where they've disclosed details about their plans, and this article manages to get it wrong on almost every point.
For intance: the web-browser is based on Webkit (same as the iPhone) not Opera. In this sense Google 'owns' the browser they are developing. You can get that little gem of information from about 30 seconds of reading on the main android page (http://code.google.com/android).
GPS: While we fully expect most phones to have GPS on the phone, it's not a guarantee. Although all phones will support location via tower-triangulation, so every phone should have some level of location support. Something the article should probably mention.
Processor: The Android team has been forthcoming about the fact that they are developing the system to be more or less platform independent. Right now they have everything up and running only on ARM cores (OMAP included). They are providing multimedia support via acceleration interfaces (OpenGL ES), which means that yes it should run very well on an OMAP processor... but there is little preventing another architecture from being put into use. I fully expect to see OMAP gPhone's, but that is unlikely to be the only configuration in the wild.
Overall, the article was light on research. Very little meat here, and most of what they speculated about was just wrong.
Not to mention Carbide the IDE for their fancy OS thingie:
http://www.forum.nokia.com/main/resources/tools_and_sdks/carbide/index.html