First, internet data is generally transfered in electrons or photons, which are (or at least can be) more numerous than atoms.
Even if there weren't so many it still wouldn't be a problem since there is no rule saying an atom (or electron or photon) can only represet one bit per second.
Well, we have the better part of a full size continent. Most Europeans can take day or weekend trips to foreign countries. Few Americans can, and those who can only have the options of Canada (more of the same) or Mexico (and the accessible parts are only really of interest to college kids).
For example I live in Colorado. It is a day and a half each way to each of Mexico and Canada, neither of which is very appealing to me.
We also don't have the kind of mass transit infrastructure that Europe has. I can't reasonably hop a train to Mexico.
A more equitable comparison would be "How many Americans have been to a 'foreign' state." I don't know any who haven't.
Let me clarify a bit. Certainly graphic design is an art, and graphic designers are artists (for better or worse).
My rant was really about web designers who are more interested in making their site look "cool" (which usually looks lame to me) than in generating actual HTML. The ultimate point is that a site is beautiful in theory (and/or IE), but is not written in actual HTML is generally useless, and (internal corporate) websites are about information not beauty.
Beyond this is the fact that so many "web designers" are frustrated wanna-be artists who think that their site is a work of art, and that the media is the message. I've got news; the message is the fucking message**. I don't give a shit that you graduated top of your class in graphics design at Shitheel Technical College, I actually want to know what the number to HR is, or what's for lunch in the cafeteria or how to change my 401k. Get over yourself and give my browser the INFORMATION (That is what the "I" in "IT" stands for!) in a format that my browser, whatever it is, has a fighting chance of parsing and presenting to me however I damn well please. If I want to use FooBrowser2000 on a black & White monitor at 320x240 with a gigantic font that ain't your fucking problem, Monet.
I didn't mean that being and artist and being a web designer are mutually exclusive, just that they are orthogonal.
As I understand it ISO standards have to be unencumbered by IP restrictions. They give an opportunity for IP claims to be made before the standard is finalized.
So, as it stands the process failed. Doing nothing will simply turn the process into a sham. Pulling the standard will show that they are serious about the process and that when it goes wrong they are prepared to act.
That's not to say that I think they should pull it on the spot (Of course, standards bodies don't to anything on the spot!), but now is the time to start the process so that they are ready to act when and if the time becomes ripe.
You seem to be unaware that there are two common meanings of the word "standard" in the computer industry.
You seem to be operating under the more general definition, which is often phrased as "de facto standard" meaning "standard from the fact.".doc and SMB are this type of "standard."
The other, more strict, usage is a formal standard published by a standards body. HTML 4.0 and JPEG are this type of "standard." (In addition to being the other kind.)
ISO is a standards body, and can most certainly retract a standard that they published in the first place.
Now, as to your qalitative analysis of ISO (and by implication, other standards bodies) I have to disagree with your assessment. I think that technical merit, to included social/legal difficulties with implementation, is exactly what ISO and friends should be doing. Getting behind the de facto "standard" of the month without regard to technical merit would be a total waste of time.
Furthermore, I think you belittle their true contribution when you intimate that they are only a "cheerleading group." Interoperation doesn't happen by magic. Without a published standard JPEG wouldn't be so universally interoperable (witness.doc).
God damnit. Why did you have to bring that up? I always manage to go blind and deaf for a moment during that scene.
I don't really mind the new release of the classic trillogy. I really liked EPII. EPI is looking better to me as more context surfaces.
But the Greedo thing really pisses me off. Comeon, a bounty hunter that shoots worse than Stormtroopers? Han just sits there and lets Greedo get the first shot? What a load.
Two of my favorite Free utilities are Simon Tatham's putty and pscp. Both are Windows only, and can be built with non-Free tools, but can also be built with Free tools.
I'm not even monomaniacal about that. I used to use WinPT (Windows Privacy Tray) (a Free utility that makes Windows GnuPG more PGP-like) which, AFAIK, can only be built with MSVC.
Allow me to rephrase a bit and say that Free Software that requires non-Free tools is not generally accepted. Do a bit of research on freshmeat.net or SF.net if you disagree with me. I think you'll find that the facts are on my side.
As to the charge of elitism, I don't see how acting in a way that is in line with one's own philosophy can be elitist. If it is then I'd rather be an elitist than a hypocrite. Is a vegetarian who finds a cheese burger unacceptable for lunch being elitist?
If you still disagree with me feel free to offer your help to some Free Software projects, but only on the condition that you can write modules in VB, and see what kind of reception you get. Again, I'm sure you can find a few examples of projects where this will fly, but for every one you find I can find 20 that find that find it unacceptable.
It is unacceptable because the toolchain is not Free, and the software would be useless on a Free System.
You could certainly distribute a VB program under Free Software terms, and it would be Free Software, but very few "Free Software people" would find this acceptable.
So, you don't know how to program, or you only know how to program in languages that are unacceptable for Free Software (such as VB), but you want to contribute. No problem!
1. Pick a project that you care about in some way. You will almost certainly lose interest in contributing to software that you don't use regularly.
2. Subscribe to the mailing list. Keep up with how the project is progressing, and what things are holding it back. Lurk for a while. (If the project does not have a mailing list, contact the project lead and coordinate setting up an SF.net account and getting one going.)
Some examples of how a non-programmer can help:
If you are and admin type you can help new users of the package. Helping new users is probably the number one thing a non-programmer can do for a project.
You could bring existing documentation up to date (see why you needed to lurk?).
You could convert existing docs to "better" formats.
You could do some other non- or semi-technical work, such as bringing a web app's HTML output into compliance with a W3C recommendation.
4. Make your presence known. Volunteer in some concrete way. Don't say "I'd love to help" say "I have six new FAQ entries, where should I send them?"
5. ???
6. Profit (just kidding).
Following these easy steps I (briefly) became the project lead of a package that was featured in this month's Sys Admin Magazine, without ever writing a single line of code.
Gandalf did tell the hobbits that all was not well in the Shire, but told them they'd have to handle it themselves. That's actually one of my favorite parts of the book. I love how amused the four hobbits are at the way they are expected to be cowed by all the rules and raggedy men.
Anyway, you are correct that the situation is that the shire is in trouble, and that the hobbits are going to have to handle it themselves, but the reason is that Gandalf is on a schedule and knows that the hobbits can handle a few ruffians.
For once I have to agree with AC. That is Butterbur. Which makes sense, even out of context since 1. "one thing drives out another" is a Butterburism 2. he has a place that the hobbits can oftener come back to (it is well established that Gandalf is a wanderer and has no physical home) and 3. even if he did have a home, he is acutely aware that he is about to un-ass Middle-Earth anyway, and won't be available for hobbit callers.
What Gandalf actually says on the topic (in part) is:
'But if you would know, I [Gandalf] am turning aside soon. I am going to have a long talk with Bombadil[. ..].'
In a little while they came to the point on the East Road where they had taken leave of Bombadil; and they hoped and half expected to see him standing there to greet them as they went by. But there was no sign of him; and there was a grey mist on the Barrow-downs southwards, and a deep veil over the Old Forest far away. [. ..] He [Gandalf] turned Shadowfax off the Road, and the great horse leaped the green dike that here ran beside it; and then at a cry from Gandalf he was gone, racing towards the Barrow-downs like a wind from the North.
You will recall that Bombadil makes his home at the edge of the Old Forest, adjacent to the Barrow-downs.
The following is clear to me.
Gandalf had a good idea what was going on in the Shire.
Gandalf had a good idea that the hobbits could handle it.
Gandalf knew it was his last (and in a way, first) chance to speak with Bombadil, which would be a rare treat for a Wizard of his caliber.
Gandalf knew that he would have a chance to give his friends a proper farewell at The Grey Havens.
-Peter
PS: Since you seem to have lost your focus at the end of the book, you may also be surprised when I tell you that Gandalf was in possesion of the third Elven Ring of Power (Narya the Great, the Ring of Fire) through the entire story, and is wearing it openly as he tells his friends "Go in peace! I will not say: do not weep; for not all tears are an evil." This is an important fact, as it sheds light on the mystery of how he survived individual combat with a (or "the" in the Third Age) Balrog, a fire daemon.
I don't have RotK in front of me, but I distinctly remember Gandalf saying something about going to talk things over with Bombadil now that the war is over, being his last chance, since Gandalf is returning to the West.
I took the statement that the hobbits would have to deal with what they found in the shire on their own to be more for the reader's benefit. To let us know that Gandalf knew what was up and to explain that he wouldn't be swooping in to the rescue.
Dude, Captain Typho as Ugluk and Chuckie (from Child's Play) as Wormtounge. That's gonna be cool.
Oh, and Sam's real daughter playing his daughter.
-Peter
PS: Like others, I'm pissed about the lack of Bombadil. Here's a question, how is Jackson going to get rid of Gandalf so that the Hobbits have to deal with "The Scouring of the Shire" on their own . . . ?
I forsee a potential abuses for this though. Annoying "spam bots" could learn to decipher the first automatic reply containing the code and then automatically send the spam, and contain the code which will allow the mail server to recieve the mail.
One of the primary charactaristics of SPAM is bogus From: and Reply-To: headers. If replies were actually recieved by the bot it would be an improvement.
At the risk of making this the thread that never ends . . .
My comments were geared more towards testing and supporting a particular browser, though, not towards writing for a particular browser.
Well, I don't know how to be any clearer that I don't want you to guess what browser I am using and test against it.
We certainly have a number of people that do know how to write clean code, and how to build applications that output clean, validator-friendly code, but generally these guys are in positions a little more advanced than a typical web monkey.
This is a management issue. Like I said, 30 pages. Those Sr. guys should be spot-checking the grunt's work. People will work up (or down) to expectations.
You have a legitimate gripe, but it's against your company, not the web designers.
What can you possibly mean by this. I have a gripe with the board of directors? It is ultimately "management's" fault, particularly the manager of the web designers. But to some extent it is the web designers fault. The ultimate responsibility falls to the technical level to make sure things work. Their manager was probably only vaguely aware that something other than IE exists. It is up to technical folks to inform management.
I think you should petition your higher-ups to spend the extra money to train your developers to learn how to standardize their HTML output, purchase better authoring tools that generate clean HTML output, and get more testing time against your sites to ensure everything validates cleanly and appears as expected in your web browser. What do you think they will say to that?
I don't work there anymore (laid off) so they'd probably say "Leave the property or we will call the police.";-)
In the real world, your bottom-rung "web authors" do not have an exceptionally high degree of training, which is pretty much what you say in the next paragraph. I'm not saying this is good, but it's the real world.
Get out of here. The entire XHTML spec is 30 pages long (in PDF). If you can't digest 30 pages of material in a week or two you have no place in this business.
If you are in technical management and you keep someone like this in your org for more than a month you need drug out and flogged.
HTML validation problems aren't nearly as severe as warnings pointing out a potentially serious vulnerability in code. You are unlikely to find exploitable buffer overflows in HTML.
Woah! Exploitable bugs are a miniscule portion of the bugs out there (and are unlikely to throw warnings besides). I know they get all the ink, but let's be for real.
I'm just talking about quality, and how disturbing I find it that "our current dot version of IE" is the gold standard of HTML quality in corporate America. Disturbing on several levels.
I was trying to point out that even standards-compliant code may not render as you expect.
Ah Ha! Now we've hit upon something. The problem, clearly stated is that web sites and web browsers both approximate the specifications to widely varying degrees. This causes a less than ideal coincidence of interoperability.
There are two general approaches to resolving this problem. First, pick two (or maybe more) particular release versions of particular browsers. Write some gross approximation of HTML (or "better yet," let FrontPage do it for you) then make ad hoc changes until it happens to mostly work in both (or all) the selected browsers. Second, write actual HTML, then resolve any issues with your selected browsers by eliminating problematic elements.
The first creates an unmaintainable mess of javascript browser detection routines and hacks that are sure to break in the next few point releases of you pet browser. It also reflects a defeatist attitude about browser standard support, which I believe to be self-fulfilling.
The second attempts to add to the harmony between web sites and browsers. The only actual disadvantage of this approach is that it doesn't give web designers the opportunity to masturbate to DHTML menus.
The real point, however, is that you can only positively influence the situation by 1. writing (and encouraging others to write) valid HTML and 2. reporting failures to properly render valid HTML to browser vendors.
Key to this is the fact that I believe that this can be done not only without additional expense, but at a development savings long term. (Yes, "long term," that magical phrase that sounds like silence to a manager's ears.)
To illustrate. Before the UNIX consultant gig I've been talking about I worked as a phone drone at Dell. Dell took exactly your attitude towards web development. When IE4 was released we were forbidden to install/run it (but were expected to support it, which was fun). They worked and worked on the site, which had been designed around IE3's quirks. It seems that IE4 has a completely separate set of incompatible quirks. Finally, because of Dell's "special" relationship with MS we had to start moving workstations over to Win98 which includes IE4. What a fiasco.
Things really haven't changed that much since then. The fact is that if you use "advanced browser features" you end up locked into a browser brand and version. Who wants to be in that pickle? Or, if you'd like, who wants to go to the CFO to explain that the web devel budget needs to be doubled for the next three quarters so that the crufty IE8 site can be refactored into a crufty IE9 site?
I guess the same guy who in the late seventies wanted to go to the CFO and explain that only IBM peripherals would work with that spiffy new IBM mainframe, and cost 230% of what everybody else's peripherals cost.
we have a very extensive lab that we use to verify that public-facing sites function with a diverse set of browsers. I don't make the decisions as to how that testing occurs, be it with an HTML validation tool or other forms of software and human testing.
Who is talking about your "public-facing" pages? Not me.
We seem to be hung up on testing and validation. Think debugging vs. compiler errors and warnings.* Somehow it became okay for "web designers" to pass off code that isn't HTML as HTML. How did that happen? I guess the same way it almost became okay to pass off non-Java that works with J++ as Java . ..
So, yes, my opinion is that web sites, even internal ones, should be based on actual, valid (and by implication validated), HTML.
also can't believe you'd advocate two to three times the testing and extend development times simply to support non-standard browsers that make up a stubborn 0.01% of employees that might use them. This does not make good business sense. Coding to standards is only part of this picture.
Are you trolling me or what? I specifically said that I don't expect you to guess what browser I am using and test against it. My suggestion, in fact, was to do more (some) validation followed by less testing. In fact, I'd wager that the over all testing cycle would be shorter if you started by validating your HTML.
In an ideal world, all code would adhere strictly to standards, and all browsers would render those standard-compliant documents perfectly. This is not an ideal world, and development time and testing cost money. While I personally (like you, I believe) do not feel this should be neglected on web sites that have a non-specific intended audience (e.g. public-facing Internet sites), I see no reason to not apply only a subset of these development and testing measures when you have a very specific target audience. This in no way reduces the expectations of public-facing code, and simply allows us to reduce development and testing times (which cost money!) for internal sites.
You clearly didn't comprehend my previous posts. Allow me to spell it out a little more clearly.
I worked at a company who's internal website was unusable in any browser except IE. (It was the same story for the corp email.) Running UNIX was a job requirement for my position. The company gave me 1 PC. I had neither the time nor the disk space to dual boot. They wouldn't buy me a VMWare license.
You tell me how to reconcile all of the above without buying another PC (or VMWare) out of my own pocket.
Explain to me how it makes business sense to go out of your way to write a web site to a specific browser, to the exclusion of all others, when you have employees who cannot run that browser.
Perhaps we'll just have to agree to disagree here Sometimes the needs of the business outweigh technical wants. Even though I am one of the biggest supporters of W3C standards and validation in the web group at my company, I nevertheless recognize that there are overriding business needs to take into account here as well.
I'm not prepared to agree to disagree based on that premise.
The fact is that writing actual HTML is no harder than writing non-HTML (at least for someone who legitimately claims to be able to write HTML), and it is considerably easier to debug. The fact is that anyone who claims to be writing HTML and isn't is a twit at best and a charlatan at worst.
The reality is that people are promoted to their level of incompetence and web designers are generally at that level. Most have no understanding of the technology that is their "area of expertise" and are just GUI monkeys that can drag shapes together to make flash animations and follow "Dummies" books to make barely-working sites that are "cool" because the menus expand when you hover over them (in IE, it crashes NS4.x (which is a separate rant), and causes newer browsers to be unable to render the page due, at lest in part, to undefined use of HTML tags).
The bottom line is that most IT employees suck at their jobs, and most IT services hover around the line of total uselessness due to incompetent design and administration.
-Peter
* God this pisses me off. In my mind this is analogus to saying "Our C program throws a gazillion warnings, but it compiles with the particular sub-version of the compiler we are using at the moment and it seems to work with the test data. Any more testing would be a waste of money. Fuck it; were shipping it."
Beyond this is the fact that so many "web designers" are frustrated wanna-be artists who think that their site is a work of art, and that the media is the message. I've got news; the message is the fucking message**. I don't give a shit that you graduated top of your class in graphics design at Shitheel Technical College, I actually want to know what the number to HR is, or what's for lunch in the cafeteria or how to change my 401k. Get over yourself and give my browser the INFORMATION (That is what the "I" in "IT" stands for!) in a format that my browser, whatever it is, has a fighting chance of parsing and presenting to me however I damn well please. If I want to use FooBrowser2000 on a black & White monitor at 320x240 with a gigantic font that ain't your fucking problem, Monet.
Well, as often is the case, the debate has become one of semantics.
If your "XHTML" isn't valid it isn't XHTML, is it? If you are testing (as opposed to validating) with an out-of-compliance browser you don't even really know if you are writing XHMTL, do you?
And, as I said, I don't expect "you" to make any special allowances for my browser, and I certainly don't expect you to test against it. But if you don't write some form of valid HTML I can't even write a useful bug report for my browser vendor.
That makes you part of the problem. Internal site or no.
Slashdot Mirror
This is no problem.
First, internet data is generally transfered in electrons or photons, which are (or at least can be) more numerous than atoms.
Even if there weren't so many it still wouldn't be a problem since there is no rule saying an atom (or electron or photon) can only represet one bit per second.
-Peter
The story also says he was convicted of "selling unauthorized computer equipment" whatever the fuck that means.
-Peter
Well, we have the better part of a full size continent. Most Europeans can take day or weekend trips to foreign countries. Few Americans can, and those who can only have the options of Canada (more of the same) or Mexico (and the accessible parts are only really of interest to college kids).
For example I live in Colorado. It is a day and a half each way to each of Mexico and Canada, neither of which is very appealing to me.
We also don't have the kind of mass transit infrastructure that Europe has. I can't reasonably hop a train to Mexico.
A more equitable comparison would be "How many Americans have been to a 'foreign' state." I don't know any who haven't.
-Peter
I take your points.
Let me clarify a bit. Certainly graphic design is an art, and graphic designers are artists (for better or worse).
My rant was really about web designers who are more interested in making their site look "cool" (which usually looks lame to me) than in generating actual HTML. The ultimate point is that a site is beautiful in theory (and/or IE), but is not written in actual HTML is generally useless, and (internal corporate) websites are about information not beauty.
-Peter
-Peter
As I understand it ISO standards have to be unencumbered by IP restrictions. They give an opportunity for IP claims to be made before the standard is finalized.
So, as it stands the process failed. Doing nothing will simply turn the process into a sham. Pulling the standard will show that they are serious about the process and that when it goes wrong they are prepared to act.
That's not to say that I think they should pull it on the spot (Of course, standards bodies don't to anything on the spot!), but now is the time to start the process so that they are ready to act when and if the time becomes ripe.
-Peter
You seem to be unaware that there are two common meanings of the word "standard" in the computer industry.
.doc and SMB are this type of "standard."
.doc).
You seem to be operating under the more general definition, which is often phrased as "de facto standard" meaning "standard from the fact."
The other, more strict, usage is a formal standard published by a standards body. HTML 4.0 and JPEG are this type of "standard." (In addition to being the other kind.)
ISO is a standards body, and can most certainly retract a standard that they published in the first place.
Now, as to your qalitative analysis of ISO (and by implication, other standards bodies) I have to disagree with your assessment. I think that technical merit, to included social/legal difficulties with implementation, is exactly what ISO and friends should be doing. Getting behind the de facto "standard" of the month without regard to technical merit would be a total waste of time.
Furthermore, I think you belittle their true contribution when you intimate that they are only a "cheerleading group." Interoperation doesn't happen by magic. Without a published standard JPEG wouldn't be so universally interoperable (witness
-Peter
Consider reading the article. Taco drew a conclusion that is not supported by the article.
The article isn't about SPAM at all. It boils down to the fact that people you CC: are unlikely to answer questions in the message.
This would generalize more to mailing lists and news groups than SPAM.
-Peter
I guess our difference of opinion revolves around the cause of a minuscule portion of Free Software being written using non-free tools.
I think that it is because most Free Software folks find such tools unacceptable.
It seems that you think that this is some sort of coincidence.
-Peter
God damnit. Why did you have to bring that up? I always manage to go blind and deaf for a moment during that scene.
I don't really mind the new release of the classic trillogy. I really liked EPII. EPI is looking better to me as more context surfaces.
But the Greedo thing really pisses me off. Comeon, a bounty hunter that shoots worse than Stormtroopers? Han just sits there and lets Greedo get the first shot? What a load.
-Peter
That is not my opinion at all.
Two of my favorite Free utilities are Simon Tatham's putty and pscp. Both are Windows only, and can be built with non-Free tools, but can also be built with Free tools.
I'm not even monomaniacal about that. I used to use WinPT (Windows Privacy Tray) (a Free utility that makes Windows GnuPG more PGP-like) which, AFAIK, can only be built with MSVC.
Allow me to rephrase a bit and say that Free Software that requires non-Free tools is not generally accepted. Do a bit of research on freshmeat.net or SF.net if you disagree with me. I think you'll find that the facts are on my side.
As to the charge of elitism, I don't see how acting in a way that is in line with one's own philosophy can be elitist. If it is then I'd rather be an elitist than a hypocrite. Is a vegetarian who finds a cheese burger unacceptable for lunch being elitist?
If you still disagree with me feel free to offer your help to some Free Software projects, but only on the condition that you can write modules in VB, and see what kind of reception you get. Again, I'm sure you can find a few examples of projects where this will fly, but for every one you find I can find 20 that find that find it unacceptable.
-Peter
It is unacceptable because the toolchain is not Free, and the software would be useless on a Free System.
You could certainly distribute a VB program under Free Software terms, and it would be Free Software, but very few "Free Software people" would find this acceptable.
-Peter
So, you don't know how to program, or you only know how to program in languages that are unacceptable for Free Software (such as VB), but you want to contribute. No problem!
1. Pick a project that you care about in some way. You will almost certainly lose interest in contributing to software that you don't use regularly.
2. Subscribe to the mailing list. Keep up with how the project is progressing, and what things are holding it back. Lurk for a while. (If the project does not have a mailing list, contact the project lead and coordinate setting up an SF.net account and getting one going.)
Some examples of how a non-programmer can help:
- If you are and admin type you can help new users of the package. Helping new users is probably the number one thing a non-programmer can do for a project.
- You could bring existing documentation up to date (see why you needed to lurk?).
- You could convert existing docs to "better" formats.
- You could do some other non- or semi-technical work, such as bringing a web app's HTML output into compliance with a W3C recommendation.
4. Make your presence known. Volunteer in some concrete way. Don't say "I'd love to help" say "I have six new FAQ entries, where should I send them?"5. ???
6. Profit (just kidding).
Following these easy steps I (briefly) became the project lead of a package that was featured in this month's Sys Admin Magazine, without ever writing a single line of code.
-Peter
that's a good question now
;-)
Well, I think it was a good question then too
Gandalf did tell the hobbits that all was not well in the Shire, but told them they'd have to handle it themselves. That's actually one of my favorite parts of the book. I love how amused the four hobbits are at the way they are expected to be cowed by all the rules and raggedy men.
Anyway, you are correct that the situation is that the shire is in trouble, and that the hobbits are going to have to handle it themselves, but the reason is that Gandalf is on a schedule and knows that the hobbits can handle a few ruffians.
-Peter
What Gandalf actually says on the topic (in part) is: You will recall that Bombadil makes his home at the edge of the Old Forest, adjacent to the Barrow-downs.
The following is clear to me.
- Gandalf had a good idea what was going on in the Shire.
- Gandalf had a good idea that the hobbits could handle it.
- Gandalf knew it was his last (and in a way, first) chance to speak with Bombadil, which would be a rare treat for a Wizard of his caliber.
- Gandalf knew that he would have a chance to give his friends a proper farewell at The Grey Havens.
-PeterPS: Since you seem to have lost your focus at the end of the book, you may also be surprised when I tell you that Gandalf was in possesion of the third Elven Ring of Power (Narya the Great, the Ring of Fire) through the entire story, and is wearing it openly as he tells his friends "Go in peace! I will not say: do not weep; for not all tears are an evil." This is an important fact, as it sheds light on the mystery of how he survived individual combat with a (or "the" in the Third Age) Balrog, a fire daemon.
-P
Your sig is out of date. Numeric Karma is dead, man.
-Peter
I don't have RotK in front of me, but I distinctly remember Gandalf saying something about going to talk things over with Bombadil now that the war is over, being his last chance, since Gandalf is returning to the West.
I took the statement that the hobbits would have to deal with what they found in the shire on their own to be more for the reader's benefit. To let us know that Gandalf knew what was up and to explain that he wouldn't be swooping in to the rescue.
-Peter
Dude, Captain Typho as Ugluk and Chuckie (from Child's Play) as Wormtounge. That's gonna be cool.
Oh, and Sam's real daughter playing his daughter.
-Peter
PS: Like others, I'm pissed about the lack of Bombadil. Here's a question, how is Jackson going to get rid of Gandalf so that the Hobbits have to deal with "The Scouring of the Shire" on their own . . . ?
-P
Damn, you got me. Good call.
-Peter
-Peter
Dell's internal employee page has (or at least had) the entire Enterprise D command staff, complete with (very low) badge numbers.
The "supervisor" and "co-workers" links even worked. If you clicked on LaForge's supervisor you got Picard's entry.
-Peter
-Peter
If you are in technical management and you keep someone like this in your org for more than a month you need drug out and flogged. Woah! Exploitable bugs are a miniscule portion of the bugs out there (and are unlikely to throw warnings besides). I know they get all the ink, but let's be for real.
I'm just talking about quality, and how disturbing I find it that "our current dot version of IE" is the gold standard of HTML quality in corporate America. Disturbing on several levels. Ah Ha! Now we've hit upon something. The problem, clearly stated is that web sites and web browsers both approximate the specifications to widely varying degrees. This causes a less than ideal coincidence of interoperability.
There are two general approaches to resolving this problem. First, pick two (or maybe more) particular release versions of particular browsers. Write some gross approximation of HTML (or "better yet," let FrontPage do it for you) then make ad hoc changes until it happens to mostly work in both (or all) the selected browsers. Second, write actual HTML, then resolve any issues with your selected browsers by eliminating problematic elements.
The first creates an unmaintainable mess of javascript browser detection routines and hacks that are sure to break in the next few point releases of you pet browser. It also reflects a defeatist attitude about browser standard support, which I believe to be self-fulfilling.
The second attempts to add to the harmony between web sites and browsers. The only actual disadvantage of this approach is that it doesn't give web designers the opportunity to masturbate to DHTML menus.
The real point, however, is that you can only positively influence the situation by 1. writing (and encouraging others to write) valid HTML and 2. reporting failures to properly render valid HTML to browser vendors.
Key to this is the fact that I believe that this can be done not only without additional expense, but at a development savings long term. (Yes, "long term," that magical phrase that sounds like silence to a manager's ears.)
To illustrate. Before the UNIX consultant gig I've been talking about I worked as a phone drone at Dell. Dell took exactly your attitude towards web development. When IE4 was released we were forbidden to install/run it (but were expected to support it, which was fun). They worked and worked on the site, which had been designed around IE3's quirks. It seems that IE4 has a completely separate set of incompatible quirks. Finally, because of Dell's "special" relationship with MS we had to start moving workstations over to Win98 which includes IE4. What a fiasco.
Things really haven't changed that much since then. The fact is that if you use "advanced browser features" you end up locked into a browser brand and version. Who wants to be in that pickle? Or, if you'd like, who wants to go to the CFO to explain that the web devel budget needs to be doubled for the next three quarters so that the crufty IE8 site can be refactored into a crufty IE9 site?
I guess the same guy who in the late seventies wanted to go to the CFO and explain that only IBM peripherals would work with that spiffy new IBM mainframe, and cost 230% of what everybody else's peripherals cost.
-Peter
We seem to be hung up on testing and validation. Think debugging vs. compiler errors and warnings.* Somehow it became okay for "web designers" to pass off code that isn't HTML as HTML. How did that happen? I guess the same way it almost became okay to pass off non-Java that works with J++ as Java . .
So, yes, my opinion is that web sites, even internal ones, should be based on actual, valid (and by implication validated), HTML. Are you trolling me or what? I specifically said that I don't expect you to guess what browser I am using and test against it. My suggestion, in fact, was to do more (some) validation followed by less testing. In fact, I'd wager that the over all testing cycle would be shorter if you started by validating your HTML. You clearly didn't comprehend my previous posts. Allow me to spell it out a little more clearly.
I worked at a company who's internal website was unusable in any browser except IE. (It was the same story for the corp email.) Running UNIX was a job requirement for my position. The company gave me 1 PC. I had neither the time nor the disk space to dual boot. They wouldn't buy me a VMWare license.
You tell me how to reconcile all of the above without buying another PC (or VMWare) out of my own pocket.
Explain to me how it makes business sense to go out of your way to write a web site to a specific browser, to the exclusion of all others, when you have employees who cannot run that browser. I'm not prepared to agree to disagree based on that premise.
The fact is that writing actual HTML is no harder than writing non-HTML (at least for someone who legitimately claims to be able to write HTML), and it is considerably easier to debug. The fact is that anyone who claims to be writing HTML and isn't is a twit at best and a charlatan at worst.
The reality is that people are promoted to their level of incompetence and web designers are generally at that level. Most have no understanding of the technology that is their "area of expertise" and are just GUI monkeys that can drag shapes together to make flash animations and follow "Dummies" books to make barely-working sites that are "cool" because the menus expand when you hover over them (in IE, it crashes NS4.x (which is a separate rant), and causes newer browsers to be unable to render the page due, at lest in part, to undefined use of HTML tags).
The bottom line is that most IT employees suck at their jobs, and most IT services hover around the line of total uselessness due to incompetent design and administration.
-Peter
* God this pisses me off. In my mind this is analogus to saying "Our C program throws a gazillion warnings, but it compiles with the particular sub-version of the compiler we are using at the moment and it seems to work with the test data. Any more testing would be a waste of money. Fuck it; were shipping it."
Beyond this is the fact that so many "web designers" are frustrated wanna-be artists who think that their site is a work of art, and that the media is the message. I've got news; the message is the fucking message**. I don't give a shit that you graduated top of your class in graphics design at Shitheel Technical College, I actually want to know what the number to HR is, or what's for lunch in the cafeteria or how to change my 401k. Get over yourself and give my browser the INFORMATION (That is what the "I" in "IT" stands for!) in a format that my browser, whatever it is, has a fighting chance of parsing and presenting to me however I damn well please. If I want to use FooBrowser2000 on a black & White monitor at 320x240 with a gigantic font that ain't your fucking problem, Monet.
-P
** I think I have a new sig!
Well, as often is the case, the debate has become one of semantics.
If your "XHTML" isn't valid it isn't XHTML, is it? If you are testing (as opposed to validating) with an out-of-compliance browser you don't even really know if you are writing XHMTL, do you?
And, as I said, I don't expect "you" to make any special allowances for my browser, and I certainly don't expect you to test against it. But if you don't write some form of valid HTML I can't even write a useful bug report for my browser vendor.
That makes you part of the problem. Internal site or no.
-Peter