Maturity has nothing to do with actual age and everything to do with having a history of being used successfully. The more people have found that a project/product helps them successfully solve a problem, the greater the chance that it can be used to solve your problem provided your problem is similar in nature to the problems of others.
Java's maturity comes from having millions of people run into, enumerate and complain about it's shortcomings. In early versions, Java was slow. Newer versions have JIT compilers which make it very competitive speedwise for most applications. Generics are another example. Programmers complained about how ugly it is to always have to cast objects coming out of collections. Java evolved to include syntactic sugar to avoid all those ugly casts.
It's the little tweaks that make things mature. Java has had quite a while now to find what needs tweaking and fix it. More importantly, the platform has shown itself to be pretty stable and unlikely to change drastically from version to version. It is valid to say that Java is a proven technology that is very likely to remain stable for the forseable future. There may be very good reasons to use Ruby and rails for webapps, but a long history of successful deployment isn't one of them.
Mature isn't nearly as vague as the blog posting contends.
It sounds like you're essentially suggesting that open source create something similar to the.NET CLR. It's an interesting idea, but it would be really difficult to get everyone to work together and agree on design details..NET has the advantage that Microsoft gets to make all the decisions, so when an implementation choice would favor one language over another, they decide based on which language will make them more money. Open source projects won't subjugate themselves when it comes to these kinds of decisions. It could very easily end up in a situation where everyone argues and nothing ever gets done right or done at all.
Something like that stands a much better chance of happening if someone just goes off and does it. It would be neat if this new JVM includes an extension mechanism that allows people to write JIT compilers for other languages. But I just don't see Java users getting behind a runtime that doesn't place Java concerns ahead of all else. So I think it's doubtful that Parrot itself would ever end up being used as the basis for a new JVM.
...however, PHP (far more popular for web development, especially with less experienced programmers) is not. It has a serialize to string function, however, this is not terribly useful if you have several variables (unless you want to deal with delimiting the variables, making sure the proper character(s) are escaped, and then unrolling that later).
Why would you bother with delimiters when PHP is perfectly capable of serializing arrays/hashes. Just dump all your variables into an array and serialize. The code necessary to implement this kind of caching is literally 3-4 lines, with a couple more to check the timestamp on your cache file for expiration purposes. As I said before, there's nothing new here...I've seen a ton of PHP apps/libraries that implement caching in this manner.
I agree that there are a ton of inexperienced PHP coders out there writing bad code who will never fully understand the theory of good v. bad caching solutions. But if you're going to try to teach something to those programmers, you should understand these issues a bit better. It's not hard to do a little research before advising others to use some new method you've cooked up. Otherwise, it's just a case of the blind leading the blinder.
It's not part of the elements of style, but some people use it. I like it because it eliminates the need for the 'this' keyword in setters.
private int _something; public void setSomething(int something) {
_something = something; }
vs.
private int something; public void setSomething(int something) {
this.something = something; }
Also, it keeps you from having to track down an annoying type bug...
private int something; public void setSomething(int soomething) {
this.something = something; }
In the above case, the extra 'o' won't cause a compilation error, but the setter will mysteriously do nothing. If you prefix your instance variable with an underscore, you'll get a compile time error.
No offense, but a lot of this sounds like poor advice.
Firstly, a lot of your caching solution should depend on what tools or language features are available for the language you're using to implement your site. For example, advocating caching things to disk isn't really necessary when you're using Java since it's more effective to use in-memory caches. If you use an ORM solution like Hibernate, caching happens behind the scenes and you don't even have to think about it. However, if you're using a scripting language like Perl or PHP, you can't use in-memory caches and have to turn to some sort of on-disk storage.
Secondly, even if you're going to cache to disk, there's usually better ways to do it than having special files (case 1) or saving the entire generated page to disk (case 2). For example, the en vogue way of doing disk caching in PHP is to serialize your data structure to disk and then unserialize it on every request. From there, the page can be generated normally and you've still avoided the trip to the database while retaining far more flexibility when it comes to making your page dynamic.
Thirdly, caching isn't rocket science. In every language I can think of, third-party tools exist to help you handle that aspect of your app for you to keep you from having to write your own custom implementation. Unless you've profiled your application and know that optimizing a certain part will have substantial benefit, using an off-the-shelf solution will make your application far more manageable and far more friendly to developers not already familiar with the code.
The main thing to remember is that if you're having this issue, chances are it's not new and someone has effectively solved your problem in the past...just go look for their solution. The world needs another roll-your-own caching solution like it needs another proprietary video or PHP/MySQL book...
FWIW, caching is also built into Hibernate and other ORM solutions for Java.
I would imagine the benefits of caching would be outweighed by the drawbacks of maintaining a custom caching solution in most cases unless profiling the application has shown that it is absolutely necessary.
Why would they snoop traffic when they could just pay students to go find the copyrighted files???
It's not like there's a shortage of students with internet2 connections that know where to go for copyrighted music files and would do just about anything for $20/hr.
The kind of system you're talking about needs to be compared with the combination of Spring and Hibernate. Some people might include MiddleGen too, though I've worked on projects without it and we've done alright.
Spring offers the equivalent of #1, though you can also use other templating languages (Velocity, WebMacro) or other MVC frameworks (Struts, Tapestry). In simple cases, JSP with Spring is sufficient. What Spring does really well is to keep you from polluting your view logic with application logic and your application logic with data access logic while at the same time minimizing developer effort. It also provides a ton of features which you can use piecemeal if you don't need all of them.
Hibernate offers #2 and #3, though #3 and connection pooling are provided through third-party implementations of defined interfaces.
I believe Hibernate is capable of using any JDBC DataSource, so this can be provided by whatever implementation you want. Spring has perfectly usable implementations, but you can also use ones from Apache or some other provider. This offers flexibility in that a DataSource can be provided as a JNDI resource.
Caching is handled by one of a number of caching implementations (default is EHCache) which can be selected depending on what features you need. If need be, you can even implement your own caching provider.
There is an access control system for Spring called ACEGI. From my experience, it's quite capable.
Obviously, since I've never looked at your implementation, I can't compare this solution with the one you've written. But I can say that it's unlikely that you've created a system which, end to end, offers the power, flexibility and ease of use that Hibernate/Spring do. The trend in these kinds of architectures is increasingly moving away from the single, all-encompassing frameworks like EJB. Instead, like another poster noted, the trend is to use a number of light-weight frameworks which pick one aspect of the overall architecture (MVC, ORM, caching, security, templating, etc) and do it well, with defined interfaces so that other implementations can be swapped easily. While your implementation might work well for you since you know the code and can make modifications to it so that it perfectly suits your environment, it won't be very useful to the general public. For a framework to be useful to the rest of us, it has to be flexible to fit in our environments without having to go in and hack the code. Hibernate and Spring have already proven to be this flexible. You might consider looking at these frameworks and determining whether ideas from your implementation can be included into these frameworks. Both communitites have very active developer discussion forums, so if you feel either solution is lacking in some respect, bring it up there and they can either tell you why they do it differently or incorporate your ideas into their projects.
Those are good points, but I think the larger critique of this benchmark is that the application he created isn't as complex as real-world webapps. Java's strength has never been running simple/small applications.
Java's strength comes as complexity increases when other languages/frameworks breakdown due to their inability to scale (from a machine resources perspective and/or a developer maintenance perspective). It isn't until you've developed a webapp with 5+ developers and millions of lines of code that you truly begin to appreciate the power of the Java/Spring/Hibernate combination.
But you're right...for a true comparison he should have used something like Resin (for XML and AppServer).
Where I work, none of the developers have this problem. I maintain an update server with all the plug-ins our team uses. Whenever any of the plug-ins are updated, I test out the update and then push it to our update server. Other developers get it with a simple dialog the next time the start Eclipse. When we update to a new major revision of Eclipse, it's a simple matter of adding our custom update server and then selecting all the plug-ins you want. It's all pretty painless. You can also export your prefs and import to your new install.
The most painful part is when plug-ins aren't designed to be updated via an update server. I have to package them myself. This may be a bit more work for an individual developer, but for a team of developers, it just takes a couple of hours every month by one developer to make all this easy for the entire team.
Right, and none of this is a substantial change from last November, and we all saw how little backlash there was against Bush and company. All it took was few mentions of gay marriage and they won pretty convincingly.
What I meant by animosity is a sentiment that can't be hidden behind a platform of relatively meaningless issues (gay marriage, Schiavo, etc). You can pull out all the polls you want, but Bush and company will find some other minor issue and convince Americans that it should be the deciding issue for the election. And, absent any real animosity, Americans will forget about all the real issues. As inept as this administration has proved in handling real issues like the economy and foreign policy, they've shown themselves to be very adept at the propaganda necessary to hide their ineptitudes.
Don't confuse "what we think today" with animosity. Animosity is far less fickle.
We're not going to see the hundreds-thousands strong marches on Washington that we saw in 1970, but that's because Americans don't communicate that way any more. Instead, we're going to see Republicans take a big hit in Congress in 2006. If they lose the House, and perhaps the Senate, we might actually see impeachment.
This is pretty much the least likely scenario in today's world. People don't care about casualties unless they have a personal connection with the soldier killed. There is no personal sense of loss for them, so it won't influence their vote. As long as people with a personal connection to a soldier KIA remain an insignificant demographic, the President doesn't have to worry about this issue. He can always convince the majority of the voting populace that the most important issue is gay people marrying or ending the life of someone who essentially died 15 years ago. Media manipulation is just too powerful and Americans just don't care enough.
However, the President does have to worry about casualties of a different kind. If people aren't able to find good jobs, they'll want to vote the president out. Even if their situation had nothing to do with the President, this would be the case. It's very possible that the 2006 election will swing towards the Democrats, but it will be financial harship and not personal hardship that will be the cause.
And because there really isn't any animosity towards the President on the part of voters, you won't see the Democrats go after Bush. It would be seen as a vindictive act and possibly as retaliation for the Clinton impeachment or the Florida election scandal. That won't go over well in the polls, so you won't see it happen.
Take an American Social Security Number for instance. Technically, no one but the government can require you to give out the number. Workplaces, however, often ask for it, when applying, so that they can fill out government income tax forms. Health care facilities often ask for things like medic-aid and medicare.
The problem with SSNs has nothing to do with the uses you've listed. It's an ID that is intended to identify you to the government. Tax forms, health care, etc are valid reasons for the government to need a unique identifier. What isn't valid is the credit card companies piggy-backing off the government's ID system. That usage (applying for credit cards) is the primary reason why SSNs are problematic and people's identities are stolen. Without that usage, SSNs would be mostly harmless.
Identity theft is a huge problem, but its one that needs to be primarily addressed within the banking industry. Addressing it in other ways is simply letting them off the hook. If they got their act together, you could tell your SSN to anyone you wanted without fear of it being used illegally.
Great, then it shouldn't be too hard to standardize an interface to these libraries and allow other browsers Opera/Firefox/etc to implement that interface and allow the user to choose a different default rendering engine.
This would empower the user to opt for more secure rendering of html without inconviniencing 3rd-party developers who need html rendering and don't want to roll their own.
Hard Drives are like types of hard liquor. Everyone has at least one that they had a horrible experience with and now avoid like the plague.
Seriously, given that hard drives are one the most common computer failures, most serious computer users will experience them eventually. And given the consequences (data loss), users don't easily forget that it happened. The result is that almost everyone has their trusted brand of hard drive. Also, chances are that if you were to post your preference for your trusted brand, you'd get 20+ responses from people who've had a nightmarish experience with your favorite brand.
I think that the number of such civilizations that we can currently contact that are between times B and C may be small.
Right now the human race seems to think that whatever they say is worth listening to.
True, however I would imagine the fact that they are using radio waves as a means of communication would probably mean that they fall into that category. Those before B won't be able to send radio waves so, for all practical purposes, they don't exist to us. Those after C will probably have developed a technology more efficient than radio waves...something that solves the 50 year transit problem mentioned in the article. Whatever advanced form of communication they've developed is likely bouncing off our unenlightened skulls as we speak just as our radio waves would bounce off the skulls of the unenlightened time B civilization which has no concept of radio waves.
I participated in a program when I was in high school where I spent the summer in South America giving immunizations. When we were learning how to give shots, we gave each other a ton of saline injections. Once our technique was good enough and we were relaxed enough as patients, we didn't feel the needle going in.
However, bad technique or tensed muscles can cause pain. Therefore, people with a fear of needles will probably end up feeling pain since they tense up.
To backup your other point, we gave a lot of vaccinations at schools, but since they were MMR shots (sub-q needle), the students rarely felt any pain from the needle. You can even minimize the perceived pain by pinching the area a bit prior to giving the shot (easy to do this while doing the pre-shot cleaning.) But while the kids were generally pleasantly surprised by the lack of pain, we had grown men reduced to tears after their tetanus shots. The IM needles actually do hurt a bit, but the medication is a bitch!
Well, in all the hype over steroids, one thing being missed is Canseco's opinion that they can be a valuable tool for improving the health of certain individuals.
The government is so quick to demonize substances as having no benefit, but we, as nerds, should try to look beyond the FDA/DEA rhetoric and look to studies which follow proper scientific protocol. The benfits of steroids are clear...they help you grow more muscle and recover from injury faster (and by injury, I include fatigue.) The drawbacks have not been as clearly enumerated. The scientific community should be studying steroids and looking at chemically similar substances that may offer the same benefits without as many drawbacks.
Wouldn't it be nice if the study of steroids yielded some form of nutritional supplement that safely helped us speed healing and growth of muscle tissue? Who cares if a bunch of jocks with IQs only slightly higher than the pieces of wood they're swinging are using these substances to hit a baseball harder than they could have otherwise? The interaction between a substance and the human body is still interesting on a scientific level and could have serious benefits for society as a whole if studied properly.
Just out of curiousity, have you tried contact Google about them? You could try reporting them to Google. If you explain your situation (stolen credit card, scam site, etc), there's a good chance Google will delist the site.
The point was never that legitimate use constituted a majority or even a significant percentage of the usage of BitTorrent. The point was that legitimate use was significant. The difference is that in one case you're comparing illegal use to legal use. In the other, you're not making a comparison.
The latter consideration would become extremely important if content producers filed suit against BitTorrent creators. The fact that they could point to examples like Debian, a non-profit entity with clear benefits to American businesses, and show that it is saving Debian money would make it really hard for content producers to make their case.
The result is that content providers have to go after those that run trackers which offer the copyrighted content. The other result is that the P2P world has found its transport layer. If BitTorrent can be standardized and protocol implementations made available to the various platforms, we can start to see a whole new set of P2P applications which use BitTorrent to transfer the content but use some other method for listing the content. Some of these methods will be blatantly illegal, but others will have signifcant legal use (like BitTorrent) or be so decentralized (like Gnutella) that they too will be near impossible to litigate out of existance.
I suspect the content producers realize this and all the lawsuits have never had the goal of preventing this from happening, but instead simply prolonging the status-quo (where they make a ton of money.)
When working in a team, it's really helpful to agree on a certain line length so that long lines do not wrap. It used to be 80 cols was standard, but with larger displays, this is somtimes increased. If different members of the team have different TAB display settings, it effects when they break the line and put the rest of the statement on the next line. So, if I use a tab display of 2, it's likely that some of the lines of code that I write would wrap on your display.
Also, some languages (notably the C variants) are most easily read when certain elements are aligned properly. Take for instance: (slashdot lameness filter breaks the line, but you can get the idea)
public void someReallyLongMethodNameWhereYouToRunOutOfSpace( SomeReallyLongTypeName type,
SomeOtherLongTypeName otherType)...
If you use tabs, you can only accomplish this if the desired indenting level is an exact multiple of your tab stop setting. It will also end up being formatted badly for anyone with different tab settings from the code's author.
Also, using tabs removes some of the flexibility you have when using indenting. Even though it's pretty rare, sometimes you come across a situation where using a different indentation allows you to put an entire statement on one line and increase the readability of the code. If you use tabs, this is harder to do.
BTW...our dev team had a 4-space standard (which was frequently broken by someone I'm sure you can guess;)
For me, it was primarily decreasing the amount of carbohydrates that I consumed. It's not as extreme as Atkins or South Beach, but I basically try to make sure that every meal is less than 50% carbs. The 5-HTP helps with this since I rarely crave carbs anymore. I also try to make sure that the carbs I do eat aren't from corn syrup (something I now believe to incredibly unhealthy, though I have no real evidence to back that up.)
The exercise part probably has as much to do with keeping my sleep patterns as anything else, since it helps me maintain a consistant schedule. Keeping a consistant sleep schedule is extremely important, as is spending time outdoors during the daytime (lack of sunlight can also bring on depression.)
As to whether it's really working, yes, I believe it is. I'm not going to say it would work for everyone, but I think my depression (like you, bipolar II) was brought on by bad eating habbits and a tendency to have an erratic sleep schedule where I stayed up 24+ hours at a time.
Slashdot Mirror
Maturity has nothing to do with actual age and everything to do with having a history of being used successfully. The more people have found that a project/product helps them successfully solve a problem, the greater the chance that it can be used to solve your problem provided your problem is similar in nature to the problems of others.
Java's maturity comes from having millions of people run into, enumerate and complain about it's shortcomings. In early versions, Java was slow. Newer versions have JIT compilers which make it very competitive speedwise for most applications. Generics are another example. Programmers complained about how ugly it is to always have to cast objects coming out of collections. Java evolved to include syntactic sugar to avoid all those ugly casts.
It's the little tweaks that make things mature. Java has had quite a while now to find what needs tweaking and fix it. More importantly, the platform has shown itself to be pretty stable and unlikely to change drastically from version to version. It is valid to say that Java is a proven technology that is very likely to remain stable for the forseable future. There may be very good reasons to use Ruby and rails for webapps, but a long history of successful deployment isn't one of them.
Mature isn't nearly as vague as the blog posting contends.
It sounds like you're essentially suggesting that open source create something similar to the .NET CLR. It's an interesting idea, but it would be really difficult to get everyone to work together and agree on design details. .NET has the advantage that Microsoft gets to make all the decisions, so when an implementation choice would favor one language over another, they decide based on which language will make them more money. Open source projects won't subjugate themselves when it comes to these kinds of decisions. It could very easily end up in a situation where everyone argues and nothing ever gets done right or done at all.
Something like that stands a much better chance of happening if someone just goes off and does it. It would be neat if this new JVM includes an extension mechanism that allows people to write JIT compilers for other languages. But I just don't see Java users getting behind a runtime that doesn't place Java concerns ahead of all else. So I think it's doubtful that Parrot itself would ever end up being used as the basis for a new JVM.
...however, PHP (far more popular for web development, especially with less experienced programmers) is not. It has a serialize to string function, however, this is not terribly useful if you have several variables (unless you want to deal with delimiting the variables, making sure the proper character(s) are escaped, and then unrolling that later).
Why would you bother with delimiters when PHP is perfectly capable of serializing arrays/hashes. Just dump all your variables into an array and serialize. The code necessary to implement this kind of caching is literally 3-4 lines, with a couple more to check the timestamp on your cache file for expiration purposes. As I said before, there's nothing new here...I've seen a ton of PHP apps/libraries that implement caching in this manner.
I agree that there are a ton of inexperienced PHP coders out there writing bad code who will never fully understand the theory of good v. bad caching solutions. But if you're going to try to teach something to those programmers, you should understand these issues a bit better. It's not hard to do a little research before advising others to use some new method you've cooked up. Otherwise, it's just a case of the blind leading the blinder.
It's not part of the elements of style, but some people use it. I like it because it eliminates the need for the 'this' keyword in setters.
private int _something;
public void setSomething(int something) {
_something = something;
}
vs.
private int something;
public void setSomething(int something) {
this.something = something;
}
Also, it keeps you from having to track down an annoying type bug...
private int something;
public void setSomething(int soomething) {
this.something = something;
}
In the above case, the extra 'o' won't cause a compilation error, but the setter will mysteriously do nothing. If you prefix your instance variable with an underscore, you'll get a compile time error.
No offense, but a lot of this sounds like poor advice.
Firstly, a lot of your caching solution should depend on what tools or language features are available for the language you're using to implement your site. For example, advocating caching things to disk isn't really necessary when you're using Java since it's more effective to use in-memory caches. If you use an ORM solution like Hibernate, caching happens behind the scenes and you don't even have to think about it. However, if you're using a scripting language like Perl or PHP, you can't use in-memory caches and have to turn to some sort of on-disk storage.
Secondly, even if you're going to cache to disk, there's usually better ways to do it than having special files (case 1) or saving the entire generated page to disk (case 2). For example, the en vogue way of doing disk caching in PHP is to serialize your data structure to disk and then unserialize it on every request. From there, the page can be generated normally and you've still avoided the trip to the database while retaining far more flexibility when it comes to making your page dynamic.
Thirdly, caching isn't rocket science. In every language I can think of, third-party tools exist to help you handle that aspect of your app for you to keep you from having to write your own custom implementation. Unless you've profiled your application and know that optimizing a certain part will have substantial benefit, using an off-the-shelf solution will make your application far more manageable and far more friendly to developers not already familiar with the code.
The main thing to remember is that if you're having this issue, chances are it's not new and someone has effectively solved your problem in the past...just go look for their solution. The world needs another roll-your-own caching solution like it needs another proprietary video or PHP/MySQL book...
FWIW, caching is also built into Hibernate and other ORM solutions for Java.
I would imagine the benefits of caching would be outweighed by the drawbacks of maintaining a custom caching solution in most cases unless profiling the application has shown that it is absolutely necessary.
Why would they snoop traffic when they could just pay students to go find the copyrighted files???
It's not like there's a shortage of students with internet2 connections that know where to go for copyrighted music files and would do just about anything for $20/hr.
The kind of system you're talking about needs to be compared with the combination of Spring and Hibernate. Some people might include MiddleGen too, though I've worked on projects without it and we've done alright.
Spring offers the equivalent of #1, though you can also use other templating languages (Velocity, WebMacro) or other MVC frameworks (Struts, Tapestry). In simple cases, JSP with Spring is sufficient. What Spring does really well is to keep you from polluting your view logic with application logic and your application logic with data access logic while at the same time minimizing developer effort. It also provides a ton of features which you can use piecemeal if you don't need all of them.
Hibernate offers #2 and #3, though #3 and connection pooling are provided through third-party implementations of defined interfaces.
I believe Hibernate is capable of using any JDBC DataSource, so this can be provided by whatever implementation you want. Spring has perfectly usable implementations, but you can also use ones from Apache or some other provider. This offers flexibility in that a DataSource can be provided as a JNDI resource.
Caching is handled by one of a number of caching implementations (default is EHCache) which can be selected depending on what features you need. If need be, you can even implement your own caching provider.
There is an access control system for Spring called ACEGI. From my experience, it's quite capable.
Obviously, since I've never looked at your implementation, I can't compare this solution with the one you've written. But I can say that it's unlikely that you've created a system which, end to end, offers the power, flexibility and ease of use that Hibernate/Spring do. The trend in these kinds of architectures is increasingly moving away from the single, all-encompassing frameworks like EJB. Instead, like another poster noted, the trend is to use a number of light-weight frameworks which pick one aspect of the overall architecture (MVC, ORM, caching, security, templating, etc) and do it well, with defined interfaces so that other implementations can be swapped easily. While your implementation might work well for you since you know the code and can make modifications to it so that it perfectly suits your environment, it won't be very useful to the general public. For a framework to be useful to the rest of us, it has to be flexible to fit in our environments without having to go in and hack the code. Hibernate and Spring have already proven to be this flexible. You might consider looking at these frameworks and determining whether ideas from your implementation can be included into these frameworks. Both communitites have very active developer discussion forums, so if you feel either solution is lacking in some respect, bring it up there and they can either tell you why they do it differently or incorporate your ideas into their projects.
Those are good points, but I think the larger critique of this benchmark is that the application he created isn't as complex as real-world webapps. Java's strength has never been running simple/small applications.
Java's strength comes as complexity increases when other languages/frameworks breakdown due to their inability to scale (from a machine resources perspective and/or a developer maintenance perspective). It isn't until you've developed a webapp with 5+ developers and millions of lines of code that you truly begin to appreciate the power of the Java/Spring/Hibernate combination.
But you're right...for a true comparison he should have used something like Resin (for XML and AppServer).
Height can be somewhat indicative of good health. There was an interesting MLP on K5 about this subject.
It's this perceived superior health that leads to higher sex appeal and respect.
Where I work, none of the developers have this problem. I maintain an update server with all the plug-ins our team uses. Whenever any of the plug-ins are updated, I test out the update and then push it to our update server. Other developers get it with a simple dialog the next time the start Eclipse. When we update to a new major revision of Eclipse, it's a simple matter of adding our custom update server and then selecting all the plug-ins you want. It's all pretty painless. You can also export your prefs and import to your new install.
The most painful part is when plug-ins aren't designed to be updated via an update server. I have to package them myself. This may be a bit more work for an individual developer, but for a team of developers, it just takes a couple of hours every month by one developer to make all this easy for the entire team.
Right, and none of this is a substantial change from last November, and we all saw how little backlash there was against Bush and company. All it took was few mentions of gay marriage and they won pretty convincingly.
What I meant by animosity is a sentiment that can't be hidden behind a platform of relatively meaningless issues (gay marriage, Schiavo, etc). You can pull out all the polls you want, but Bush and company will find some other minor issue and convince Americans that it should be the deciding issue for the election. And, absent any real animosity, Americans will forget about all the real issues. As inept as this administration has proved in handling real issues like the economy and foreign policy, they've shown themselves to be very adept at the propaganda necessary to hide their ineptitudes.
Don't confuse "what we think today" with animosity. Animosity is far less fickle.
We're not going to see the hundreds-thousands strong marches on Washington that we saw in 1970, but that's because Americans don't communicate that way any more. Instead, we're going to see Republicans take a big hit in Congress in 2006. If they lose the House, and perhaps the Senate, we might actually see impeachment.
This is pretty much the least likely scenario in today's world. People don't care about casualties unless they have a personal connection with the soldier killed. There is no personal sense of loss for them, so it won't influence their vote. As long as people with a personal connection to a soldier KIA remain an insignificant demographic, the President doesn't have to worry about this issue. He can always convince the majority of the voting populace that the most important issue is gay people marrying or ending the life of someone who essentially died 15 years ago. Media manipulation is just too powerful and Americans just don't care enough.
However, the President does have to worry about casualties of a different kind. If people aren't able to find good jobs, they'll want to vote the president out. Even if their situation had nothing to do with the President, this would be the case. It's very possible that the 2006 election will swing towards the Democrats, but it will be financial harship and not personal hardship that will be the cause.
And because there really isn't any animosity towards the President on the part of voters, you won't see the Democrats go after Bush. It would be seen as a vindictive act and possibly as retaliation for the Clinton impeachment or the Florida election scandal. That won't go over well in the polls, so you won't see it happen.
Take an American Social Security Number for instance. Technically, no one but the government can require you to give out the number. Workplaces, however, often ask for it, when applying, so that they can fill out government income tax forms. Health care facilities often ask for things like medic-aid and medicare.
The problem with SSNs has nothing to do with the uses you've listed. It's an ID that is intended to identify you to the government. Tax forms, health care, etc are valid reasons for the government to need a unique identifier. What isn't valid is the credit card companies piggy-backing off the government's ID system. That usage (applying for credit cards) is the primary reason why SSNs are problematic and people's identities are stolen. Without that usage, SSNs would be mostly harmless.
Identity theft is a huge problem, but its one that needs to be primarily addressed within the banking industry. Addressing it in other ways is simply letting them off the hook. If they got their act together, you could tell your SSN to anyone you wanted without fear of it being used illegally.
Great, then it shouldn't be too hard to standardize an interface to these libraries and allow other browsers Opera/Firefox/etc to implement that interface and allow the user to choose a different default rendering engine.
This would empower the user to opt for more secure rendering of html without inconviniencing 3rd-party developers who need html rendering and don't want to roll their own.
So do I.
(ok, so I actually just select the PDF printer, but it's still the same number of clicks)
Hard Drives are like types of hard liquor. Everyone has at least one that they had a horrible experience with and now avoid like the plague.
Seriously, given that hard drives are one the most common computer failures, most serious computer users will experience them eventually. And given the consequences (data loss), users don't easily forget that it happened. The result is that almost everyone has their trusted brand of hard drive. Also, chances are that if you were to post your preference for your trusted brand, you'd get 20+ responses from people who've had a nightmarish experience with your favorite brand.
I think that the number of such civilizations that we can currently contact that are between times B and C may be small.
Right now the human race seems to think that whatever they say is worth listening to.
True, however I would imagine the fact that they are using radio waves as a means of communication would probably mean that they fall into that category. Those before B won't be able to send radio waves so, for all practical purposes, they don't exist to us. Those after C will probably have developed a technology more efficient than radio waves...something that solves the 50 year transit problem mentioned in the article. Whatever advanced form of communication they've developed is likely bouncing off our unenlightened skulls as we speak just as our radio waves would bounce off the skulls of the unenlightened time B civilization which has no concept of radio waves.
Exactly.
I participated in a program when I was in high school where I spent the summer in South America giving immunizations. When we were learning how to give shots, we gave each other a ton of saline injections. Once our technique was good enough and we were relaxed enough as patients, we didn't feel the needle going in.
However, bad technique or tensed muscles can cause pain. Therefore, people with a fear of needles will probably end up feeling pain since they tense up.
To backup your other point, we gave a lot of vaccinations at schools, but since they were MMR shots (sub-q needle), the students rarely felt any pain from the needle. You can even minimize the perceived pain by pinching the area a bit prior to giving the shot (easy to do this while doing the pre-shot cleaning.) But while the kids were generally pleasantly surprised by the lack of pain, we had grown men reduced to tears after their tetanus shots. The IM needles actually do hurt a bit, but the medication is a bitch!
Well, in all the hype over steroids, one thing being missed is Canseco's opinion that they can be a valuable tool for improving the health of certain individuals.
The government is so quick to demonize substances as having no benefit, but we, as nerds, should try to look beyond the FDA/DEA rhetoric and look to studies which follow proper scientific protocol. The benfits of steroids are clear...they help you grow more muscle and recover from injury faster (and by injury, I include fatigue.) The drawbacks have not been as clearly enumerated. The scientific community should be studying steroids and looking at chemically similar substances that may offer the same benefits without as many drawbacks.
Wouldn't it be nice if the study of steroids yielded some form of nutritional supplement that safely helped us speed healing and growth of muscle tissue? Who cares if a bunch of jocks with IQs only slightly higher than the pieces of wood they're swinging are using these substances to hit a baseball harder than they could have otherwise? The interaction between a substance and the human body is still interesting on a scientific level and could have serious benefits for society as a whole if studied properly.
That's why we should care.
You're right...for that you'd need 2 drops of holy water and an incantation.
Just out of curiousity, have you tried contact Google about them? You could try reporting them to Google. If you explain your situation (stolen credit card, scam site, etc), there's a good chance Google will delist the site.
The point was never that legitimate use constituted a majority or even a significant percentage of the usage of BitTorrent. The point was that legitimate use was significant. The difference is that in one case you're comparing illegal use to legal use. In the other, you're not making a comparison.
The latter consideration would become extremely important if content producers filed suit against BitTorrent creators. The fact that they could point to examples like Debian, a non-profit entity with clear benefits to American businesses, and show that it is saving Debian money would make it really hard for content producers to make their case.
The result is that content providers have to go after those that run trackers which offer the copyrighted content. The other result is that the P2P world has found its transport layer. If BitTorrent can be standardized and protocol implementations made available to the various platforms, we can start to see a whole new set of P2P applications which use BitTorrent to transfer the content but use some other method for listing the content. Some of these methods will be blatantly illegal, but others will have signifcant legal use (like BitTorrent) or be so decentralized (like Gnutella) that they too will be near impossible to litigate out of existance.
I suspect the content producers realize this and all the lawsuits have never had the goal of preventing this from happening, but instead simply prolonging the status-quo (where they make a ton of money.)
It's not quite that simple.
...
;)
When working in a team, it's really helpful to agree on a certain line length so that long lines do not wrap. It used to be 80 cols was standard, but with larger displays, this is somtimes increased. If different members of the team have different TAB display settings, it effects when they break the line and put the rest of the statement on the next line. So, if I use a tab display of 2, it's likely that some of the lines of code that I write would wrap on your display.
Also, some languages (notably the C variants) are most easily read when certain elements are aligned properly. Take for instance: (slashdot lameness filter breaks the line, but you can get the idea)
public void someReallyLongMethodNameWhereYouToRunOutOfSpace( SomeReallyLongTypeName type,
SomeOtherLongTypeName otherType)
If you use tabs, you can only accomplish this if the desired indenting level is an exact multiple of your tab stop setting. It will also end up being formatted badly for anyone with different tab settings from the code's author.
Also, using tabs removes some of the flexibility you have when using indenting. Even though it's pretty rare, sometimes you come across a situation where using a different indentation allows you to put an entire statement on one line and increase the readability of the code. If you use tabs, this is harder to do.
BTW...our dev team had a 4-space standard (which was frequently broken by someone I'm sure you can guess
For me, it was primarily decreasing the amount of carbohydrates that I consumed. It's not as extreme as Atkins or South Beach, but I basically try to make sure that every meal is less than 50% carbs. The 5-HTP helps with this since I rarely crave carbs anymore. I also try to make sure that the carbs I do eat aren't from corn syrup (something I now believe to incredibly unhealthy, though I have no real evidence to back that up.)
The exercise part probably has as much to do with keeping my sleep patterns as anything else, since it helps me maintain a consistant schedule. Keeping a consistant sleep schedule is extremely important, as is spending time outdoors during the daytime (lack of sunlight can also bring on depression.)
As to whether it's really working, yes, I believe it is. I'm not going to say it would work for everyone, but I think my depression (like you, bipolar II) was brought on by bad eating habbits and a tendency to have an erratic sleep schedule where I stayed up 24+ hours at a time.