Really? You're citing the American Enterprise Institute?
While I admit that I don't really have a problem with a little "income redistribution" in the form of progressive taxes (and yes, I would put this in that category), I'm pretty sure nobody would be happy if Bush, the AEI, and the rest of the gang had gotten their way and put all of our social security into private investment accounts (which would probably be worth about as much as our 401(k)s are now).
Whatever you do, don't listen to anyone on Slashdot.
But seriously, whatever you end up doing, there are a few things that are of value on most any project:
1. Always try to make your code readable and easy to understand for someone that's not inside your head. 2. Naming things well is critical. No amount of documentation or inline comments will make code with bad naming easy to work on, and when your code is well-organized with useful names, documentation and comments become much less important. Hint: if you have a hard time naming something, it's usually (but not always) an indication that it's not as well organized as it could be. 3. Always try to spend a certain amount of time reworking your code to make it easier to understand. 5, 10, 30%---as long as it's something. This will help with #1. 4. Always try to think about how you can test what you wrote. It will help your designs, it will reduce your bugs, it will help you relate to your QA, and it will help with #1. 5. Learn to let go. While you can take pride in your coding skills, don't get attached to your code. 6. Software development is a social skill. Become very good at these: working collaboratively, understanding other people's frustrations, finding ways of working with/around people effectively when you depend on them, articulating your ideas in an e-mail, and explaining to other people what you're doing and why you're doing it. Someone that is a decent programmer and has all those skills is a thousand times more valuable on any software team I've been on than someone that knows everything there is to know about software but doesn't have those skills. 7. Always try to find a way to make things less painful for your team, or at least yourself. Software development always has certain pain points, and there are usually things that you can do to reduce some of it. RCS/SCM, continuous integration, automated deployment, automated functional testing, a wiki for documentation, an IRC/campfire server for collaboration with people not in your office... all of these are things that can (but won't necessarily) reduce pain on your project. While you might have to pick your battles, never resign yourself completely to the status quo of your software development process. 8. Everything else is in the details, really. If you continue to learn (new languages, new frameworks, new app servers, new operating systems, new software development methodologies, new tools, etc.), and you keep to these basic guidelines, nothing else is particularly important, whether you're coding Java, C++, PHP, Ruby, Basic. If you're not learning anything new on your project, then try to work with your managers/clients/etc. to change that. Whether you put Java code in your JSPs, whether you prefer underscores or camel-case, whether you put SQL inside strings or use an ORM, whether you write your unit tests first, or last, or not at all, whether you like to put an 'I' in front of your interface names, or a str as a prefix for your String variables, or never use curly braces for one-line 'if' clauses, or swallow your exceptions---these things don't really matter in the long run. You'll probably change your mind on some of your most strongly held positions, and more importantly you need to be able to work effectively with people that hold very strongly to the opposite position.
There are some admirable politicians out there. The fact that you are unwilling to look at their individual behavior, and simply tar them all with the same brush, marks you as intellectually lazy and fundamentally dishonest.
Can you name some so that we might tar them individually, with different brushes?
I think there are two key concerns here, and they are quite different. One is intellectual property rights, and the other is the optimal state of intellectual property law for us to have a ____ (e.g., fair, equitable, functioning, orderly, free, wealthy, powerful) society.
There are also auxiliary considerations, such as the rights you have in protecting your intellectual property. Do you have the right to install rootkits on your customer's computer as part of the agreement in selling the product to them? Do you have to make sure that they know and agree before they are bound to it? Do you as a customer have a right to reverse engineer a physical or software product that you have purchased? Do you have the right to resell it?
Personally, I don't really believe in intellectual property 'rights', and I believe that intellectual property law needs to be scaled back considerably but not entirely (though I generally discourage drastic changes and would prefer to see it done in stages over a few years). Something like 10 years for copyrights, 15 with extension; 5 years for patents, 10 with extension.
Patents in particular are tricky, howeverâ"there's a need to provide incentive for entities to absorb the massive costs in developing breakthrough technologies without allowing the prices set on those technologies to undermine the ability of those technologies to benefit humanity. I have no solution (in part because I don't know enough about the domain), but it seems pretty clear that the current mechanisms are b0rken, particularly with regard to medicine.
The article is right: anonymity is not privacy and privacy is not anonymity. However, anonymity is a form of privacy and should be protected within reason.
Another way of looking at it:
privacy: people not knowing what you've done. anonymity: people not knowing who did X.
if you lose anonymity, you lose privacy in relation to X, and where X covers everything in the public sphere, you lose all privacy except in relation to those things that are not in the public sphere (Y). That's a lot of privacy to lose.
It sounds like your dad had a good manager _and_ benefitted from the union across the street at the same time. He'll never know what his career would have been like if the shop across the street hadn't had a union.
The premise of this argument is that no content worth having exists in the public domain, so any use of this tool must be directed toward infilching upon proprietary content.
It is probably worth mentioning that for music recordings it is pretty much the case. The Mickey Mouse clause is a little different in the area of sound recordings, since copyrights reach farther back than Mickey Mouse. Every sound recording prior to 1972 has copyright status as though it had been copyrighted in 1972, and thus no sound recording has fallen into the public domain or is going to soon.
The difference is that (1) no one is willing to pay the price of a bridge (or the development of a major physical product) for similarly secure or bug-free software because it's rarely worthwhile in terms of time and money (whether open source or no) and (2) every piece of a bridge is worked over by different people in different roles (architect, different types of engineers, the people that build it, etc.), each of which has a chance to notice critical problems. As the bridge goes through various stages of development many types of critical problems become more obvious, not less; as software goes through various stages of development bugs not affecting the user experience become harder to spot. (Despite this, buildings can from time to time be found to have critical engineering flaws after they are built, requiring them to be reinforced or even rebuilt)
When you really need software to be secure or bug-free you can almost get it there, but you have to pay exponentially more to get an exponentially smaller increase in security or decrease in bugs, and it will also take a very long time no matter how many people you throw at it. Would you be willing to pay a factor of 10 more and double the length of your project in order to go from 95% secure to 99% secure?
I have no problem with this in principle, except for the fact that the blogs aren't often much of a source of original media output. For the most part, they are part of the digestive process, and so much of what we get through blogs comes through them from the original media in the first place, so as the original media degrades, so will the value of what comes through those blogs. This will give more strength to those blogs that do provide original research (e.g., http://dpreview.com/ a halfway point between blog and tech media), but as good reporting and good analysis is expensive, they will have to avoid suffering the same problems as the original tech media they are supplanting as they work their way down the food chain (here I think of blogs as being "higher" on the food chain in that they consume the text media and we consume them. They are essentially sitting between us and the tech media, which is sitting between us and the tech industry).
Slashvertizing in Action
on
Groovy in Action
·
· Score: 3, Funny
Summary:
* Groovy is in Java, and therefore current and former Java programmers will love it (wtf?)
* Groovy is a dynamic language and therefore attractive to people who work in scripting languages (wtf?)
* Grails is implemented using Groovy and therefore Ruby on Rails programmers will be interested.
* Groovy is awesome!
* This book is awesome!
I've seen a lot of advertising masquerading as book reviews on slashdot, and I don't generally mind 'em too much, but this one's over the top. The author seems to think that the book will appeal to every group of people that could possibly be touched by some aspect of Groovy, and gives very odd reasoning for each case. The review imparts almost no information beyond that and a summary of the table of contents. If the book is half as proselytistic as this review, then it's unlikely to be worth the paper it's printed on. Then again, you shouldn't judge a book by its review.
My favorite sentence is: "I like the approach of including guidance for using the language after you've learned it, because it acknowledges that the purpose of learning a programming language is to then use it."
Re:Let's play the substitution game, kids!
on
Safe and Insecure?
·
· Score: 1
He never said ANYTHING about 'licensing the internet'.
Nor did I suggest that he did. However, it is a logical extension of the analogy: if an Internet connection is dangerous like a firearm, then it should be licensed like a firearm.
The idea that it's bad to allow people to use your internet connection because they might cause harm is what I'm calling into question. I think it's bad for a lot of reasons (sacrificing security, opening the possibility that you will be held responsible for someone else's crime, etc.), but the possibility that someone might do something immoral with it is not one of them.
To put it another way, if you think it is bad to open up your internet connections for the specific reason that someone might do something immoral with it, then you ought (for reasons of being consistent) to think that libraries or other institutions should not allow anonymous internet access to the general public. Do you? Or is there a flaw in my reasoning?
Re:Let's play the substitution game, kids!
on
Safe and Insecure?
·
· Score: 1
Are you really suggesting that an Internet Connection is like a gun? Do you further believe that its use should be restricted to licensed people who should not be allowed to share it? People can do bad and crazy things on the Internet, but a connection to it is not a gun, and the analogy is simple-minded and erroneous. I want no part of your vision of the Internet (I don't think it would be very popular).
I think it's awesome that Mr. Lowry admitted to messing up the Citizen Kane dvd (by accidentally "cleaning up" the grain).
In any case, I think that this scanning is great for making home video products, but it's quite immature for real film restoration. Digital restorations still look pretty terrible, and I think that the studios should wait until they can scan the films at a much higher resolution before relying on the digital technology to preserve films like Modern Times. They shouldn't even be touching the camera negative (or the best source, if there is camera negative to work from, or it's no good) unless they're going to significantly improve its longevity (e.g., by cleaning it), or significantly improve the quality of the other elements out there (enough to justify the damage done by running the camera negative).
Slashdot Mirror
Really? You're citing the American Enterprise Institute?
While I admit that I don't really have a problem with a little "income redistribution" in the form of progressive taxes (and yes, I would put this in that category), I'm pretty sure nobody would be happy if Bush, the AEI, and the rest of the gang had gotten their way and put all of our social security into private investment accounts (which would probably be worth about as much as our 401(k)s are now).
Whatever you do, don't listen to anyone on Slashdot.
But seriously, whatever you end up doing, there are a few things that are of value on most any project:
1. Always try to make your code readable and easy to understand for someone that's not inside your head.
2. Naming things well is critical. No amount of documentation or inline comments will make code with bad naming easy to work on, and when your code is well-organized with useful names, documentation and comments become much less important. Hint: if you have a hard time naming something, it's usually (but not always) an indication that it's not as well organized as it could be.
3. Always try to spend a certain amount of time reworking your code to make it easier to understand. 5, 10, 30%---as long as it's something. This will help with #1.
4. Always try to think about how you can test what you wrote. It will help your designs, it will reduce your bugs, it will help you relate to your QA, and it will help with #1.
5. Learn to let go. While you can take pride in your coding skills, don't get attached to your code.
6. Software development is a social skill. Become very good at these: working collaboratively, understanding other people's frustrations, finding ways of working with/around people effectively when you depend on them, articulating your ideas in an e-mail, and explaining to other people what you're doing and why you're doing it. Someone that is a decent programmer and has all those skills is a thousand times more valuable on any software team I've been on than someone that knows everything there is to know about software but doesn't have those skills.
7. Always try to find a way to make things less painful for your team, or at least yourself. Software development always has certain pain points, and there are usually things that you can do to reduce some of it. RCS/SCM, continuous integration, automated deployment, automated functional testing, a wiki for documentation, an IRC/campfire server for collaboration with people not in your office... all of these are things that can (but won't necessarily) reduce pain on your project. While you might have to pick your battles, never resign yourself completely to the status quo of your software development process.
8. Everything else is in the details, really. If you continue to learn (new languages, new frameworks, new app servers, new operating systems, new software development methodologies, new tools, etc.), and you keep to these basic guidelines, nothing else is particularly important, whether you're coding Java, C++, PHP, Ruby, Basic. If you're not learning anything new on your project, then try to work with your managers/clients/etc. to change that. Whether you put Java code in your JSPs, whether you prefer underscores or camel-case, whether you put SQL inside strings or use an ORM, whether you write your unit tests first, or last, or not at all, whether you like to put an 'I' in front of your interface names, or a str as a prefix for your String variables, or never use curly braces for one-line 'if' clauses, or swallow your exceptions---these things don't really matter in the long run. You'll probably change your mind on some of your most strongly held positions, and more importantly you need to be able to work effectively with people that hold very strongly to the opposite position.
There are some admirable politicians out there. The fact that you are unwilling to look at their individual behavior, and simply tar them all with the same brush, marks you as intellectually lazy and fundamentally dishonest.
Can you name some so that we might tar them individually, with different brushes?
I think there are two key concerns here, and they are quite different. One is intellectual property rights, and the other is the optimal state of intellectual property law for us to have a ____ (e.g., fair, equitable, functioning, orderly, free, wealthy, powerful) society.
There are also auxiliary considerations, such as the rights you have in protecting your intellectual property. Do you have the right to install rootkits on your customer's computer as part of the agreement in selling the product to them? Do you have to make sure that they know and agree before they are bound to it? Do you as a customer have a right to reverse engineer a physical or software product that you have purchased? Do you have the right to resell it?
Personally, I don't really believe in intellectual property 'rights', and I believe that intellectual property law needs to be scaled back considerably but not entirely (though I generally discourage drastic changes and would prefer to see it done in stages over a few years). Something like 10 years for copyrights, 15 with extension; 5 years for patents, 10 with extension.
Patents in particular are tricky, howeverâ"there's a need to provide incentive for entities to absorb the massive costs in developing breakthrough technologies without allowing the prices set on those technologies to undermine the ability of those technologies to benefit humanity. I have no solution (in part because I don't know enough about the domain), but it seems pretty clear that the current mechanisms are b0rken, particularly with regard to medicine.
The article is right: anonymity is not privacy and privacy is not anonymity. However, anonymity is a form of privacy and should be protected within reason.
Another way of looking at it:
privacy: people not knowing what you've done.
anonymity: people not knowing who did X.
if you lose anonymity, you lose privacy in relation to X, and where X covers everything in the public sphere, you lose all privacy except in relation to those things that are not in the public sphere (Y). That's a lot of privacy to lose.
What exactly is this advice based on?
It sounds like your dad had a good manager _and_ benefitted from the union across the street at the same time. He'll never know what his career would have been like if the shop across the street hadn't had a union.
I think you should have taken that class.
The premise of this argument is that no content worth having exists in the public domain, so any use of this tool must be directed toward infilching upon proprietary content.
It is probably worth mentioning that for music recordings it is pretty much the case. The Mickey Mouse clause is a little different in the area of sound recordings, since copyrights reach farther back than Mickey Mouse. Every sound recording prior to 1972 has copyright status as though it had been copyrighted in 1972, and thus no sound recording has fallen into the public domain or is going to soon.
http://www.pdinfo.com/record.htm
Then again, there are a lot of good recordings that have been released with CC licenses and such, so the essence of your argument remains true.
The difference is that (1) no one is willing to pay the price of a bridge (or the development of a major physical product) for similarly secure or bug-free software because it's rarely worthwhile in terms of time and money (whether open source or no) and (2) every piece of a bridge is worked over by different people in different roles (architect, different types of engineers, the people that build it, etc.), each of which has a chance to notice critical problems. As the bridge goes through various stages of development many types of critical problems become more obvious, not less; as software goes through various stages of development bugs not affecting the user experience become harder to spot. (Despite this, buildings can from time to time be found to have critical engineering flaws after they are built, requiring them to be reinforced or even rebuilt)
When you really need software to be secure or bug-free you can almost get it there, but you have to pay exponentially more to get an exponentially smaller increase in security or decrease in bugs, and it will also take a very long time no matter how many people you throw at it. Would you be willing to pay a factor of 10 more and double the length of your project in order to go from 95% secure to 99% secure?
I have no problem with this in principle, except for the fact that the blogs aren't often much of a source of original media output. For the most part, they are part of the digestive process, and so much of what we get through blogs comes through them from the original media in the first place, so as the original media degrades, so will the value of what comes through those blogs. This will give more strength to those blogs that do provide original research (e.g., http://dpreview.com/ a halfway point between blog and tech media), but as good reporting and good analysis is expensive, they will have to avoid suffering the same problems as the original tech media they are supplanting as they work their way down the food chain (here I think of blogs as being "higher" on the food chain in that they consume the text media and we consume them. They are essentially sitting between us and the tech media, which is sitting between us and the tech industry).
Summary:
* Groovy is in Java, and therefore current and former Java programmers will love it (wtf?)
* Groovy is a dynamic language and therefore attractive to people who work in scripting languages (wtf?)
* Grails is implemented using Groovy and therefore Ruby on Rails programmers will be interested.
* Groovy is awesome!
* This book is awesome!
I've seen a lot of advertising masquerading as book reviews on slashdot, and I don't generally mind 'em too much, but this one's over the top. The author seems to think that the book will appeal to every group of people that could possibly be touched by some aspect of Groovy, and gives very odd reasoning for each case. The review imparts almost no information beyond that and a summary of the table of contents. If the book is half as proselytistic as this review, then it's unlikely to be worth the paper it's printed on. Then again, you shouldn't judge a book by its review.
My favorite sentence is:
"I like the approach of including guidance for using the language after you've learned it, because it acknowledges that the purpose of learning a programming language is to then use it."
He never said ANYTHING about 'licensing the internet'.
Nor did I suggest that he did. However, it is a logical extension of the analogy: if an Internet connection is dangerous like a firearm, then it should be licensed like a firearm.
The idea that it's bad to allow people to use your internet connection because they might cause harm is what I'm calling into question. I think it's bad for a lot of reasons (sacrificing security, opening the possibility that you will be held responsible for someone else's crime, etc.), but the possibility that someone might do something immoral with it is not one of them.
To put it another way, if you think it is bad to open up your internet connections for the specific reason that someone might do something immoral with it, then you ought (for reasons of being consistent) to think that libraries or other institutions should not allow anonymous internet access to the general public. Do you? Or is there a flaw in my reasoning?
Are you really suggesting that an Internet Connection is like a gun? Do you further believe that its use should be restricted to licensed people who should not be allowed to share it? People can do bad and crazy things on the Internet, but a connection to it is not a gun, and the analogy is simple-minded and erroneous. I want no part of your vision of the Internet (I don't think it would be very popular).
That's not improving your security. That's improving your privacy (via anonymity) at the expense of your security.
I think it's awesome that Mr. Lowry admitted to messing up the Citizen Kane dvd (by accidentally "cleaning up" the grain).
In any case, I think that this scanning is great for making home video products, but it's quite immature for real film restoration. Digital restorations still look pretty terrible, and I think that the studios should wait until they can scan the films at a much higher resolution before relying on the digital technology to preserve films like Modern Times. They shouldn't even be touching the camera negative (or the best source, if there is camera negative to work from, or it's no good) unless they're going to significantly improve its longevity (e.g., by cleaning it), or significantly improve the quality of the other elements out there (enough to justify the damage done by running the camera negative).