For a Web world, compartmentalisation of sign-on is vital.
Only up to a point.
I have 128 logins that I keep. I know that because don't remember any of them, I have a file full of them. When I use Yet Another Website, I'm really tired of making Yet Another Login.
If one no longer wishes to have dealings with a site, it is easy to randomise the password and delete the corresponding e-mail alias.
If you think that using openId from Site A to log into site B gives site B ways to continue having dealing with you against your wishes, then can you outline how that can happen? How many internbet users have "e-mail aliases" to throw away.
This seems like a last gasp from OpenID to convince someone, anyone, of the relevance of SSO.
I've seen a fair amount of OpenId around recently. You can sue it on Blogger and LiveJournal. If it's a "last gasp" for a declining technology, how do you back that statement up?
But the consumers weren't hurt when Enron blew itself up. Sure, the investors lost their shirts,
1) Normal people invest in institutions - you know, unit trusts, pensions and stuff - these buy Enron shares. These consumers are investors, and they got hurt.
2) I have colleagues whose former employer (in the IT Industry) laid off a lot of staff as a result of the collapse of Enron collapse. Were these staff consumers? Was an Enron janitor watching his pension go up in smoke a consumer? Were Anderson's employees? Yes.
Unless you're referring to the days of Grey-outs. That wasn't really Enron per-se - that was a classic case of private companies taking advantage of dumb government loopholes.
Right, that wasn't begin eaten by Lions per se - it was just a case of predators exhibiting natural behaviour and taking advantage of dumb tourists.
Because of this one point of difference I still don't believe SVN is a mature product.
I don't think it's because the SVN team are incompetent or haven't finished the basic feature set yet and their product is "immature".
It's about priorities - Oddly enough, the SVN developer team and community don't seem to have prioritised the feature of a revision-tracking system totally losing track of a revision. Priorities, as in "that's very far down on most people's list of priorities".
Yup - updating multiple bits of c+p code where the two are subtly different is a 'mare.
Do both versions need to be updated? Do changes to one mean that the new fix is not applicable to to? Was the change to one version in fact a fix that should be applied out to the others? Can they be consolidated again? Should you rather just a find a blunt, heavy object and apply it to the original author instead?
These can both be used to prevent code building if it doesn't meet standards. Sadly, the first task for me is usually to turn on "warnings as errors" and get the code up to that minimal standard.
The problem with code standards is that your best coders are probably using a standard already; and the while the worst can be dragged onto a standard, they will write bad code even with it.
Also found I prefix in.NET really bad practice for marking interfaces like ICollection, what about when You decide turn interface to abstract class?..
You rename it.
Is this common for you? Tell me the last time that it was a "really bad" problem. It's not common for me. In fact the only similar refactoring that I've ever seen used is the opposite: to extract an interface from a class.
An interface is different to an abstract base class; an interface doesn't determine the base class heritage. If you make that kind of change, you should also be prepared to rename the interface/class.
The difference between ""cut and paste" friendly code" and "use Cut and paste" is the difference between "bake a nice cake" and "get obese and prone to illness".
Code that is well-factored can be (incidentally) suitable for cut-and-paste, but using cut and paste is the problem.
It's better than calling it "Anno Domini". "Common Era" may be up for debate, and there's a good case in favour of it seeing as it's a widely used calendar, but "Year of our lord" would just be factually wrong for me to write.
But "all of that" of the Romans wasn't destroyed. There were still lots of texts and crumbling buildings. It just took a long time for the veneration of the texts "from the wise ancients" to die down enough for people to start experimenting for themselves. Galileo's observations that the Earth went around the Sun not vice versa were considered so radical in 1610 because it was different to what Ptolemy and Aristotle had said was the truth.
200 years: 20th century English is viewed a lot like Shakespearean text are by us: you can work it out, but it's tedious. It's not how anyone talks. People actually talk and write in a language that is descended from l33t, lol and txt. 2000 years: 20th century English is an academic topic, like ancient Latin is today. Average people can recognize a few words or phrases at best. 5000 years "The inscriptions on this ancient treasure-heard seem to claim that elixir contained inside will bring your ancestors back to life!
Slashdot Mirror
Err no. MS doesn't usually make their code publicly available. I wonder where you saw it..
Probably on Codeplex
the code Microsoft develops by themselves haven't you? Its not pretty.
Microsoft is a big company. The code standards, and sometimes the language, will vary from department to department. At least.
I disagree, it's got a lot of nasty clever in it. The grandparent comment could have easily come from The Twat-O-Tron
Really, really bad move. Now, instead of two years at summer camp, he will go to many more years of Federal Pound-me-in-the-a$$ Prison.
Spammers are not known for taking the long view and doing the right thing.
Next thing you know, they'll be outlawing alcohol and chopping your hand off if you badmouth Allah.
You belong on this website: spEak You're bRanes
For a Web world, compartmentalisation of sign-on is vital.
Only up to a point.
I have 128 logins that I keep. I know that because don't remember any of them, I have a file full of them. When I use Yet Another Website, I'm really tired of making Yet Another Login.
If one no longer wishes to have dealings with a site, it is easy to randomise the password and delete the corresponding e-mail alias.
If you think that using openId from Site A to log into site B gives site B ways to continue having dealing with you against your wishes, then can you outline how that can happen? How many internbet users have "e-mail aliases" to throw away.
This seems like a last gasp from OpenID to convince someone, anyone, of the relevance of SSO.
I've seen a fair amount of OpenId around recently. You can sue it on Blogger and LiveJournal. If it's a "last gasp" for a declining technology, how do you back that statement up?
But the consumers weren't hurt when Enron blew itself up. Sure, the investors lost their shirts,
1) Normal people invest in institutions - you know, unit trusts, pensions and stuff - these buy Enron shares. These consumers are investors, and they got hurt.
2) I have colleagues whose former employer (in the IT Industry) laid off a lot of staff as a result of the collapse of Enron collapse. Were these staff consumers? Was an Enron janitor watching his pension go up in smoke a consumer? Were Anderson's employees? Yes.
Unless you're referring to the days of Grey-outs. That wasn't really Enron per-se - that was a classic case of private companies taking advantage of dumb government loopholes.
Right, that wasn't begin eaten by Lions per se - it was just a case of predators exhibiting natural behaviour and taking advantage of dumb tourists.
If government was ran like a business I'd be all for them having control over utilities.
So business does it better then?
Because of this one point of difference I still don't believe SVN is a mature product.
I don't think it's because the SVN team are incompetent or haven't finished the basic feature set yet and their product is "immature".
It's about priorities - Oddly enough, the SVN developer team and community don't seem to have prioritised the feature of a revision-tracking system totally losing track of a revision. Priorities, as in "that's very far down on most people's list of priorities".
With the exception of that last sentence, that sounds like something I would tell someone to get out of doing any actual work.
Pairing does sound like taking it easy at first, but I suggest reading the whole Wikipedia article before saying that.
By Hg do you mean Mercurial?
What is there about it that makes developers better or worse at merging?
I'm assuming that you're not agreeing that CVS would solve this particular problem, since it merges much like SVN does?
For the love of Dog, please don't move from SVN to CVS.
SVN was designed as a "compelling replacement" for CVS. And it succeeds.
I've yet to see a compelling reason to move to SVN.
That doesn't mean that there's a reason to move back. If you don't see the benefits of atomic commits, keeping version history over file moves an renames, and rapid branching then by all means, stay with your CVS. Just don't drag other people back down with you.
If nothing else, CVS is pretty much a dead end. The next version of CVS is SVN. SVN has a development roadmap, CVS has migration-to-svn utilities.
You mean pair programming.
Yup, that's pretty much what I said. Interfaces tend to come out from classes. Not vice versa.
make the function do foo before it returns
That's exactly what try...finally blocks are for. See here.
Why would anyone decide that return statements were off-limits? I don't know, but some people do.
I don't think it's a valid rule. there is a longer discussion of the topic here
That do{ ... } while(0); thing is horrible, it's taking bad code and making it worse, not better.
I recently argued against the "single return statement" rule over here.
This exposes an implementation detail to the user of the Object
In many languages, an interface is not an object.
and makes it difficult to refactor
Refactor how, and how often do you do this? Reply under this comment, please.
Yup - updating multiple bits of c+p code where the two are subtly different is a 'mare.
Do both versions need to be updated? Do changes to one mean that the new fix is not applicable to to? Was the change to one version in fact a fix that should be applied out to the others? Can they be consolidated again? Should you rather just a find a blunt, heavy object and apply it to the original author instead?
If you are using your computer right, it does not only enable you to do things, it does the boring things for you, automatically.
Exactly. Use the tools.
In the .net world, check out
fxCop: http://msdn.microsoft.com/en-us/library/bb429476(vs.80).aspx
StyleCop: http://code.msdn.microsoft.com/sourceanalysis
These can both be used to prevent code building if it doesn't meet standards. Sadly, the first task for me is usually to turn on "warnings as errors" and get the code up to that minimal standard.
Also check out Resharper: http://www.jetbrains.com/resharper/
for flagging some code problems.
The problem with code standards is that your best coders are probably using a standard already; and the while the worst can be dragged onto a standard, they will write bad code even with it.
Also found I prefix in .NET really bad practice for marking interfaces like ICollection, what about when You decide turn interface to abstract class?..
You rename it.
Is this common for you? Tell me the last time that it was a "really bad" problem. It's not common for me. In fact the only similar refactoring that I've ever seen used is the opposite: to extract an interface from a class.
An interface is different to an abstract base class; an interface doesn't determine the base class heritage. If you make that kind of change, you should also be prepared to rename the interface/class.
The difference between ""cut and paste" friendly code" and "use Cut and paste" is the difference between "bake a nice cake" and "get obese and prone to illness".
Code that is well-factored can be (incidentally) suitable for cut-and-paste, but using cut and paste is the problem.
There are several tools that can detect cut and paste code:
Simian: http://www.redhillconsulting.com.au/products/simian/
PMD: http://pmd.sourceforge.net/
DuplicateFinder: http://www.codeplex.com/DuplicateFinder
And probably others
Still of topic here:
It's better than calling it "Anno Domini".
"Common Era" may be up for debate, and there's a good case in favour of it seeing as it's a widely used calendar, but "Year of our lord" would just be factually wrong for me to write.
But "all of that" of the Romans wasn't destroyed. There were still lots of texts and crumbling buildings. It just took a long time for the veneration of the texts "from the wise ancients" to die down enough for people to start experimenting for themselves. Galileo's observations that the Earth went around the Sun not vice versa were considered so radical in 1610 because it was different to what Ptolemy and Aristotle had said was the truth.
200 years: 20th century English is viewed a lot like Shakespearean text are by us: you can work it out, but it's tedious. It's not how anyone talks. People actually talk and write in a language that is descended from l33t, lol and txt.
2000 years: 20th century English is an academic topic, like ancient Latin is today. Average people can recognize a few words or phrases at best.
5000 years "The inscriptions on this ancient treasure-heard seem to claim that elixir contained inside will bring your ancestors back to life!