The intent of the new law is to make it more difficult for someone who intends to commit mass murder to be successful. The "two-feature" test never accomplished this. I'm not saying that the "one-feature" test is better, but let's stop pretending that the old law was effective.
The two-feature test accomplished nothing for precisely the same reasons the one-feature test will accomplish nothing.
Regardless, I expect this ban to be challenged and struck down in court. US v Miller established the core parameters of constitutional limitations on firearms, and that is that arms in common military use may not be restricted. In fact, I won't be surprised if the lawsuits pursued to fight down this ban (and a possible federal ban) don't end up establishing precedents which cause large portions of the NFA to be struck down as well.
I would argue that a shotgun loaded with bird shot is a much better option for home defense, but I digress
Shotgun, yes, bird shot, no. Bird shot tends to produce nasty-looking but very shallow wounds which will generally not stop a determined assailant. For an effective man-stopper, you need deeper penetration. Yes, that means that your deeper-penetrating projectiles will also penetrate walls better, but anything that will penetrate a human body sufficiently to have a prayer of stopping an attack will also go through some walls.
There are numerous web sites and YouTube videos that demonstrate the inadequacy of bird shot for home defense. Bird shot is for birds, if you need to shoot people use buck shot.
As for an AR for home defense, it's certainly perfectly functional, and actually doesn't create as much overpenetration risk as is often assumed, due to the tendency of the bullets to tumble and fragment. But a shotgun loaded with buckshot is a more effective man-stopper at close range and will overpenetrate less.
Good comments--that are not prescriptive for whatever autodoc tool you use--are invaluable, but bad or marginal ones do more harm than good, especially in interpreted languages.
I'm even skeptical of good comments because of their tendency to become misleading over time. The ultimate authority on the function of the code is the code itself, so if there's any way the code can be made readable enough to eliminate the need for the comment, that's the better choice, and that's true even if reading the code is slightly harder than reading the comment. Now, if the comment is an order of magnitude faster to grok than the code can be, even in it's clearest and cleanest form and assuming an experienced programmer who is good at reading code, then I think there's an argument for the comment.
And, of course, if there's information which simply cannot be expressed in the code, comments are essential.
Do you deal with devices? Where register A must be set before register B? How do you write code that documents this in such a way that a later programmer doesn't come along and say "that's inefficient, let me move the order around"?
It's been a long time since I did much bare metal programming. Commenting code like you describe would be an example of what I called "bits of code that do something which apparently could be done differently but for some other reason must not".
The best use of comments I've seen is as a "user's guide" to functions and procedures that are meant to be used by others, essentially defining the API and relevant notes.
Yeah, that's an excellent use of comments. Even better if you format them so you can automatically extract them and create a nicely-formatted user guide (e.g. Javadoc, Doxygen, etc.).
Both of your examples are special cases of the "this code implements a sophisticated algorithm which needs to be explained" situation, in which I agree comments are appropriate. Actually, though, in both cases the details you mention should really be in the doxygen/Javadoc/whatever documentation-generating comments.
The amount of time required to write, read and understand the comment is far less than the amount of time needed to read the code, parse each section and understand it, especially after not looking at it for 3 months. Even though the function might seem obvious to a veteran C++ programmer, the comment defiantly nice for those less adept.
While this may be true, it ignores another non-trivial cost to comments: They must be maintained -- and very often are not.
Almost inevitably, if the code lives long enough the comment will become wrong, and when that happens the comment has negative value, in fact it often has great negative value, as it may mislead engineers into making incorrect assumptions and cause bugs which would have been avoided had they read the code.
On balance "because it's easier for non-adept programmers to read" is the worst reason for writing comments. It's far better to assume that the readers of the code know how to read the code, or will learn how by doing it. Giving them comments as a crutch not only increases the likelihood that they misunderstand what the code really does (as opposed to what the comment says it does), but also obscures their need to learn how to read code quickly and accurately, which is an absolutely crucial skill. I use the word "obscures" rather than "obviates", or similar, because it's the right word. Being able to read the comment doesn't make it unnecessary for them to learn to read the code, it just hides the fact that they need to learn to read the code.
I should mention that documentation comments (as well as other forms of documentation) suffer even more from creeping inaccuracy than more localized comments. But assuming the documentation is necessary there's no way to avoid that short of moving to a full literate programming style.
Where there is no other way to convey all relevant information, comments are indeed appropriate. I find that there are far fewer such cases than I once did, though, with appropriate effort to make the code itself express the information. And often that extra information shouldn't be only in the code, it should also be in the generated documentation, which further reduces the number of needed non-document comments.
I really liked this bit, because it's something I've been really focusing on for the last year or so, and I think it has significantly improved my code:
Comments should be avoided whenever possible. Comments duplicate work when both writing and reading code. If you need to comment something to make it understandable it should probably be rewritten.
Comments can be useful, IMO, but primarily only for generating documentation (think Javadoc or doxygen, etc.). Other exceptions include bits of code that perform highly-optimized mathematical calculations, in which case I think the best solution is to write a proper document and then add a comment linking to the document, and bits of code that do something which apparently could be done differently but for some other reason must not -- assuming that explanation doesn't belong in the doc-generating comments.
Other than that, I find it makes my code a lot better if every time I find myself wanting to write a comment to explain some bit of code's purpose or operation, I instead refactor until the comment is no longer necessary. Often it's as simple as taking a chunk of code from one method/function and pulling it out into another with a well-chosen name, or else introducing a variable to hold an intermediate value in a calculation, with a well-chosen name. Sometimes the fact that a bit of code is hard to explain is a strong indicator that the design is wrong, that stuff is mashed together that shouldn't be.
The bottom line is that I've found eliminating comments does more for improving the readability of my code than anything else, and I've gotten similar feedback from colleagues whose code I critique by pointing out that they can eliminate their comments if they refactor a bit.
On one condition... promise me you'll do some performance tuning on your site!:-)
I'm guessing it's an AppEngine app that directly uses the (slow) Google data stores. If so, you need to put a caching layer in front of the data store and let updates of the backing store happen asynchronously. If it's not an AppEngine app, there's some other performance-related problem, because any action that does an update is painfully slow.
Since you're worried about losing fitness, gaining weight, etc., -- which is great, most people don't start to think about it until after it becomes a problem -- and since you're an engineer, I suggest the first thing you should do is to begin measuring and tracking relevant stats. Anything worth doing is worth quantifying and plotting on graphs, of course:-)
Read (or skim) The Hacker's Diet. Whether or not you agree with its particular approach to weight management, it does a good job of instilling the idea that your body is just another piece of equipment that you can engineer. You can't redesign it, but you can set up negative feedback control loops that keep it in the configuration that you want it to be, and the first step is to measure and track so you have hard numbers that represent your state and trend.
This doesn't have to be difficult. In fact there are a lot of free on-line resources to make it very easy. Google will find you plenty more, but I'll give you the ones I use.
For overall weight and activity tracking I use http://fitbit.com/ It works best if you buy the $100 Fitbit pedometer/activity tracker and the $130 Aria Wifi-enabled scale (see how the website can be free, without ads?) but you can do it just by entering your numbers daily. Just weigh yourself every morning and take 15 seconds to record it (or if you have the Aria, just weigh yourself and the numbers show up on the web site). You can also track your exercise activities, your measurements (e.g. chest, belly, biceps, etc.) and whatever else you want, and the web site will give you nice graphs. If you get the Fitbit, or another pedometer whose measurements you'll have to enter manually, you'll have that measure of your activity level as well.
If you run, or cycle, etc., http://endomondo.com/ is a great tool for tracking those. Endomondo provides iOS and Android apps for your phone, and you can connect your Endomondo and Fitbit accounts, so when you go out for a run or a ride and track it with your phone, the activity automatically shows up on your Fitbit log. If you like you can also get a bluetooth heart rate monitor which the Endomondo app will use to log your heart rate.
Another key metric is food intake, but that's a lot more work. Fitbit provides food logging, but it sucks because it has a lousy food database. However http://myfitnesspal/ provides an excellent database which makes it easy to find whatever you eat, and the phone app includes a barcode scanner which makes it even easier for packaged foods. Oh and myfitnesspal integrates with Fitbit, too. Honestly, though, unless you're working towards a specific weight gain/loss goal, and you are pretty dedicated about it, logging your food is too much work.
Anyway, armed with measurements, plotted on charts, with trendlines you can see where you're at and where you're going, which enables you to see if there's something you need to be concerned about and to take charge if there is. If you want to make a change, just decide what you think would help and start doing it, then monitor your trends over a few weeks to see if it does. If not, or if not enough, tweak a bit more. Continue adjusting whatever knobs seem appropriate and observing the results until you are where you want to be -- or if maintaining is your goal, just keep doing what you're doing unless the trend lines show movement that you don't want.
The key to making the "measured lifestyle" work is making the measurements easy, automatic and habitual.
Oh, one other tool I've found helpful for goal achievement is http://beeminder.com./ It integrates with fitbit.com (and some other sites) and also provides SMS and/or e-mail reminders, as well as pretty graphs. Most importantly, though, Beeminder provides incentive. You can make a "pledge" to achieve a parti
I would submit that it's a fine circus, nice entertainment to distract from real issues while giving the administration an opportunity to look hip.
How about we get a real, straightforward and non-weaseling answer on the petition to abolish the TSA? That would be a fine precedent.
Establishing an online forum that produces irrelevant and evasive answers from the administration is the appearance of an improvement, but without any substance.
It's my training and I should be able to say what it costs, whether it's a physical good or not.
Substantiate this assertion.
Whatever value you added to the training was miniscule compared to the boost that you yourself got from society, in which you learned the material you covered in your training, learned how to present the material, and made use of literally millions of technological innovations in order to create a video recording and distribute it to others.
You have a fundamental -- common, but fundamental -- misunderstanding of the purpose, meaning and origin of copyright. There is no natural right of ownership of ideas or expressions. None. And there never has been. Ideas are for all of us. You can, of course, keep an idea to yourself. That indeed is your right, because the right of free speech includes the right not to speak. Therefore, you can decide who you share it with and under what circumstances. But once you share it, it becomes equally the property of whoever you shared it with, and if it's sufficiently valuable will eventually become common knowledge of society as a whole.
And that's a good thing. In fact, it's the thing which makes civilization possible, and it's the thing which -- in countless ways -- made it possible for you to produce your SAT training video.
That is the natural state of affairs with respect to intellectual property. It's not like physical property, which is naturally scarce and must be defended. Knowledge is naturally abundant.
Copyright and other IP laws have as their fundamental goal not to restrict but to expand the sharing of ideas and expression. To increase the flow of knowledge into the public domain, in service to society as a whole. The mechanism we use to increase the flow is to temporarily restrict it; granting to creators a limited and temporary monopoly in order to motivate them to create and publish.
In an ideal world, every creative work would be given just enough protection in order to ensure its publication and eventual release to the public domain, and no more. In many, many cases, this would mean no protection at all (c.f. much of the content on the Web). In some cases, for example a movie that costs $200M to make, there has to be a pretty high assurance of protection so the moviemaker can recover costs and profit.
In reality we can't set protections on a per-work basis, so we have to set general rules. Those rules should be set to maximize the flow of useful material into the public domain (which is not what they currently do, BTW).
The key point is that your intellectual work does not belong to you, not once you decide to share it. We have a legal structure in place that encourages you to share it by giving you a modicum of (unnatural) control over it, but that doesn't mean it's yours.
You're probably saying at this point that I'm splitting hairs, saying that it isn't yours but that you have the legal right (for some years) to control copying and distribution, which appear to amount to the same thing. In practice, somewhat. But your choice of words indicates a belief in some fundamental ownership of your intellectual work which does not exist. Society has chosen to give you temporary and unnatural control.
Now, feel free to make your arguments about how it's to the benefit of society that you be able to control the reproduction and distribution of your training video. But don't try to claim that it's yours, because it's not, not once you share it.
That's what google product search was, until a few months ago, but it got very little use and so they changed it to a store where companies pay to have their products listed.
That's not exactly the same thing, in my mind. In fact, I'd say that what it changed to is closer to an ad search than what it was before.
He's proposing a service that searches only for ads. Regular search would still include ads as it does now, but this other notional service would not include any web search results, just ads. I could see myself using that from time to time when I'm looking to buy something.
The goal always has been, and will be, showing ads and getting companies to pay them to show ads.
Everything else follows from that. The search is not the product, the eyeball using the search is.
This is actually precisely backwards from how Google employees and the company leadership -- all the way up to the CEO -- see it.
Google started as an idea for searching the web, implemented on donated and scrounged hardware in a dorm room and using the university's Internet connection. Eventually traffic rose to a point where it was causing problems for Stanford, so it had to move out, which meant it had to find a way to fund itself. The founders were opposed to using advertising as the revenue source, but couldn't find anything else workable. Even then they didn't find advertising acceptable until they realized that advertising can be useful to the user, if it's relevant and not obnoxious.
That attitude is still what drives Google. The goal is all of the products that users use. When new ideas come up, the first question is whether or not it's cool and will improve peoples' lives. Whether or not there's a way to monetize it comes up much later. Of course, if there isn't a way for it to be profitable Google probably won't do it, because the bills have to be paid, but generally any product that's sufficiently useful to a sufficiently large number of people will have some way of paying for itself and generating a profit. Advertising is a monetization approach that works for many products, doesn't create a large barrier to usage, and often creates revenues that grow naturally alongside usage (and therefore cost), so it's widely used.
The point, though, is that products are the goal, and advertising is (usually) the means.
(Disclaimer: I work for Google, but not as a spokesperson. The above reflects my view of the company's motivations from my perspective inside the company, but is not any sort of an official position.)
It wasn't actually mine, though I was on the team and it was common practice in IBM for teams to jointly submit for one member's work, on the theory that everyone had some contribution in the discussions that led up to the patentable work (which is reasonable, and I probably did contribute some).
The face detection technique was part of a project for doing security badging with smart cards, and we needed to reduce the amount of fiddling needed to get a perfectly-centered and scaled head shot. All of the commercial badging systems of the time required the user either to carefully aim the camera or else to select the region of the image to be used after the shot. We needed an approach that could be used at high volume, with no more than 5 seconds per subject, including walk-on, subject positioning and photo capture. By automating the face finding we could point the camera at a fairly large blue background and tell the subjects "Just stand over there and look at the camera".
So the technique relied on the subject being photographed against a blue background and consisted of a simple technique for identifying blue pixels (basically, that B > R+G) plus an efficient search algorithm for identifying the silhouette of the subject and locating the top of the head and the shoulders. With that information it was then easy to find the right portion of the image for a perfect ID badge shot.
We also extended it to work without the blue background, with a calibration shot taken before the subject steps into the frame. It required a tripod-mounted camera and a calibration shot before the subject stepped into the frame.
So, nothing extremely sophisticated. Certainly much simpler than what cheap P&S cameras do today (based, I believe on looking for face geometry, especially eyes and nose). Maybe it really wasn't patent-worthy, but it seemed to be a pretty significant advance compared to the systems in the field.
Is Google's spike in patents due to it taking over Motorola Mobile?
And/or is it due to the recent patent wars that have ignited a lust for patents at Google?
There is a push for Google engineers to propose patents, and corporate infrastructure in place to support it. However, it's not really a part of the culture like it is at IBM. In my opinion, the patent focus at IBM costs the company a great deal in terms of innovation, because the most inventive engineers spend so much of their time on participating in the patent process rather than working on more inventions. IBM obviously reaps later rewards, but I think the patent culture is a net drag on IBM's business. IBM is enormously proud of it however, and I could certainly be wrong.
I can't think of examples off the top of my head, but it seems like "employees are used to identifying what might count as patentable and submitting it" really amounts to "employees know to just go ahead and patent almost anything, and IBM can decide later if they want to enforce it"
Sort of.
IBM has an internal process for vetting possible patents. Employees are encouraged to submit anything and everything that seems like a reasonably novel and interesting idea to this internal process, and a committee composed of attorneys and patent-savvy engineers reviews it and decides if it makes sense to go ahead.
I never really got involved in the patent game during my 14 years at IBM, but the one patent I did submit (for a method of automatically finding faces in images) the committee deemed to be insufficiently novel. I thought it was pretty novel. It was dead simple to implement, blindingly fast and highly accurate, and this was about 15 years ago, before there were face-finding tools and libraries all over the place. But the committee shut us down.
I think that internal committee is the reason why IBM's patents tend to be fairly high quality. Some ringers slip through, of course, but I think they're the exception, not the rule.
If you print money, wages never keep up with the resulting inflation. If you are rich you have assets which will appreciate in value. The rich will never be hurt by these policies. Printing money is a secret tax on the poor and middle class.
That's not true, not all of it. The rich are hurt by inflation, because most of those assets are in securities. Equities tend to lose net value in high inflation because it damages the economy as a whole which damages businesses. Bonds directly lose value because they provide fixed rates of return (which often go very negative when calibrated against high inflation). In fact, devaluing bonds is the whole reason a government might want to induce high inflation to get rid of its debt, which is actually owed to bondholders. Real estate and other physical assets appreciate, and debts on those assets drop in value, but on a percentage basis that dynamic tends to favor the middle class who have most of their net worth tied up in their home -- assuming they can keep their jobs and don't have adjustable-rate mortgages. Today's middle class also tends to have a fair amount in securities, in their 401Ks, so we're also pretty exposed.
You're right that the poor get hammered the hardest and the rich are impacted the least (relatively -- in absolute terms they tend to lose the most but that's because they have more to lose), but it's not accurate to say the rich are not hurt. Printing money is a not-so-secret tax on everyone, though I'll grant that it's a fairly regressive tax.
Redirect the spending into the space program and reap the rewards
Better yet, stop sucking it out of the private sector and see what can be done when all of that labor and capital is freed up to go do useful things. (Not saying the space program isn't useful, just that government boondoggles are net drags on the economy. Sometimes they make sense because there are some things the private sector just wouldn't do.)
The intent of the new law is to make it more difficult for someone who intends to commit mass murder to be successful. The "two-feature" test never accomplished this. I'm not saying that the "one-feature" test is better, but let's stop pretending that the old law was effective.
The two-feature test accomplished nothing for precisely the same reasons the one-feature test will accomplish nothing.
Regardless, I expect this ban to be challenged and struck down in court. US v Miller established the core parameters of constitutional limitations on firearms, and that is that arms in common military use may not be restricted. In fact, I won't be surprised if the lawsuits pursued to fight down this ban (and a possible federal ban) don't end up establishing precedents which cause large portions of the NFA to be struck down as well.
I would argue that a shotgun loaded with bird shot is a much better option for home defense, but I digress
Shotgun, yes, bird shot, no. Bird shot tends to produce nasty-looking but very shallow wounds which will generally not stop a determined assailant. For an effective man-stopper, you need deeper penetration. Yes, that means that your deeper-penetrating projectiles will also penetrate walls better, but anything that will penetrate a human body sufficiently to have a prayer of stopping an attack will also go through some walls.
There are numerous web sites and YouTube videos that demonstrate the inadequacy of bird shot for home defense. Bird shot is for birds, if you need to shoot people use buck shot.
As for an AR for home defense, it's certainly perfectly functional, and actually doesn't create as much overpenetration risk as is often assumed, due to the tendency of the bullets to tumble and fragment. But a shotgun loaded with buckshot is a more effective man-stopper at close range and will overpenetrate less.
Good comments--that are not prescriptive for whatever autodoc tool you use--are invaluable, but bad or marginal ones do more harm than good, especially in interpreted languages.
I'm even skeptical of good comments because of their tendency to become misleading over time. The ultimate authority on the function of the code is the code itself, so if there's any way the code can be made readable enough to eliminate the need for the comment, that's the better choice, and that's true even if reading the code is slightly harder than reading the comment. Now, if the comment is an order of magnitude faster to grok than the code can be, even in it's clearest and cleanest form and assuming an experienced programmer who is good at reading code, then I think there's an argument for the comment.
And, of course, if there's information which simply cannot be expressed in the code, comments are essential.
Do you deal with devices? Where register A must be set before register B? How do you write code that documents this in such a way that a later programmer doesn't come along and say "that's inefficient, let me move the order around"?
It's been a long time since I did much bare metal programming. Commenting code like you describe would be an example of what I called "bits of code that do something which apparently could be done differently but for some other reason must not".
The best use of comments I've seen is as a "user's guide" to functions and procedures that are meant to be used by others, essentially defining the API and relevant notes.
Yeah, that's an excellent use of comments. Even better if you format them so you can automatically extract them and create a nicely-formatted user guide (e.g. Javadoc, Doxygen, etc.).
Both of your examples are special cases of the "this code implements a sophisticated algorithm which needs to be explained" situation, in which I agree comments are appropriate. Actually, though, in both cases the details you mention should really be in the doxygen/Javadoc/whatever documentation-generating comments.
The amount of time required to write, read and understand the comment is far less than the amount of time needed to read the code, parse each section and understand it, especially after not looking at it for 3 months. Even though the function might seem obvious to a veteran C++ programmer, the comment defiantly nice for those less adept.
While this may be true, it ignores another non-trivial cost to comments: They must be maintained -- and very often are not.
Almost inevitably, if the code lives long enough the comment will become wrong, and when that happens the comment has negative value, in fact it often has great negative value, as it may mislead engineers into making incorrect assumptions and cause bugs which would have been avoided had they read the code.
On balance "because it's easier for non-adept programmers to read" is the worst reason for writing comments. It's far better to assume that the readers of the code know how to read the code, or will learn how by doing it. Giving them comments as a crutch not only increases the likelihood that they misunderstand what the code really does (as opposed to what the comment says it does), but also obscures their need to learn how to read code quickly and accurately, which is an absolutely crucial skill. I use the word "obscures" rather than "obviates", or similar, because it's the right word. Being able to read the comment doesn't make it unnecessary for them to learn to read the code, it just hides the fact that they need to learn to read the code.
I should mention that documentation comments (as well as other forms of documentation) suffer even more from creeping inaccuracy than more localized comments. But assuming the documentation is necessary there's no way to avoid that short of moving to a full literate programming style.
That would be a sub-case of "bits of code that do something which apparently could be done differently but for some other reason must not".
Where there is no other way to convey all relevant information, comments are indeed appropriate. I find that there are far fewer such cases than I once did, though, with appropriate effort to make the code itself express the information. And often that extra information shouldn't be only in the code, it should also be in the generated documentation, which further reduces the number of needed non-document comments.
I really liked this bit, because it's something I've been really focusing on for the last year or so, and I think it has significantly improved my code:
Comments should be avoided whenever possible. Comments duplicate work when both writing and reading code. If you need to comment something to make it understandable it should probably be rewritten.
Comments can be useful, IMO, but primarily only for generating documentation (think Javadoc or doxygen, etc.). Other exceptions include bits of code that perform highly-optimized mathematical calculations, in which case I think the best solution is to write a proper document and then add a comment linking to the document, and bits of code that do something which apparently could be done differently but for some other reason must not -- assuming that explanation doesn't belong in the doc-generating comments.
Other than that, I find it makes my code a lot better if every time I find myself wanting to write a comment to explain some bit of code's purpose or operation, I instead refactor until the comment is no longer necessary. Often it's as simple as taking a chunk of code from one method/function and pulling it out into another with a well-chosen name, or else introducing a variable to hold an intermediate value in a calculation, with a well-chosen name. Sometimes the fact that a bit of code is hard to explain is a strong indicator that the design is wrong, that stuff is mashed together that shouldn't be.
The bottom line is that I've found eliminating comments does more for improving the readability of my code than anything else, and I've gotten similar feedback from colleagues whose code I critique by pointing out that they can eliminate their comments if they refactor a bit.
On one condition... promise me you'll do some performance tuning on your site! :-)
I'm guessing it's an AppEngine app that directly uses the (slow) Google data stores. If so, you need to put a caching layer in front of the data store and let updates of the backing store happen asynchronously. If it's not an AppEngine app, there's some other performance-related problem, because any action that does an update is painfully slow.
Other than that, thanks for a great tool!
Grandma bought $app for her Android (v1.23) tablet because she knows that it runs Android. Except it is only supported on v4.56.
Then she didn't buy it from the Google Play store or any other decent Android app store. They check compatibility.
Apparently you didn't read my post.
Since you're worried about losing fitness, gaining weight, etc., -- which is great, most people don't start to think about it until after it becomes a problem -- and since you're an engineer, I suggest the first thing you should do is to begin measuring and tracking relevant stats. Anything worth doing is worth quantifying and plotting on graphs, of course :-)
Read (or skim) The Hacker's Diet. Whether or not you agree with its particular approach to weight management, it does a good job of instilling the idea that your body is just another piece of equipment that you can engineer. You can't redesign it, but you can set up negative feedback control loops that keep it in the configuration that you want it to be, and the first step is to measure and track so you have hard numbers that represent your state and trend.
This doesn't have to be difficult. In fact there are a lot of free on-line resources to make it very easy. Google will find you plenty more, but I'll give you the ones I use.
For overall weight and activity tracking I use http://fitbit.com/ It works best if you buy the $100 Fitbit pedometer/activity tracker and the $130 Aria Wifi-enabled scale (see how the website can be free, without ads?) but you can do it just by entering your numbers daily. Just weigh yourself every morning and take 15 seconds to record it (or if you have the Aria, just weigh yourself and the numbers show up on the web site). You can also track your exercise activities, your measurements (e.g. chest, belly, biceps, etc.) and whatever else you want, and the web site will give you nice graphs. If you get the Fitbit, or another pedometer whose measurements you'll have to enter manually, you'll have that measure of your activity level as well.
If you run, or cycle, etc., http://endomondo.com/ is a great tool for tracking those. Endomondo provides iOS and Android apps for your phone, and you can connect your Endomondo and Fitbit accounts, so when you go out for a run or a ride and track it with your phone, the activity automatically shows up on your Fitbit log. If you like you can also get a bluetooth heart rate monitor which the Endomondo app will use to log your heart rate.
Another key metric is food intake, but that's a lot more work. Fitbit provides food logging, but it sucks because it has a lousy food database. However http://myfitnesspal/ provides an excellent database which makes it easy to find whatever you eat, and the phone app includes a barcode scanner which makes it even easier for packaged foods. Oh and myfitnesspal integrates with Fitbit, too. Honestly, though, unless you're working towards a specific weight gain/loss goal, and you are pretty dedicated about it, logging your food is too much work.
Anyway, armed with measurements, plotted on charts, with trendlines you can see where you're at and where you're going, which enables you to see if there's something you need to be concerned about and to take charge if there is. If you want to make a change, just decide what you think would help and start doing it, then monitor your trends over a few weeks to see if it does. If not, or if not enough, tweak a bit more. Continue adjusting whatever knobs seem appropriate and observing the results until you are where you want to be -- or if maintaining is your goal, just keep doing what you're doing unless the trend lines show movement that you don't want.
The key to making the "measured lifestyle" work is making the measurements easy, automatic and habitual.
Oh, one other tool I've found helpful for goal achievement is http://beeminder.com./ It integrates with fitbit.com (and some other sites) and also provides SMS and/or e-mail reminders, as well as pretty graphs. Most importantly, though, Beeminder provides incentive. You can make a "pledge" to achieve a parti
I would submit it's a fine precedent.
I would submit that it's a fine circus, nice entertainment to distract from real issues while giving the administration an opportunity to look hip.
How about we get a real, straightforward and non-weaseling answer on the petition to abolish the TSA? That would be a fine precedent.
Establishing an online forum that produces irrelevant and evasive answers from the administration is the appearance of an improvement, but without any substance.
It's my training and I should be able to say what it costs, whether it's a physical good or not.
Substantiate this assertion.
Whatever value you added to the training was miniscule compared to the boost that you yourself got from society, in which you learned the material you covered in your training, learned how to present the material, and made use of literally millions of technological innovations in order to create a video recording and distribute it to others.
You have a fundamental -- common, but fundamental -- misunderstanding of the purpose, meaning and origin of copyright. There is no natural right of ownership of ideas or expressions. None. And there never has been. Ideas are for all of us. You can, of course, keep an idea to yourself. That indeed is your right, because the right of free speech includes the right not to speak. Therefore, you can decide who you share it with and under what circumstances. But once you share it, it becomes equally the property of whoever you shared it with, and if it's sufficiently valuable will eventually become common knowledge of society as a whole.
And that's a good thing. In fact, it's the thing which makes civilization possible, and it's the thing which -- in countless ways -- made it possible for you to produce your SAT training video.
That is the natural state of affairs with respect to intellectual property. It's not like physical property, which is naturally scarce and must be defended. Knowledge is naturally abundant.
Copyright and other IP laws have as their fundamental goal not to restrict but to expand the sharing of ideas and expression. To increase the flow of knowledge into the public domain, in service to society as a whole. The mechanism we use to increase the flow is to temporarily restrict it; granting to creators a limited and temporary monopoly in order to motivate them to create and publish.
In an ideal world, every creative work would be given just enough protection in order to ensure its publication and eventual release to the public domain, and no more. In many, many cases, this would mean no protection at all (c.f. much of the content on the Web). In some cases, for example a movie that costs $200M to make, there has to be a pretty high assurance of protection so the moviemaker can recover costs and profit.
In reality we can't set protections on a per-work basis, so we have to set general rules. Those rules should be set to maximize the flow of useful material into the public domain (which is not what they currently do, BTW).
The key point is that your intellectual work does not belong to you, not once you decide to share it. We have a legal structure in place that encourages you to share it by giving you a modicum of (unnatural) control over it, but that doesn't mean it's yours.
You're probably saying at this point that I'm splitting hairs, saying that it isn't yours but that you have the legal right (for some years) to control copying and distribution, which appear to amount to the same thing. In practice, somewhat. But your choice of words indicates a belief in some fundamental ownership of your intellectual work which does not exist. Society has chosen to give you temporary and unnatural control.
Now, feel free to make your arguments about how it's to the benefit of society that you be able to control the reproduction and distribution of your training video. But don't try to claim that it's yours, because it's not, not once you share it.
Cite? I'm not saying you're wrong, but my understanding is that Doubleclick has been forced to tone down the obnoxiousness of its ads.
That's what google product search was, until a few months ago, but it got very little use and so they changed it to a store where companies pay to have their products listed.
That's not exactly the same thing, in my mind. In fact, I'd say that what it changed to is closer to an ad search than what it was before.
He's proposing a service that searches only for ads. Regular search would still include ads as it does now, but this other notional service would not include any web search results, just ads. I could see myself using that from time to time when I'm looking to buy something.
Web search was what they did for a while.
The goal always has been, and will be, showing ads and getting companies to pay them to show ads.
Everything else follows from that. The search is not the product, the eyeball using the search is.
This is actually precisely backwards from how Google employees and the company leadership -- all the way up to the CEO -- see it.
Google started as an idea for searching the web, implemented on donated and scrounged hardware in a dorm room and using the university's Internet connection. Eventually traffic rose to a point where it was causing problems for Stanford, so it had to move out, which meant it had to find a way to fund itself. The founders were opposed to using advertising as the revenue source, but couldn't find anything else workable. Even then they didn't find advertising acceptable until they realized that advertising can be useful to the user, if it's relevant and not obnoxious.
That attitude is still what drives Google. The goal is all of the products that users use. When new ideas come up, the first question is whether or not it's cool and will improve peoples' lives. Whether or not there's a way to monetize it comes up much later. Of course, if there isn't a way for it to be profitable Google probably won't do it, because the bills have to be paid, but generally any product that's sufficiently useful to a sufficiently large number of people will have some way of paying for itself and generating a profit. Advertising is a monetization approach that works for many products, doesn't create a large barrier to usage, and often creates revenues that grow naturally alongside usage (and therefore cost), so it's widely used.
The point, though, is that products are the goal, and advertising is (usually) the means.
(Disclaimer: I work for Google, but not as a spokesperson. The above reflects my view of the company's motivations from my perspective inside the company, but is not any sort of an official position.)
It wasn't actually mine, though I was on the team and it was common practice in IBM for teams to jointly submit for one member's work, on the theory that everyone had some contribution in the discussions that led up to the patentable work (which is reasonable, and I probably did contribute some).
The face detection technique was part of a project for doing security badging with smart cards, and we needed to reduce the amount of fiddling needed to get a perfectly-centered and scaled head shot. All of the commercial badging systems of the time required the user either to carefully aim the camera or else to select the region of the image to be used after the shot. We needed an approach that could be used at high volume, with no more than 5 seconds per subject, including walk-on, subject positioning and photo capture. By automating the face finding we could point the camera at a fairly large blue background and tell the subjects "Just stand over there and look at the camera".
So the technique relied on the subject being photographed against a blue background and consisted of a simple technique for identifying blue pixels (basically, that B > R+G) plus an efficient search algorithm for identifying the silhouette of the subject and locating the top of the head and the shoulders. With that information it was then easy to find the right portion of the image for a perfect ID badge shot.
We also extended it to work without the blue background, with a calibration shot taken before the subject steps into the frame. It required a tripod-mounted camera and a calibration shot before the subject stepped into the frame.
So, nothing extremely sophisticated. Certainly much simpler than what cheap P&S cameras do today (based, I believe on looking for face geometry, especially eyes and nose). Maybe it really wasn't patent-worthy, but it seemed to be a pretty significant advance compared to the systems in the field.
Is Google's spike in patents due to it taking over Motorola Mobile? And/or is it due to the recent patent wars that have ignited a lust for patents at Google?
There is a push for Google engineers to propose patents, and corporate infrastructure in place to support it. However, it's not really a part of the culture like it is at IBM. In my opinion, the patent focus at IBM costs the company a great deal in terms of innovation, because the most inventive engineers spend so much of their time on participating in the patent process rather than working on more inventions. IBM obviously reaps later rewards, but I think the patent culture is a net drag on IBM's business. IBM is enormously proud of it however, and I could certainly be wrong.
(I used to work for IBM and now work for Google.)
I can't think of examples off the top of my head, but it seems like "employees are used to identifying what might count as patentable and submitting it" really amounts to "employees know to just go ahead and patent almost anything, and IBM can decide later if they want to enforce it"
Sort of.
IBM has an internal process for vetting possible patents. Employees are encouraged to submit anything and everything that seems like a reasonably novel and interesting idea to this internal process, and a committee composed of attorneys and patent-savvy engineers reviews it and decides if it makes sense to go ahead.
I never really got involved in the patent game during my 14 years at IBM, but the one patent I did submit (for a method of automatically finding faces in images) the committee deemed to be insufficiently novel. I thought it was pretty novel. It was dead simple to implement, blindingly fast and highly accurate, and this was about 15 years ago, before there were face-finding tools and libraries all over the place. But the committee shut us down.
I think that internal committee is the reason why IBM's patents tend to be fairly high quality. Some ringers slip through, of course, but I think they're the exception, not the rule.
If you print money, wages never keep up with the resulting inflation. If you are rich you have assets which will appreciate in value. The rich will never be hurt by these policies. Printing money is a secret tax on the poor and middle class.
That's not true, not all of it. The rich are hurt by inflation, because most of those assets are in securities. Equities tend to lose net value in high inflation because it damages the economy as a whole which damages businesses. Bonds directly lose value because they provide fixed rates of return (which often go very negative when calibrated against high inflation). In fact, devaluing bonds is the whole reason a government might want to induce high inflation to get rid of its debt, which is actually owed to bondholders. Real estate and other physical assets appreciate, and debts on those assets drop in value, but on a percentage basis that dynamic tends to favor the middle class who have most of their net worth tied up in their home -- assuming they can keep their jobs and don't have adjustable-rate mortgages. Today's middle class also tends to have a fair amount in securities, in their 401Ks, so we're also pretty exposed.
You're right that the poor get hammered the hardest and the rich are impacted the least (relatively -- in absolute terms they tend to lose the most but that's because they have more to lose), but it's not accurate to say the rich are not hurt. Printing money is a not-so-secret tax on everyone, though I'll grant that it's a fairly regressive tax.
Redirect the spending into the space program and reap the rewards
Better yet, stop sucking it out of the private sector and see what can be done when all of that labor and capital is freed up to go do useful things. (Not saying the space program isn't useful, just that government boondoggles are net drags on the economy. Sometimes they make sense because there are some things the private sector just wouldn't do.)