Wikipedia has the opportunity to be both free and more accurate than any printed work.
...and the potential to be less accurate too. This is what The Register is arguing.
When he came across it, fix it, move on. Hes actually created a much larger problem by bringing so much attention to this.
Yes, but as The Register has also pointed out: he changes it to be accurate. There's nothing to stop someone else changing it back. Should he be reviewing this article continuously to stop this happening?
The great "freedom" benefit is also a weakness. Not for everything but the opportunity is there for this stuff to occur. The only problem the attention is causing is to suggest Wiki is beyond criticism. The Register is arguing it isn't - but no more zealously than many of the comments on/. After all - to reuse an argument here - anyone reading The Register won't take it as a single authoritative voice. You can't have this both ways...
Well, the MMM (Fred Brookes' Mythical Man Month) could have been condensed into a blog entry with little loss of value
Except, and here's why I largely disagree with you, MMM was written 30 years ago. This is pre-more or less everything that has a trendy buzzword now. And MMM holds up today.
MMM could be condensed to be something like: The difficulties of developing software are non-linear based on size. Software development is hard. Projects slip one day at a time. More people means more communication paths, which will likely slow your project further rather than dig it out of trouble.
You could probably write your own better summary. But the point is, people still do not get this. Late project? Add more people! MMM is important because there are developers now making the same mistake with software development that were identified before they were born.
We may have notionally better languages for development and better tools but the constant is the human element's ability to foul things up.
This isn't a rant as I also agree with you in part: anyone throwing around MMM (or whatever) should have read it.
As mentioned elsewhere you can probably Google your way out of trouble to get ADO.net to work (or whatever) but it's harder to Google "how will I make sure my project doesn't needless repeat mistake that other people could effortless predict".
I'm a big fan of MMM by the way, should I mention this?
You can keep your windows editors... wait, how many of them are there? Notepad and wordpad? At least I've got a nice selection with just a basic Linux install.
Not trolling but this works both ways. Install Windows, need to use an editor, so use one. Rather than evaluate which one of X editors I'd prefer to use.
Just to demonstrate why a lack of choice might be a good thing, which is better: vi or emacs?
Granted, but given the transcoding is happening on the server surely the only reason forward/backwards isn't there is because it's not implemented.
As the unit itself is getting a stream it could get a forward or reversed stream from the server. Although there's caching it could at least - from the server - implement 5 seconds skips (or whatever).
Not that this is too serious a discussion but essentially the complaint that there's no OGG support is a little redundant given that it will play OGG files. May be not natively (with the extra functionality implied) but it's not like there are hundreds of fully OGG compliant alternatives.
In short it's a fantastic device (at least my v1 wired SlimServer is awesome), it's open, it's multi-codec and it's OGG limitation is still better than many other devices.
Hey, SlimServer is open source. If it doesn't do what you want, you've got the code...
(I know, OGG is supported by transcoding on the server but I like being facetious.)
You can't blame the user. It's not Joe-Sixpack. He doesn't want an application that does everything. He probably doesn't even know what he wants.
It's IT that sells him stuff using basically the justification "look, shiny!". IT as an industry over-promises - keep the punters interested - but underdelivers.
Business customers want IT to run their business. If they want anything else it's because they're being sold it. Joe-Sixpack probably won't need version two of any desktop application for new features. He'll only need it because the first won't work.
Isn't this just a recognition that security issues are here to stay. At least MS is doing something about it.
http://www.theregister.co.uk/2005/12/01/secfoc_mac os/Other OSes aren't immunue [TheRegister.co.uk] Malicious code can originate and run on anything. Just because you're not root doesn't make you safe, surely?
Anyway, doesn't this also address malicious applications that can arrive via third-party software. (MS isn't responsible for everything? Yes, I must be new here, etc.)
It's pointless writing "good" comments on bad code. Write clear obvious code that doesn't rely on needless tricks or language side-effects.
Layout is important but don't get obessive. You'd write prose using paragraphs, use whitespace in code.
Good comments are hard because, like code, bad comments are very easy. Don't describe what's obvious from the code. Why is better than how. Don't spend ten lines describing a pattern when you can refer it by name.
Don't add redundant comments (and this is from someone who writes more than my peers). Twenty lines of boiler-plate for each method is pointless. If there's a need for a detailed change history then your source-control should provide this. If the code requires heavy detail try refactoring it to make the code clearer.
Simple metrics are difficult but look at your code without comments and imagine what'd be useful if your coming at it blind. What would you want to see? (Try this with a random sample of colleagues code. Typically - from experience - you won't have to spend too long removing comments because there won't be any.)
And the difficult bit: make sure you're in a culture that values comments and documentation. It's pointless crafting detail now if some future developer will ignore them or not maintain them.
Finally, none of this is exact. Everything about can be argued. Get some literature (McConnell, Brooks, etc.) and learn from this too. Use what the situation demands, don't apply things where they're not warranted.
Slashdot Mirror
Wikipedia has the opportunity to be both free and more accurate than any printed work.
...and the potential to be less accurate too. This is what The Register is arguing.
When he came across it, fix it, move on. Hes actually created a much larger problem by bringing so much attention to this.
Yes, but as The Register has also pointed out: he changes it to be accurate. There's nothing to stop someone else changing it back. Should he be reviewing this article continuously to stop this happening?
The great "freedom" benefit is also a weakness. Not for everything but the opportunity is there for this stuff to occur. The only problem the attention is causing is to suggest Wiki is beyond criticism. The Register is arguing it isn't - but no more zealously than many of the comments on /. After all - to reuse an argument here - anyone reading The Register won't take it as a single authoritative voice. You can't have this both ways...
Well, the MMM (Fred Brookes' Mythical Man Month) could have been condensed into a blog entry with little loss of value
Except, and here's why I largely disagree with you, MMM was written 30 years ago. This is pre-more or less everything that has a trendy buzzword now. And MMM holds up today.
MMM could be condensed to be something like: The difficulties of developing software are non-linear based on size. Software development is hard. Projects slip one day at a time. More people means more communication paths, which will likely slow your project further rather than dig it out of trouble.
You could probably write your own better summary. But the point is, people still do not get this. Late project? Add more people! MMM is important because there are developers now making the same mistake with software development that were identified before they were born.
We may have notionally better languages for development and better tools but the constant is the human element's ability to foul things up.
This isn't a rant as I also agree with you in part: anyone throwing around MMM (or whatever) should have read it.
As mentioned elsewhere you can probably Google your way out of trouble to get ADO.net to work (or whatever) but it's harder to Google "how will I make sure my project doesn't needless repeat mistake that other people could effortless predict".
I'm a big fan of MMM by the way, should I mention this?
You can keep your windows editors ... wait, how many of them are there? Notepad and wordpad? At least I've got a nice selection with just a basic Linux install.
Not trolling but this works both ways. Install Windows, need to use an editor, so use one. Rather than evaluate which one of X editors I'd prefer to use.
Just to demonstrate why a lack of choice might be a good thing, which is better: vi or emacs?
Surely the copyright violation going on in the first place is a bigger waste of packets?
Granted, but given the transcoding is happening on the server surely the only reason forward/backwards isn't there is because it's not implemented. As the unit itself is getting a stream it could get a forward or reversed stream from the server. Although there's caching it could at least - from the server - implement 5 seconds skips (or whatever). Not that this is too serious a discussion but essentially the complaint that there's no OGG support is a little redundant given that it will play OGG files. May be not natively (with the extra functionality implied) but it's not like there are hundreds of fully OGG compliant alternatives. In short it's a fantastic device (at least my v1 wired SlimServer is awesome), it's open, it's multi-codec and it's OGG limitation is still better than many other devices.
Hey, SlimServer is open source. If it doesn't do what you want, you've got the code... (I know, OGG is supported by transcoding on the server but I like being facetious.)
You can't blame the user. It's not Joe-Sixpack. He doesn't want an application that does everything. He probably doesn't even know what he wants.
It's IT that sells him stuff using basically the justification "look, shiny!". IT as an industry over-promises - keep the punters interested - but underdelivers.
Business customers want IT to run their business. If they want anything else it's because they're being sold it. Joe-Sixpack probably won't need version two of any desktop application for new features. He'll only need it because the first won't work.
Isn't this just a recognition that security issues are here to stay. At least MS is doing something about it. http://www.theregister.co.uk/2005/12/01/secfoc_mac os/Other OSes aren't immunue [TheRegister.co.uk] Malicious code can originate and run on anything. Just because you're not root doesn't make you safe, surely?
Anyway, doesn't this also address malicious applications that can arrive via third-party software. (MS isn't responsible for everything? Yes, I must be new here, etc.)
It's pointless writing "good" comments on bad code. Write clear obvious code that doesn't rely on needless tricks or language side-effects.
Layout is important but don't get obessive. You'd write prose using paragraphs, use whitespace in code.
Good comments are hard because, like code, bad comments are very easy. Don't describe what's obvious from the code. Why is better than how. Don't spend ten lines describing a pattern when you can refer it by name.
Don't add redundant comments (and this is from someone who writes more than my peers). Twenty lines of boiler-plate for each method is pointless. If there's a need for a detailed change history then your source-control should provide this. If the code requires heavy detail try refactoring it to make the code clearer.
Simple metrics are difficult but look at your code without comments and imagine what'd be useful if your coming at it blind. What would you want to see? (Try this with a random sample of colleagues code. Typically - from experience - you won't have to spend too long removing comments because there won't be any.)
And the difficult bit: make sure you're in a culture that values comments and documentation. It's pointless crafting detail now if some future developer will ignore them or not maintain them.
Finally, none of this is exact. Everything about can be argued. Get some literature (McConnell, Brooks, etc.) and learn from this too. Use what the situation demands, don't apply things where they're not warranted.