How often do judges admit they were wrong when presented with additional evidence? If they were so biased as to infer things that weren't even claimed by the DHS, are they going to admit they made a mistake or hedge and hide in the gray areas? Seems like an appeal to a higher court may get better results, but IANAL and don't understand the possible options or reasoning goes into these decision.
This is one of the dumbest things to debate ever. Choose your arbitrary definition and I'll choose mine. Then we can argue about who's correct, using other arbitrary definitions as evidence. Our perception of sport is entirely cultural and the sooner we get over the labels, the better off we'll all be.
Yes, you're missing something. Imagine you opt out of tracking and the company erases all information about you (including their cookies). What happens the next time you hit their system? You look like somebody they've never seen before. In most systems, that means they give you a cookie and start tracking you. But you just asked them not to track you...
The only way they can comply is to know that you fall into the group of people who don't want to be tracked. In general, they can do this with a generic "do-not-track" cookie value they drop (like an ID with all zeros, e.g.). Then you and everybody else who doesn't want to be tracked looks identical, but you all still have a cookie from them.
You mentioned IP address as a way to track users, but that's really unreliable. So you want to go opt out again every time you restart your modem or connect to another network? If you're behind a NAT, your opt out would affect everybody behind the NAT (but only until the external address changed, at which point it would affect nobody).
As a side note: If you clear all your cookies every time you close your browser, your tracking starts fresh with every browsing session. It doesn't mean you aren't tracked - it just means the scope of the tracking matches the scope the cookie lifetime. I leave my browser up for days/weeks at a time, so deleting cookies on close would actually make me more trackable than an opt-out. A whitelist of sites you accept cookies from is the best way to minimize tracking, but most people won't understand or bother with that. Storing an opt-out cookie is a really simple next-best-thing.
You're somehow being obtuse and elitist at the same time. I didn't use these terms to sound smart. I used them to "facilitate rapid communication" within the field of "software engineering". I'm sorry if you find them distasteful, but that doesn't make them worthless.
What's the alternative? Full paragraph descriptions of each concept? Catch phrases catch on because succinctly convey meaning. There's nothing magical about either the phrases or the concepts behind them, but that doesn't mean the concepts are useless.
"Agile" is definitely over-used, but it actually *can* mean things. In my circle, it's always referred to a collection of traits including timeboxed iteration and bottom-up planning. I'd say to fundamental goal of "Agile" development is to codify the "release early, release often" mantra into your development process as efficiently as possible.
What you suggest sounds like a less-capable Twitter. I think you're greatly over-simplifying social networking. Almost nobody uses it simply to have a website; those inanities you hate are what actually get and keep users. In fact, I see no "social" in your social networking at all.
Interesting. I'm a big fan of scrum. Tellingly, I've also never had a serious discussion about pigs and chickens. I think there are a lot of useful tenets of scrum (e.g., timeboxing, group scheduling, bottom-up planning, iterative learning) and I've seen people pick-and-choose simply because don't see the usefulness of a tenet (even though they haven't tried them). If somebody is harping on some aspect of scrum, I would hope it's because they don't think your org has ever done it right. If your org really tries it, it doesn't work, and they're still mindlessly harping on it, well, yeah, that's dumb.
BTW, if code review is a horrible pain in the ass, you've got a culture problem, IMO. Assuming there aren't real concerns with your code, either you're not following the standards (perhaps there are no standards), the reviewer doesn't trust you, or the reviewer is a jerk. I wouldn't say any of those things reduces the value of code review; you've just got a larger problem that needs solving.
Holy crap. I just spent an hour on that site and I still can't accurately summarize what this guy wants. There's such an amazing amount of text that he probably would have better results if he had just spent that time actually building his perfect system.
All I know is I saw a lot of pages that were updated 5-10 years ago complaining about things that either aren't serious problems I've encountered or are addressed by a good ORM package. I'm totally open to hearing that OOP is broken, but I want to see specific use-cases where it breaks down and specific ways your system is better (so I can decide if any of that is relevant to me). That shouldn't take more than, say, 5 pages, should it? I can't even count the pages on that site...
Totally true but, as I understand it, Apple didn't have very lucrative enterprise customers to keep happy. Microsoft's technology has, at times, limited its success, but I believe the converse is also true.
Thanks for digging up the study. As an aside, I'm not sure why TDD is so bundled with Agile. It may well have surfaced with the movement, but it could apply to any software development model... I've worked in various agile teams and never practiced TDD.
So this study is interesting. I immediately see a number of issues with it. First, it looks like it's actually measuring two dimensions at the same time: add a formalized testing policy + use TDD. From reading about the teams, it looks like their previous testing methodology was "write whatever tests you think are necessary." So it's not at all clear whether the changes in bugs and productivity are a result of TDD or the formalized policy. It could be that a simple formal testing policy would have caused the same changes, but we can't really know because they don't seem to isolate their variables.
The teams are also new to TDD, so you don't know how they'd perform at peak efficiency. Plus they can't really measure the gains of having a library of tests to run against your code - something that makes future refactoring and extensions much simpler.
The defect rate does seem significantly reduced (which is further evidence to me that the team had no formalized testing practice prior to TDD). It's misleading to say "but it took X% longer" when you have no way to measure what the future cost of the bugs would be. You'd have to do this study over a long period of time and multiple dev cycles to determine how much their productivity was actually impacted.
This last point is the most important to me. And it's why I want to understand the methodology behind claiming the overall feature rate is the same. Bugs cost a lot and reducing them does seem like a recipe for long-term productivity.
Simply having improved fault levels should improve your productivity, as you'll spend less time hunting / fixing bugs and more time on new features. Or do you end up spending MORE time on a feature, but deliver it with higher quality?
Sorry, I'm not trying to be difficult. I just want to understand what trade-offs you're experiencing to yield your conclusion.
As far as I can see there is no actual benefit in productivity at all moving to agile. It just gives greater clarity to the current state of development and should produce software with lower levels of faults through automated testing and continuous integration.
This sounds like a recipe for improved productivity to me. How are you measuring your productivity level?
I wouldn't say no danger. I don't understand why people think that not using their info online means nobody can access their info online. If your data is stored anywhere, there's a good chance some sequence of events could leak it.
That said, you've probably reduced your vulnerable surface area, but don't get too confident; incompetence comes in all forms, many of which are probably handling your (and my) data.
Go to a bank and ask about your options. After I got out of school and went to get my first credit card, I couldn't get one because I had no credit history and was no longer in the "terrible credit risk" demographic (see the documentary "Maxed Out," btw). Anyway, the bank had a "secured" card in which I prepaid (set my own credit limit with cash) and used it for a year. At the end of the year of responsible use, they gave me my money back and let me keep the credit limit. Now I have a credit history and have since obtained several more credit cards (which I max out and never pay! hahahah.... but not really)
Considering Google just released Google Instant, a feature that reduces overall query time (and also just happens to increases overall ad impressions), I don't think "online time" is a particularly meaningful metric for relevance.
In my opinion, this reply was much nicER (minus the fruitless taunting about the apparently-poor choice of the word "feel").
1. Feeling held up is not being held up. 2. Mental Blocks are your problem. Not a speed issue.
Actually, it is being held up and it is a speed issue. Assuming a mental block, the fade in activates the mental block and I wait for it to complete, thereby being delayed by the combination of their site design and my defective brain.
This next part is hearsay, but I believe Google has copyright text at the bottom of the home page simply as a visual cue that the page is loaded. The tale I heard goes that when they were user testing the original home page, people sat there waiting for it to load because they didn't realize it had finished; the text at the bottom gave them an unconscious signal it was done. My point is that visual cues are critical to UI design and you have to factor in subconscious activity to achieve your desired effects.
This is all assuming a mental block is even the issue. I brought up the mental block because it's a possibility and would make my frustration at least partially my fault, but it does not invalidate my point that including fade in fights speed and efficiency. What's the other option? Not fading in, which is maximally fast for everybody (including brain-damaged me). By definition, the fade-in has created a situation that is not as fast as it could be.
That said, I know I'm not alone in this. The post I replied to by Garble Snarky expressed the same sort of displeasure with the fade in. That doesn't make me right, but it shows that other people seem to have the same perspective. Perhaps this is evidence that I'm not as unreasonable as you seem to believe.
Well I feel held up and annoyed by the fade-in. It might just be a mental block that prevents me from processing the page without it loading or I might just be hyper-sensitive to any kind of delay.
Either way, I stand by my assertion that adding fade-in works against being fast and efficient. That statement can be objectively true and also not impact everybody. For example, if you have a script that simulates mouse clicks and have to introduce a delay because of the fade in, the fade in has impacted the speed of your script.
Slashdot Mirror
How often do judges admit they were wrong when presented with additional evidence? If they were so biased as to infer things that weren't even claimed by the DHS, are they going to admit they made a mistake or hedge and hide in the gray areas? Seems like an appeal to a higher court may get better results, but IANAL and don't understand the possible options or reasoning goes into these decision.
This is one of the dumbest things to debate ever. Choose your arbitrary definition and I'll choose mine. Then we can argue about who's correct, using other arbitrary definitions as evidence. Our perception of sport is entirely cultural and the sooner we get over the labels, the better off we'll all be.
Yes, you're missing something. Imagine you opt out of tracking and the company erases all information about you (including their cookies). What happens the next time you hit their system? You look like somebody they've never seen before. In most systems, that means they give you a cookie and start tracking you. But you just asked them not to track you...
The only way they can comply is to know that you fall into the group of people who don't want to be tracked. In general, they can do this with a generic "do-not-track" cookie value they drop (like an ID with all zeros, e.g.). Then you and everybody else who doesn't want to be tracked looks identical, but you all still have a cookie from them.
You mentioned IP address as a way to track users, but that's really unreliable. So you want to go opt out again every time you restart your modem or connect to another network? If you're behind a NAT, your opt out would affect everybody behind the NAT (but only until the external address changed, at which point it would affect nobody).
As a side note: If you clear all your cookies every time you close your browser, your tracking starts fresh with every browsing session. It doesn't mean you aren't tracked - it just means the scope of the tracking matches the scope the cookie lifetime. I leave my browser up for days/weeks at a time, so deleting cookies on close would actually make me more trackable than an opt-out. A whitelist of sites you accept cookies from is the best way to minimize tracking, but most people won't understand or bother with that. Storing an opt-out cookie is a really simple next-best-thing.
You're somehow being obtuse and elitist at the same time. I didn't use these terms to sound smart. I used them to "facilitate rapid communication" within the field of "software engineering". I'm sorry if you find them distasteful, but that doesn't make them worthless.
What's the alternative? Full paragraph descriptions of each concept? Catch phrases catch on because succinctly convey meaning. There's nothing magical about either the phrases or the concepts behind them, but that doesn't mean the concepts are useless.
"Agile" is definitely over-used, but it actually *can* mean things. In my circle, it's always referred to a collection of traits including timeboxed iteration and bottom-up planning. I'd say to fundamental goal of "Agile" development is to codify the "release early, release often" mantra into your development process as efficiently as possible.
What you suggest sounds like a less-capable Twitter. I think you're greatly over-simplifying social networking. Almost nobody uses it simply to have a website; those inanities you hate are what actually get and keep users. In fact, I see no "social" in your social networking at all.
Wrong. Facebook *is* profitable. Google just plain screwed up.
http://www.businessinsider.com/facebook-details-leaked-company-is-much-more-profitable-than-everyone-thought-2011-1
Interesting. I'm a big fan of scrum. Tellingly, I've also never had a serious discussion about pigs and chickens. I think there are a lot of useful tenets of scrum (e.g., timeboxing, group scheduling, bottom-up planning, iterative learning) and I've seen people pick-and-choose simply because don't see the usefulness of a tenet (even though they haven't tried them). If somebody is harping on some aspect of scrum, I would hope it's because they don't think your org has ever done it right. If your org really tries it, it doesn't work, and they're still mindlessly harping on it, well, yeah, that's dumb.
BTW, if code review is a horrible pain in the ass, you've got a culture problem, IMO. Assuming there aren't real concerns with your code, either you're not following the standards (perhaps there are no standards), the reviewer doesn't trust you, or the reviewer is a jerk. I wouldn't say any of those things reduces the value of code review; you've just got a larger problem that needs solving.
Achievement Unlocked!
Shit Slinger: Begin and end a sentence with the word "bullshit"!
Kudos to you, sir. I apologize for the low blow.
Interesting. This lends some perspective to his site, which reads like a shrine to his hatred of everybody who won't get off his lawn.
Holy crap. I just spent an hour on that site and I still can't accurately summarize what this guy wants. There's such an amazing amount of text that he probably would have better results if he had just spent that time actually building his perfect system.
All I know is I saw a lot of pages that were updated 5-10 years ago complaining about things that either aren't serious problems I've encountered or are addressed by a good ORM package. I'm totally open to hearing that OOP is broken, but I want to see specific use-cases where it breaks down and specific ways your system is better (so I can decide if any of that is relevant to me). That shouldn't take more than, say, 5 pages, should it? I can't even count the pages on that site...
Totally true but, as I understand it, Apple didn't have very lucrative enterprise customers to keep happy. Microsoft's technology has, at times, limited its success, but I believe the converse is also true.
Thanks for digging up the study. As an aside, I'm not sure why TDD is so bundled with Agile. It may well have surfaced with the movement, but it could apply to any software development model... I've worked in various agile teams and never practiced TDD.
So this study is interesting. I immediately see a number of issues with it. First, it looks like it's actually measuring two dimensions at the same time: add a formalized testing policy + use TDD. From reading about the teams, it looks like their previous testing methodology was "write whatever tests you think are necessary." So it's not at all clear whether the changes in bugs and productivity are a result of TDD or the formalized policy. It could be that a simple formal testing policy would have caused the same changes, but we can't really know because they don't seem to isolate their variables.
The teams are also new to TDD, so you don't know how they'd perform at peak efficiency. Plus they can't really measure the gains of having a library of tests to run against your code - something that makes future refactoring and extensions much simpler.
The defect rate does seem significantly reduced (which is further evidence to me that the team had no formalized testing practice prior to TDD). It's misleading to say "but it took X% longer" when you have no way to measure what the future cost of the bugs would be. You'd have to do this study over a long period of time and multiple dev cycles to determine how much their productivity was actually impacted.
This last point is the most important to me. And it's why I want to understand the methodology behind claiming the overall feature rate is the same. Bugs cost a lot and reducing them does seem like a recipe for long-term productivity.
Simply having improved fault levels should improve your productivity, as you'll spend less time hunting / fixing bugs and more time on new features. Or do you end up spending MORE time on a feature, but deliver it with higher quality?
Sorry, I'm not trying to be difficult. I just want to understand what trade-offs you're experiencing to yield your conclusion.
As far as I can see there is no actual benefit in productivity at all moving to agile. It just gives greater clarity to the current state of development and should produce software with lower levels of faults through automated testing and continuous integration.
This sounds like a recipe for improved productivity to me. How are you measuring your productivity level?
I am just a legal layman, but I find this comment incredibly insightful. I'd mod you up if I had points.
I believe Freeman has a Ph.D. in theoretical physics from MIT. Definitely a scientist, just probably also the new guy.
I wouldn't say no danger. I don't understand why people think that not using their info online means nobody can access their info online. If your data is stored anywhere, there's a good chance some sequence of events could leak it.
That said, you've probably reduced your vulnerable surface area, but don't get too confident; incompetence comes in all forms, many of which are probably handling your (and my) data.
Go to a bank and ask about your options. After I got out of school and went to get my first credit card, I couldn't get one because I had no credit history and was no longer in the "terrible credit risk" demographic (see the documentary "Maxed Out," btw). Anyway, the bank had a "secured" card in which I prepaid (set my own credit limit with cash) and used it for a year. At the end of the year of responsible use, they gave me my money back and let me keep the credit limit. Now I have a credit history and have since obtained several more credit cards (which I max out and never pay! hahahah.... but not really)
Considering Google just released Google Instant, a feature that reduces overall query time (and also just happens to increases overall ad impressions), I don't think "online time" is a particularly meaningful metric for relevance.
I tried to be nice but ok.
In my opinion, this reply was much nicER (minus the fruitless taunting about the apparently-poor choice of the word "feel").
1. Feeling held up is not being held up.
2. Mental Blocks are your problem. Not a speed issue.
Actually, it is being held up and it is a speed issue. Assuming a mental block, the fade in activates the mental block and I wait for it to complete, thereby being delayed by the combination of their site design and my defective brain.
This next part is hearsay, but I believe Google has copyright text at the bottom of the home page simply as a visual cue that the page is loaded. The tale I heard goes that when they were user testing the original home page, people sat there waiting for it to load because they didn't realize it had finished; the text at the bottom gave them an unconscious signal it was done. My point is that visual cues are critical to UI design and you have to factor in subconscious activity to achieve your desired effects.
This is all assuming a mental block is even the issue. I brought up the mental block because it's a possibility and would make my frustration at least partially my fault, but it does not invalidate my point that including fade in fights speed and efficiency. What's the other option? Not fading in, which is maximally fast for everybody (including brain-damaged me). By definition, the fade-in has created a situation that is not as fast as it could be.
That said, I know I'm not alone in this. The post I replied to by Garble Snarky expressed the same sort of displeasure with the fade in. That doesn't make me right, but it shows that other people seem to have the same perspective. Perhaps this is evidence that I'm not as unreasonable as you seem to believe.
Proof by "you're wrong" is never very convincing... If you'd instead like to address my point, feel free.
Well I feel held up and annoyed by the fade-in. It might just be a mental block that prevents me from processing the page without it loading or I might just be hyper-sensitive to any kind of delay.
Either way, I stand by my assertion that adding fade-in works against being fast and efficient. That statement can be objectively true and also not impact everybody. For example, if you have a script that simulates mouse clicks and have to introduce a delay because of the fade in, the fade in has impacted the speed of your script.