The third, fourth, and fifth word on every Wikipedia page is "edit this page".
Nevermind the fact that the vast majority of the general public doesn't appreciate what a wiki is, people have been conditioned to *read* web pages. Even though "edit this page" appears all over the place, people aren't used to the idea of editing web content. Therefor they can't indirectly appreciate that the page they are reading was written by many people over time.
By a disclaimer, I'm talking about something more direct and like: "This page was written by several people (some of whom are anonymous) working together and could contain factual errors."
I get what you mean when you say that over-disclaiming on web pages is ridiculous but a wiki is not a traditional website. It's a dumping ground for text and can be easily vandalized. This seriously changes the rules of the game for readers and it should be pointed out to them in a *direct* way.
We can't just assume that everyone who reads Wikipedia will bother to figure out what a wiki is and appreciate the consequences.
Wikipedia is a wiki - quite obviously, the system is not perfect and it has its benefits and its downfalls. They are not claiming otherwise, either.
Since when is a wiki "obvious"? Wikis are far too new for the *general public* that reads Wikipedia to be aware of their consequences.
Wikipedia markets itself as an encyclopedia and then wonders why (or passes the buck when) people get upset when the information is incorrect. Wikipedia needs to do a better job explaining to people where the information comes from and why it might not be accurate instead of patting itself on the back.
How about a disclaimer on *every single Wikipedia page*?
So this tragedy is no 'closer' to us personally in the UK than it is in the US...
Many of the countries hit by this earthquake/tsunami are former British colonies (India, Sri Lanka/Ceylon, Malaysia, Maldives, Myanmar/Burma) and others were formerly under the colonial power of European nations (Indonesia was once Dutch ruled, Madagascar was French ruled, etc).
It seems that the UK (and Europe) has much closer personal ties to these countries than the US, so that could explain the increased coverage in the UK.
I agree though, the short attention span of American media definitely has something to do with it. It's interesting that some people are saying "that could never happen to the US, so that's why people don't care."
There's a volcano on the Canary Islands that could erupt and trigger a tsunami that would deluge the Eastern coast of the United States. The west coast of the US is vulnerable to tsunamis created by the "Ring of Fire". Maybe this disaster will not only get counties around the Indian Ocean to take tsunamis more seriously, but also people on the coasts of the US as well.
One point of contention seems to be "how will you navigate a music collection with no screen?" as an argument against making a player this small.
The answer has been around for quite some time, but Apple is the kind of company that could actually do it right: an audio interface to replace the display. People are already wearing earphones, they could listen to the menus instead of viewing them.
The other issue is replacing the input wheel. Rather than taking audio input (speech), it's more likely they would change the form factor and make new input hardware to fit on a smaller device with a different form factor than the iPod or iPod mini.
I could see the input hardware being more sensitive to touch, because you don't have the visual feedback of a screen... maybe "bump" or resistence feedback of some sort, brail-like but electronic so you can use the input without looking at the player at all.
Consider this a starting point for discussion...:)
Come on guys. I need 1.0 pronto.... Version 1.0 would be nice ASAP.
What's with the obsession with version numbers? Firefox has been terrific for months and has been getting great reviews from the press and guys like Joel Spolsky.
This is something the Mozilla guys have to convey to the public a little better: Don't wait for 1.0, switch now!
Of course you are right that counting funtions or objects and methods if you are doing c++ would be a better metric but that was not in the artical.
Actually I wasn't talking about counting functions or objects, I was talking about counting function points, which are a more accurate software metric used for estimations:
If you're a software developer, you should check out function points even just to know they exist as a better alternative to LOC.
f you told me that he wrote a 100,000 lines of code I would doubt it a lot. 10,000 lines of code in a year is reasonable to say the least.
Why, do you doubt Linus' typing skills? Lines of code (LOC) is a terrible software metric. The only reason we use it is:
1. It's easy to measure. 2. It's easier to calculate than function points, which are more accurate.
The problem with #1 is that everyone formats code differently, which effects LOC measurements. That makes comparisons pretty dubious at best.
Of course a million lines of code is unreasonable. Not because a person can't write a million lines of proper C code in a year but because no one would write a million lines of ANYTHING in that time. It's useless hyperbole.
The focus should be on *what* the kernel was able to do at that time, not the LOC count, in order to make the assertion that it was possible for Linus to create the *functionality* by himself in that amount of time. This is the only fair comparison.
The kernel at that time could have been 20% useless cruft code brought on by a poor design (likely, as he was a student). This is not taken into account when one only considers the LOC count of 10,000.
The Trolls should look nothing like the Cave Troll in the Fellowship. They are more like country bumpkins. They have clothes, sacks, ropes and know how to make jelly. They have some kind of civilization. They are stupid but are not animalistic like the trolls in LOTR the movie.
Agreed. However, the Trolls *were* in the Lord of the Rings movies. If you watch Fellowship, you'll notice that they camp next to the stone trolls. So they might want to have them look somewhat like the stone versions.
#1: My biggest problems always revolve around the user interface.
But what would you rather debug: 1) A problem in the user interface you know has to be in the user interface because you have confidence that it's not below it or 2) the whole thing all the way down all of the method calls? If you have unit tests in the rest of the code, debugging the UI is much easier.
#2: I spent many hours developing tests for things that ended up rarely/never choking my tests....
Making tests for situations that work is still valuable. If you make such a test and it fails later on, you'll know you had a regression in the code somewhere. This is very handy to have when refactoring as well.
#3: Whenever I re-factor, unless I'm Mr. Perfect and all my interfaces are perfect from the get-go...
Interfaces can be refactored too, and of course you'll break tests and have to rewrite things because now you're expecting a new set of behaviour.
I've found that this has the side benefit of forcing people to really think about changes they make to their code and not just hack away at it. If people know they have to write tests too they seem to put more thought into it ahead of time.
Anyway, that's just my personal experience with unit testing.
The first wow, that's cool moment I had with test driven development was from an article on Object Mentor called The Bowling Game. It also highlights pair programming a bit.
The unique thing about the article was that it was presented as a discussion between two developers pair programming doing agile test driven development of the game. It was like watching over their shoulders.
If you want to get an idea of what extreme programming is like, I suggest reading this article AND writing the code and tests along with it, either in Java (and JUnit) or C#/VB.NET (and NUnit) or another language with a xUnit unit testing framework. Most object oriented languages have them now so you don't have to roll your own framework.
My experience has been that "unit testing" slows development to a painfully slow crawl.
This is a common miconception about test-driven development. Sure, when you look at the speed at which new features go in, "development" seems to be slowing to a crawl.
But this is a very short-sighted and limited view of the whole project lifecycle. I've found that having great unit tests for my code actually help in the long run for adding new features. And that's not just adding the features to the code base, that's all the way to the end -- making sure they work properly.
Nevermind the benefit they give while refactoring in an agile development process: the unit tests become a sort contract you can guarantee will work for objects that use your code, no matter the internals of a function. For refactoring this is invaluable.
In short, you're not alone. Very few developers think long term like this and it's a shame. But once you drink the unit testing/test driven design (TDD) kool-aid I guarantee you'll never go back. I wouldn't think of writing code without unit tests any more and quite often it's TDD.
It should be interesting to see if outside contributors will morph the Rich Client Platform into some sort of new browser. It's just being introduced in Eclipse 3.0 and could be the basis for a lot of new Eclipse-partner software.
OK, so what if you could put a URL into it and it would load a whole application. The bonus is that you don't have to use the limited browser widget set or hacked together CSS-DHTML widgets, but can still deliver a piece of software like an ASP (Application Service Provider) that's NOT DHTML based and all of the advantages of that (instant updates, metered us) for businesses.
That's not to say there aren't disadvantages, but it will be interesting to see what people come up with.
To people who live in Toronto, any place smaller than Toronto isn't a city. Therefore Sault Ste. Marie must be something less, a town.
That is a typical center-of-the-universe ignorant Torontonian attitude. By that logic Ottawa must be a town too. And Edmonton, Calgary, Winnipeg. All smaller than Toronto yet they are all cities. Fairly big cities I might add.
In fact, if you read the wikipedia article I linked to it will tell you that Sault Ste. Marie was incorporated as a city in 1912.
To Americans (and others worldwide) who might be unfamiliar, Torontonians are often mocked by the rest of the country for reasons exactly like this. Ah well... it gives Newfoundlanders someone to make fun of.
Just so people not familiar with the place know, the Toronto Star is kind of stretching the word "town" here. Sault Ste. Marie has a population of over 75,000 people.
Also, "hydros" in the article refer to the power utilities like Ontario Hydro. "Hydro" (water) comes from the fact that they get some of the power from hydroelectric damns.
Furthermore the hacker can do more than just tampering data. Indeed it can overload the collider resulting in an explosion. This would set off a cloud of toxic material threatening the surrounding villages.
Indeed, that sounds very dangerous. They ought to secure their computer systems, eh?
People are quick to blame the hacker/cracker/script kiddie but that's the easy way out. If companies and organizations don't take security seriously, a dangerous incident like this could happen.
But who cares, right? We can always just blame the cracker AFTER THE FACT. That's just absurd. We need to concentrate more on preventing these incidents. Increasing the level of punishment will only make the hacks more risky and attractive to extreme personalities.
Re:every rose has its thorn
on
SCO Offline
·
· Score: 1
Let's hope something good comes out of this idiocy.
I agree. How about an end to baseless lawsuits? How about an end to scripting support in e-mail clients? Those things would be nice.
have tried each and every release of Eclipse and found it to be a terrible IDE. It's so unintutive that I could almost believe that Sun made their Solaris developers work on it in secret just to piss of Sun.
Just because you can't pick up a complicated piece of software like an IDE right away doesn't mean that it is unintuitive. Try Eclipse for 6 months and then get back to us.
You have to dispose of everything explicitly (al la C++) which completely goes against Javas garbage collection paradigm.
There are some widgets like Fonts which have to be disposed manually. Most widgets are disposed automatically.
There is even a little application you can download from the Eclipse web site to spot when widgets aren't disposed properly.
I'm a Java developer of 4 years and I'm unimpressed by generics... I don't see the need for all that extra ugly syntax just to enforce it at compile time.
It's a good thing then that you don't have to use generics if you don't want to. The choice is great, isn't it?
Personally I do a lot of development with the Java collection framework. Generics will save me a lot of time and code spent checking Object types.
For those of us with small screens, having to leave "room" for a drawer to pop out visibly is a waste. If I make iCal the width of the screen without the drawer, the drawer will just pop out off the screen and I'll have to move the iCal window over just to see it, losing the left side in the process. This is annoying.
I want to maximize the width of iCal so I can read more on the calendar. I can't do that if I need to leave space for a drawer to pop out.
Now, you could make an argument that having the detachable window is better for screen 'real estate' as you can leave just a little piece of it visible, behind the iCal main window, and click it to bring it forward.
IMO, the popup window is much better because now I don't have to resize or move the iCal window whenI want to see the info. By the way, you can pop up and close it with Command-I, which is a lot easier than mousing over to a visible piece of it.
Unless you have the horizontal space to pop out the drawer without it going offscreen, I think detachable window is easier to use. But you're right, we're entitled to our own opinions.
Slashdot Mirror
The third, fourth, and fifth word on every Wikipedia page is "edit this page".
Nevermind the fact that the vast majority of the general public doesn't appreciate what a wiki is, people have been conditioned to *read* web pages. Even though "edit this page" appears all over the place, people aren't used to the idea of editing web content. Therefor they can't indirectly appreciate that the page they are reading was written by many people over time.
By a disclaimer, I'm talking about something more direct and like: "This page was written by several people (some of whom are anonymous) working together and could contain factual errors."
I get what you mean when you say that over-disclaiming on web pages is ridiculous but a wiki is not a traditional website. It's a dumping ground for text and can be easily vandalized. This seriously changes the rules of the game for readers and it should be pointed out to them in a *direct* way.
We can't just assume that everyone who reads Wikipedia will bother to figure out what a wiki is and appreciate the consequences.
Wikipedia is a wiki - quite obviously, the system is not perfect and it has its benefits and its downfalls. They are not claiming otherwise, either.
Since when is a wiki "obvious"? Wikis are far too new for the *general public* that reads Wikipedia to be aware of their consequences.
Wikipedia markets itself as an encyclopedia and then wonders why (or passes the buck when) people get upset when the information is incorrect. Wikipedia needs to do a better job explaining to people where the information comes from and why it might not be accurate instead of patting itself on the back.
How about a disclaimer on *every single Wikipedia page*?
So this tragedy is no 'closer' to us personally in the UK than it is in the US...
Many of the countries hit by this earthquake/tsunami are former British colonies (India, Sri Lanka/Ceylon, Malaysia, Maldives, Myanmar/Burma) and others were formerly under the colonial power of European nations (Indonesia was once Dutch ruled, Madagascar was French ruled, etc).
It seems that the UK (and Europe) has much closer personal ties to these countries than the US, so that could explain the increased coverage in the UK.
I agree though, the short attention span of American media definitely has something to do with it. It's interesting that some people are saying "that could never happen to the US, so that's why people don't care."
There's a volcano on the Canary Islands that could erupt and trigger a tsunami that would deluge the Eastern coast of the United States. The west coast of the US is vulnerable to tsunamis created by the "Ring of Fire". Maybe this disaster will not only get counties around the Indian Ocean to take tsunamis more seriously, but also people on the coasts of the US as well.
Of course I spelt braille wrong, my bad.
One point of contention seems to be "how will you navigate a music collection with no screen?" as an argument against making a player this small.
... maybe "bump" or resistence feedback of some sort, brail-like but electronic so you can use the input without looking at the player at all.
:)
The answer has been around for quite some time, but Apple is the kind of company that could actually do it right: an audio interface to replace the display. People are already wearing earphones, they could listen to the menus instead of viewing them.
The other issue is replacing the input wheel. Rather than taking audio input (speech), it's more likely they would change the form factor and make new input hardware to fit on a smaller device with a different form factor than the iPod or iPod mini.
I could see the input hardware being more sensitive to touch, because you don't have the visual feedback of a screen
Consider this a starting point for discussion...
... they're just a tax on people who are bad at math.
The odds are still terrible you'll win an iPod Mini, but it looks like the only thing signing up for this will cost you is your time.
Come on guys. I need 1.0 pronto .... Version 1.0 would be nice ASAP.
What's with the obsession with version numbers? Firefox has been terrific for months and has been getting great reviews from the press and guys like Joel Spolsky.
This is something the Mozilla guys have to convey to the public a little better: Don't wait for 1.0, switch now!
Of course you are right that counting funtions or objects and methods if you are doing c++ would be a better metric but that was not in the artical.
Actually I wasn't talking about counting functions or objects, I was talking about counting function points, which are a more accurate software metric used for estimations:
If you're a software developer, you should check out function points even just to know they exist as a better alternative to LOC.
f you told me that he wrote a 100,000 lines of code I would doubt it a lot. 10,000 lines of code in a year is reasonable to say the least.
Why, do you doubt Linus' typing skills? Lines of code (LOC) is a terrible software metric. The only reason we use it is:
1. It's easy to measure.
2. It's easier to calculate than function points, which are more accurate.
The problem with #1 is that everyone formats code differently, which effects LOC measurements. That makes comparisons pretty dubious at best.
Of course a million lines of code is unreasonable. Not because a person can't write a million lines of proper C code in a year but because no one would write a million lines of ANYTHING in that time. It's useless hyperbole.
The focus should be on *what* the kernel was able to do at that time, not the LOC count, in order to make the assertion that it was possible for Linus to create the *functionality* by himself in that amount of time. This is the only fair comparison.
The kernel at that time could have been 20% useless cruft code brought on by a poor design (likely, as he was a student). This is not taken into account when one only considers the LOC count of 10,000.
I have wrote a 14,000 line application in less than three months.
:)
So what?
I can write a Java program that can produce 14,000 lines of useless but valid C code in about 5 minutes.
The quantity of code shouldn't be the question, which is Tanenbaum's point. What could the kernel do at 0.1? Well, not much.
So is it belieable that Linux wrote it all by himself? Sure it is. The LOC argument is pretty stupid, isn't it?
The Trolls should look nothing like the Cave Troll in the Fellowship. They are more like country bumpkins. They have clothes, sacks, ropes and know how to make jelly. They have some kind of civilization. They are stupid but are not animalistic like the trolls in LOTR the movie.
Agreed. However, the Trolls *were* in the Lord of the Rings movies. If you watch Fellowship, you'll notice that they camp next to the stone trolls. So they might want to have them look somewhat like the stone versions.
Which, I imagine, makes this story not a dupe, but a triplicate!
Would that be a tripe? How appropriate.
It's a little picky on format (you have to do (555) 555-4444, not 5555554444 or 555-555-4444)
It's probably really picky because of the Google calculator. The other versions of the phone number you have there are valid mathematical expressions.
#1: My biggest problems always revolve around the user interface.
But what would you rather debug: 1) A problem in the user interface you know has to be in the user interface because you have confidence that it's not below it or 2) the whole thing all the way down all of the method calls? If you have unit tests in the rest of the code, debugging the UI is much easier.
#2: I spent many hours developing tests for things that ended up rarely/never choking my tests....
Making tests for situations that work is still valuable. If you make such a test and it fails later on, you'll know you had a regression in the code somewhere. This is very handy to have when refactoring as well.
#3: Whenever I re-factor, unless I'm Mr. Perfect and all my interfaces are perfect from the get-go...
Interfaces can be refactored too, and of course you'll break tests and have to rewrite things because now you're expecting a new set of behaviour.
I've found that this has the side benefit of forcing people to really think about changes they make to their code and not just hack away at it. If people know they have to write tests too they seem to put more thought into it ahead of time.
Anyway, that's just my personal experience with unit testing.
The first wow, that's cool moment I had with test driven development was from an article on Object Mentor called The Bowling Game. It also highlights pair programming a bit.
The unique thing about the article was that it was presented as a discussion between two developers pair programming doing agile test driven development of the game. It was like watching over their shoulders.
If you want to get an idea of what extreme programming is like, I suggest reading this article AND writing the code and tests along with it, either in Java (and JUnit) or C#/VB.NET (and NUnit) or another language with a xUnit unit testing framework. Most object oriented languages have them now so you don't have to roll your own framework.
My experience has been that "unit testing" slows development to a painfully slow crawl.
This is a common miconception about test-driven development. Sure, when you look at the speed at which new features go in, "development" seems to be slowing to a crawl.
But this is a very short-sighted and limited view of the whole project lifecycle. I've found that having great unit tests for my code actually help in the long run for adding new features. And that's not just adding the features to the code base, that's all the way to the end -- making sure they work properly.
Nevermind the benefit they give while refactoring in an agile development process: the unit tests become a sort contract you can guarantee will work for objects that use your code, no matter the internals of a function. For refactoring this is invaluable.
In short, you're not alone. Very few developers think long term like this and it's a shame. But once you drink the unit testing/test driven design (TDD) kool-aid I guarantee you'll never go back. I wouldn't think of writing code without unit tests any more and quite often it's TDD.
It should be interesting to see if outside contributors will morph the Rich Client Platform into some sort of new browser. It's just being introduced in Eclipse 3.0 and could be the basis for a lot of new Eclipse-partner software.
OK, so what if you could put a URL into it and it would load a whole application. The bonus is that you don't have to use the limited browser widget set or hacked together CSS-DHTML widgets, but can still deliver a piece of software like an ASP (Application Service Provider) that's NOT DHTML based and all of the advantages of that (instant updates, metered us) for businesses.
That's not to say there aren't disadvantages, but it will be interesting to see what people come up with.
To people who live in Toronto, any place smaller than Toronto isn't a city. Therefore Sault Ste. Marie must be something less, a town.
... it gives Newfoundlanders someone to make fun of.
That is a typical center-of-the-universe ignorant Torontonian attitude. By that logic Ottawa must be a town too. And Edmonton, Calgary, Winnipeg. All smaller than Toronto yet they are all cities. Fairly big cities I might add.
In fact, if you read the wikipedia article I linked to it will tell you that Sault Ste. Marie was incorporated as a city in 1912.
To Americans (and others worldwide) who might be unfamiliar, Torontonians are often mocked by the rest of the country for reasons exactly like this. Ah well
heh, ya ooops ... finger must have slipped *rolls eyes*
Just so people not familiar with the place know, the Toronto Star is kind of stretching the word "town" here. Sault Ste. Marie has a population of over 75,000 people.
Also, "hydros" in the article refer to the power utilities like Ontario Hydro. "Hydro" (water) comes from the fact that they get some of the power from hydroelectric damns.
Furthermore the hacker can do more than just tampering data. Indeed it can overload the collider resulting in an explosion. This would set off a cloud of toxic material threatening the surrounding villages.
Indeed, that sounds very dangerous. They ought to secure their computer systems, eh?
People are quick to blame the hacker/cracker/script kiddie but that's the easy way out. If companies and organizations don't take security seriously, a dangerous incident like this could happen.
But who cares, right? We can always just blame the cracker AFTER THE FACT. That's just absurd. We need to concentrate more on preventing these incidents. Increasing the level of punishment will only make the hacks more risky and attractive to extreme personalities.
Let's hope something good comes out of this idiocy.
I agree. How about an end to baseless lawsuits? How about an end to scripting support in e-mail clients? Those things would be nice.
have tried each and every release of Eclipse and found it to be a terrible IDE. It's so unintutive that I could almost believe that Sun made their Solaris developers work on it in secret just to piss of Sun.
Just because you can't pick up a complicated piece of software like an IDE right away doesn't mean that it is unintuitive. Try Eclipse for 6 months and then get back to us.
You have to dispose of everything explicitly (al la C++) which completely goes against Javas garbage collection paradigm.
There are some widgets like Fonts which have to be disposed manually. Most widgets are disposed automatically.
There is even a little application you can download from the Eclipse web site to spot when widgets aren't disposed properly.
I'm a Java developer of 4 years and I'm unimpressed by generics ... I don't see the need for all that extra ugly syntax just to enforce it at compile time.
It's a good thing then that you don't have to use generics if you don't want to. The choice is great, isn't it?
Personally I do a lot of development with the Java collection framework. Generics will save me a lot of time and code spent checking Object types.
For those of us with small screens, having to leave "room" for a drawer to pop out visibly is a waste. If I make iCal the width of the screen without the drawer, the drawer will just pop out off the screen and I'll have to move the iCal window over just to see it, losing the left side in the process. This is annoying.
I want to maximize the width of iCal so I can read more on the calendar. I can't do that if I need to leave space for a drawer to pop out.
Now, you could make an argument that having the detachable window is better for screen 'real estate' as you can leave just a little piece of it visible, behind the iCal main window, and click it to bring it forward.
IMO, the popup window is much better because now I don't have to resize or move the iCal window whenI want to see the info. By the way, you can pop up and close it with Command-I, which is a lot easier than mousing over to a visible piece of it.
Unless you have the horizontal space to pop out the drawer without it going offscreen, I think detachable window is easier to use. But you're right, we're entitled to our own opinions.