The doctor can no longer inform your parents when you'er over 16.
I would hope your parents wouldn't need informing when you're over 16. Forgetting your kid's birthday isn't going to win you any Parent Of The Year awards.
There is a chance that the next Trek movie will be great. I mean, consider the evidence...
Trek 1 - sucked Trek 2 - great Trek 3 - sucked Trek 4 - great Trek 5 - sucked Trek 6 - great Trek 7 - sucked Trek 8 - great Trek 9 - sucked
At this point, everyone is aware of the "evens are great, odds all suck" rule. But then...
Trek 10 - sucked
"WTF?!" comes the cry of astonishment. Well, re-examine the evidence and come up with a new theory:
Trek 10 sucked because ONE PLUS ZERO EQUALS ONE WHICH IS ODD. It's simple: it's the sum of the digits that matter. So Trek 11 will be great because ONE PLUS ONE IS TWO WHICH IS EVEN!
Back in 1996 or so when just about anybody with a text editor and a link to that excellent Netscape HTML manual could write a decent page without spending hours poring over obtuse documentation?
The W3C specs for XHTML, CSS and the DOM aren't obtuse - I understand them just fine. You're just not thinking about their target audiences. Joe Schmoe has about as much need to read the XHTML specs in order to write XHTML documents as he does to read the TCP/IP RFCs in order to set up a home network.
Joe Schmoe will instead read a beginners tutorial on the web, or buy "a dummies guide to XHTML", or (more likely) use a WYSIWYG tool.
The specifications are primarily for implementors, i.e. writers of browsers and parsers and other such tools, and secondly for those users that are advanced enough to want to read the actual spec.
The problem I've found with fully using XHTML+CSS for web pages is that it is not possible to layout pages that will scale accurately as the font size is increased.
That is possible. I suggest you stop using absolute units (pixels, points, etc) and have a look at relative units (for example ems). Then all your width/height/etc settings will be recalculated when the user changes their browser's font settings. 3em for "medium" font size is different from 3em for "small" font size, and so on.
At this stage, why bother with YAHTMLS (Yet Another HTML Standard) and why not just go straight to the full-blown XML standards?
Well, this isn't Yet Another HTML Standard - this is XHTML, which is HTML in an XML format. In that sense, we've already gone to "full-blown XML".
Alternatively, if you mean we should all make up our own XML-based languages and create whatever tags we want every time we create a website... that's a terrible idea. The strength of (X)HTML is that you/me/browsers/everyone knows that <h1> is a heading, and so on.
Imagine writing a script that extracts all the headings from a document, in order to create a table of contents. Simple when you know you're looking for <h1>, <h2>, etc., but exactly how would you go about it when the elements that represent headings can be different for each and every document, depending on whatever element names the author felt like using on that particular day?
why don't they fix CSS first and try doing something GOOD, like making the id and name attributes the same or both handled in CSS and javascript
The id and name attributes aren't meant to be the same. The name attribute is used for naming form controls, and (for example) this means that all radio buttons that are meant to be part of the same set all have the same name. Since the id attribute is meant to contain a unique identifier, making them the same would mean either [a] making it impossible to group radio buttons, since their names would need to be unique, or [b] making it impossible to grab an element by it's unique identifier, since ids can't be unique if you want to group radio buttons. Which would you prefer, exactly?
during the course of designing a website for a friend I tried several Java based transforms to go from XML to an XHTML page.
May I ask why? There are three situations I can imagine here:
You have a bunch of static XML files that you want to display in a browser as XHTML. In which case, write a script to transform the XML files into XHTML, and then put the XHTML files on your web server. Rerun the script when you change the XML. There is no need to be recreating your XHTML for every page request when the XML isn't changing!
You're grabbing data from e.g. a database and creating an XML file from it, and then transforming this to XHTML. Believe me, I've seen this done - just use the data to generate an XHTML file instead. There's no need to generate XML as an intermediary format when you can just as easily generate the final output you want anyway. Once again, if the data doesn't change frequently, consider just creating the XHTML files and storing them statically, recreating them when the data changes.
You're grabbing an XML file from a remote location (and therefore the format is out of your control) and using it to generate XHTML. In this case, you're pretty much out of luck - although, yep, you guessed it, consider creating the files only as necessary.
Another thing to bear in mind is that some browsers (Internet Explorer 6.0, Mozilla (I forget from which version)) can understand XSLT themselves. You could do some server-side browser detection and, if the client can support it, farm out the XSLT processing to them.
Moral of the story: if you don't need to do it, don't!
It's about time someone tried to circumvent the W3C.
Honestly, the timescales the W3C are working on now are a joke. CSS3 has been in development since 2000 and is still nowhere near completion. XHTML 2.0 has been in development since August 2002, has already suffered from having its mission statement rewritten without announcement, and is, frankly, a bit crap. They don't even make use of XLink, but instead decided to write their own linking specification from scratch.
In short, the W3C has become a dinosaur. It takes far too long for them to get around to do anything, and it seems riddled with political jostling between both its members and its different working groups.
I think it's time someone else took over. The W3C only really works because the public allows it to - after all, the W3C isn't an official standards body so it's "standards" aren't really standards anyway. If someone else can do a better job, I say let them.
I've had the unfortunate experience of attempting to generate XML using Microsoft's MSXML object. What a piece of crap! In an attempt to completely abstract the format, the objects are obfuscated beyond reason. Even the simplest things require ridiculous complexity: just to escape-out special characters requires instantiating a new "entity" element in the middle of the text string element.
Er... in that respect, Microsoft are following the standards, because that's how it's done with the W3C's Document Object Model. If you have a problem with it, you have a problem with the DOM, not with Microsoft.
But the worst part is that I *succeeded* in using MSXML. Now, if I wanted to go back to just writing a text file (which I do!), I can't -- my code is tangled up in the objects to the point that it would take a complete rewrite.
Again, that's your fault, not Microsofts. Either live with it, or split out the XML-generation code into a separate module. The world and his dog has long since learned to separate out logic code and database-access code so that it's possible to change DBMS by just rewriting the database-access module rather than the entire application - exactly the same thing applies with XML.
Actually, the human ear has no problem with "B". The problem is that the 12 frets, or the 12 steps of the chromatic scale, stand for multiple notes. Bb is not the same as A#, and even any one of those notes actually stands for several other slightly different notes that fit with different chords in different keys.
It's all about equal temperament not matching the notes one really wants to use. Good guitarrists compensate slightly by stretching strings just a bit, but it still can't match the flexibility of a well-played fretless instrument. The 12 chromatic steps are just a convenient lie to prevent the necessity of over 30 notes per octave.
If you can tell the difference between equal temperament and the "correct" temperament for the key you're playing in, then you've a better ear than me. There's only a very limited difference between the two (less than 1%, if memory serves).
Plus, equal temperament is a fricking godsend. Can you imagine having to retune a piano every time you needed to change key? Without equal temperament, every piece of piano music (and all other similarly-difficult-to-retune instruments) would pretty much have to pick a key and stay in it.
I'm not a Linux user, and have never been, and nor have I ever purchased any software or services from SCO. Thus, I consider myself pretty impartial when it comes to the ongoing SCO vs Linux case, but nonetheless I felt compelled to complain about the factual errors and, worse, outright assumptions presented as facts within this story.
Firstly, the story claims that it "seems likely" that the MyDoom worm is the work of an enraged Linux zealot. Personally, this seems highly unlikely - for a start, most Linux zealots that I know don't know anything about Windows, in the same way that most Windows users don't know anything about Linux. Thus the likelihood that a Linux zealot would have the know-how to write a sophisticated Windows-based worm (and let's not forget, this worm only affects Windows) seems rather unlikely.
Furthormore, the article bases this claim upon the fact that the worm targets the SCO website. Perhaps, but that seems to be far from the primary purpose of the worm. It also installs a backdoor on the victim's machine that allows it to be used as a spam relay. Since Linux zealots (and indeed, the vast majority of programmers in general) aren't fans of spam, it seems highly unlikely that such a backdoor would be desirable to the programmer.
Based on that alone, I find it far more likely that the worm is the work of spammers. It's well documented that spammers will stop at little to send their mail. Furthermore, the attack on the SCO website provides a sufficient red herring to divert attention from the spam backdoor - I consider it significant, for example, that the attack on SCO's webserver lasts only for a few days, whereas the backdoor remains there permanently until removed.
I further object to the implication that virus writers are "run of the mill geeks". Virus writers are far from run of the mill - if every computer geek (and I do count myself amongst this group, despite not being a Linux user) were to write and release viruses, then quite frankly the Internet would not even still be in existence.
As an aside, I would also like to point out that, in the courts, the case brought by SCO against IBM is definitely not going in SCO's favour - for the simple reason that SCO have so far failed to so much as present their case. In fact, they have recently been ordered by the judge to present the actual allegations and evidence to IBM so that both the court and IBM actually know what the case is even about. SCO have been obstructive at every turn within the course of proceedings, leading many analysts conclude that SCO have no case and are merely stalling for time before reaping the rewards of their share price (which has been rising in the wake of their claims) and withdrawing the case entirely.
In the aftermath of the BBC's recent controversy (a case where I side with the BBC, incidently), I find it disappointing that a story containing nothing but supposition, factual errors, and one-sidedness could be released.
...is often one of those areas where you need both qualifications and experience to get a good job. If you only have experience, you'll find it difficult to get a high-level job, and if you only have qualifications - well, you've basically at the bottom of the ladder.
In Europe, I'd recommend the Open University. It's distance-learning in your own time, so you can start out with an entry-level job immediately while you're studying. Frequently, the mere fact that you *are* studying towards a degree counts in your favour, so you may be able to negotiate a higher salary based on it. Plus, you can work towards "smaller" qualifications en route, so that after a year or two you could have a Certificate in Computing, another year or two and you have a Diploma, and then eventually (after an average total of about six years, depending on how much you want to take on at once) you get your Degree.
Another reason the Open University is good is that, if (like me) you're in the IT field without qualifications, but you already know your shit, you can step straight on to the Postgraduate level stuff. I'm currently working towards an MSc despite the fact that I don't even have a BSc. I'm certainly thankful for that, because I didn't particularly want to have to sit through a course on "You, Your Computer And The Internet"!
Given the recent furore in the UK over university tuition fees, I wouldn't be at all surprised if in the future more school-leavers get a job with someone willing to fund a degree with the OU. It takes a few years longer, granted, but you come out with it with a big wad of cash from your job rather than a big pile of student debt.
I brought a new Iron the other day and in capital letters in the instruction book I was told to never iron clothes while I am wearing them and that while I could use the shot of steam while the iron was in an upright position I should not forget the previous instruction about not ironing the clothes I'm wearing.
But people dumb enough to do this do exist. I have personally witnessed a friend (who shall remain nameless) iron his trousers whilst wearing them. To his credit, he did have the intelligence to promptly learn not to attempt this a second time.
at the top of your page. That will disable the default session cookies.
Not as simple as that. That disables sessions entirely, not just the cookie.
This basically means you can't use ASP sessions AT ALL. You could have a session-disabled ASP page at the start of your site to present a "do you want to use cookies?" option - but then you've got to code your site without sessions at all.
Even then, on the session-enabled ASP pages, you have to have a check that they've picked the "go ahead and use cookies" option - if they haven't, redirect back to the (session-disabled) option page. I'm not even sure that a session cookie wouldn't be set in the process.
Imagine the FSF suddenly abandoning/stalling the GPL in favor for someyet-unwritten different license, leaving ten thousands of Free Software developers in the legal lurch & betraying their trust.
Okay... so I start imagining this... and then one microsecond later I start wondering why the licence.gpl file I distribute with my software has supposedly just gone up in smoke.
Slashdot Mirror
There is a chance that the next Trek movie will be great. I mean, consider the evidence...
Trek 1 - sucked
Trek 2 - great
Trek 3 - sucked
Trek 4 - great
Trek 5 - sucked
Trek 6 - great
Trek 7 - sucked
Trek 8 - great
Trek 9 - sucked
At this point, everyone is aware of the "evens are great, odds all suck" rule. But then...
Trek 10 - sucked
"WTF?!" comes the cry of astonishment. Well, re-examine the evidence and come up with a new theory:
Trek 10 sucked because ONE PLUS ZERO EQUALS ONE WHICH IS ODD. It's simple: it's the sum of the digits that matter. So Trek 11 will be great because ONE PLUS ONE IS TWO WHICH IS EVEN!
You heard it here first.
Mail? FTP? Usenet? DNS? IRC and Instant Messaging? Just to name a handful.
The web isn't everything, and your question certainly doesn't warrant three question marks.
Good heavens. Surely not... you don't mean... it can't be...
Yes, folks, a growing population plus a record turnout means a large number of votes. Colour me stunned.
Ha! The idiot can't even spell 'intarweb'.
The W3C specs for XHTML, CSS and the DOM aren't obtuse - I understand them just fine. You're just not thinking about their target audiences. Joe Schmoe has about as much need to read the XHTML specs in order to write XHTML documents as he does to read the TCP/IP RFCs in order to set up a home network.
Joe Schmoe will instead read a beginners tutorial on the web, or buy "a dummies guide to XHTML", or (more likely) use a WYSIWYG tool.
The specifications are primarily for implementors, i.e. writers of browsers and parsers and other such tools, and secondly for those users that are advanced enough to want to read the actual spec.
That is possible. I suggest you stop using absolute units (pixels, points, etc) and have a look at relative units (for example ems). Then all your width/height/etc settings will be recalculated when the user changes their browser's font settings. 3em for "medium" font size is different from 3em for "small" font size, and so on.
Well, this isn't Yet Another HTML Standard - this is XHTML, which is HTML in an XML format. In that sense, we've already gone to "full-blown XML".
Alternatively, if you mean we should all make up our own XML-based languages and create whatever tags we want every time we create a website... that's a terrible idea. The strength of (X)HTML is that you/me/browsers/everyone knows that <h1> is a heading, and so on.
Imagine writing a script that extracts all the headings from a document, in order to create a table of contents. Simple when you know you're looking for <h1>, <h2>, etc., but exactly how would you go about it when the elements that represent headings can be different for each and every document, depending on whatever element names the author felt like using on that particular day?
The id and name attributes aren't meant to be the same. The name attribute is used for naming form controls, and (for example) this means that all radio buttons that are meant to be part of the same set all have the same name. Since the id attribute is meant to contain a unique identifier, making them the same would mean either [a] making it impossible to group radio buttons, since their names would need to be unique, or [b] making it impossible to grab an element by it's unique identifier, since ids can't be unique if you want to group radio buttons. Which would you prefer, exactly?
May I ask why? There are three situations I can imagine here:
Another thing to bear in mind is that some browsers (Internet Explorer 6.0, Mozilla (I forget from which version)) can understand XSLT themselves. You could do some server-side browser detection and, if the client can support it, farm out the XSLT processing to them.
Moral of the story: if you don't need to do it, don't!
It's about time someone tried to circumvent the W3C.
Honestly, the timescales the W3C are working on now are a joke. CSS3 has been in development since 2000 and is still nowhere near completion. XHTML 2.0 has been in development since August 2002, has already suffered from having its mission statement rewritten without announcement, and is, frankly, a bit crap. They don't even make use of XLink, but instead decided to write their own linking specification from scratch.
In short, the W3C has become a dinosaur. It takes far too long for them to get around to do anything, and it seems riddled with political jostling between both its members and its different working groups.
I think it's time someone else took over. The W3C only really works because the public allows it to - after all, the W3C isn't an official standards body so it's "standards" aren't really standards anyway. If someone else can do a better job, I say let them.
Er... in that respect, Microsoft are following the standards, because that's how it's done with the W3C's Document Object Model. If you have a problem with it, you have a problem with the DOM, not with Microsoft.
Again, that's your fault, not Microsofts. Either live with it, or split out the XML-generation code into a separate module. The world and his dog has long since learned to separate out logic code and database-access code so that it's possible to change DBMS by just rewriting the database-access module rather than the entire application - exactly the same thing applies with XML.
If you can tell the difference between equal temperament and the "correct" temperament for the key you're playing in, then you've a better ear than me. There's only a very limited difference between the two (less than 1%, if memory serves).
Plus, equal temperament is a fricking godsend. Can you imagine having to retune a piano every time you needed to change key? Without equal temperament, every piece of piano music (and all other similarly-difficult-to-retune instruments) would pretty much have to pick a key and stay in it.
Where's the URL, dude? I want to apply it to my local copy.
My complaint submitted to the BBC:
I'm not a Linux user, and have never been, and nor have I ever purchased any software or services from SCO. Thus, I consider myself pretty impartial when it comes to the ongoing SCO vs Linux case, but nonetheless I felt compelled to complain about the factual errors and, worse, outright assumptions presented as facts within this story.
Firstly, the story claims that it "seems likely" that the MyDoom worm is the work of an enraged Linux zealot. Personally, this seems highly unlikely - for a start, most Linux zealots that I know don't know anything about Windows, in the same way that most Windows users don't know anything about Linux. Thus the likelihood that a Linux zealot would have the know-how to write a sophisticated Windows-based worm (and let's not forget, this worm only affects Windows) seems rather unlikely.
Furthormore, the article bases this claim upon the fact that the worm targets the SCO website. Perhaps, but that seems to be far from the primary purpose of the worm. It also installs a backdoor on the victim's machine that allows it to be used as a spam relay. Since Linux zealots (and indeed, the vast majority of programmers in general) aren't fans of spam, it seems highly unlikely that such a backdoor would be desirable to the programmer.
Based on that alone, I find it far more likely that the worm is the work of spammers. It's well documented that spammers will stop at little to send their mail. Furthermore, the attack on the SCO website provides a sufficient red herring to divert attention from the spam backdoor - I consider it significant, for example, that the attack on SCO's webserver lasts only for a few days, whereas the backdoor remains there permanently until removed.
I further object to the implication that virus writers are "run of the mill geeks". Virus writers are far from run of the mill - if every computer geek (and I do count myself amongst this group, despite not being a Linux user) were to write and release viruses, then quite frankly the Internet would not even still be in existence.
As an aside, I would also like to point out that, in the courts, the case brought by SCO against IBM is definitely not going in SCO's favour - for the simple reason that SCO have so far failed to so much as present their case. In fact, they have recently been ordered by the judge to present the actual allegations and evidence to IBM so that both the court and IBM actually know what the case is even about. SCO have been obstructive at every turn within the course of proceedings, leading many analysts conclude that SCO have no case and are merely stalling for time before reaping the rewards of their share price (which has been rising in the wake of their claims) and withdrawing the case entirely.
In the aftermath of the BBC's recent controversy (a case where I side with the BBC, incidently), I find it disappointing that a story containing nothing but supposition, factual errors, and one-sidedness could be released.
I thank you for reading, and await your reply.
...is often one of those areas where you need both qualifications and experience to get a good job. If you only have experience, you'll find it difficult to get a high-level job, and if you only have qualifications - well, you've basically at the bottom of the ladder.
In Europe, I'd recommend the Open University. It's distance-learning in your own time, so you can start out with an entry-level job immediately while you're studying. Frequently, the mere fact that you *are* studying towards a degree counts in your favour, so you may be able to negotiate a higher salary based on it. Plus, you can work towards "smaller" qualifications en route, so that after a year or two you could have a Certificate in Computing, another year or two and you have a Diploma, and then eventually (after an average total of about six years, depending on how much you want to take on at once) you get your Degree.
Another reason the Open University is good is that, if (like me) you're in the IT field without qualifications, but you already know your shit, you can step straight on to the Postgraduate level stuff. I'm currently working towards an MSc despite the fact that I don't even have a BSc. I'm certainly thankful for that, because I didn't particularly want to have to sit through a course on "You, Your Computer And The Internet"!
Given the recent furore in the UK over university tuition fees, I wouldn't be at all surprised if in the future more school-leavers get a job with someone willing to fund a degree with the OU. It takes a few years longer, granted, but you come out with it with a big wad of cash from your job rather than a big pile of student debt.
I can just imagine the Slashdot front page....
But people dumb enough to do this do exist. I have personally witnessed a friend (who shall remain nameless) iron his trousers whilst wearing them. To his credit, he did have the intelligence to promptly learn not to attempt this a second time.
That would be water then...
Woah.
This guy has one serious afro.
Either that or she really needs to think about shaving.
I refuse to believe I was the only one who misread that as "Microsoft Adding Bugs to Longhorn?" and thought "geez, aren't there enough already?"
Not as simple as that. That disables sessions entirely, not just the cookie.
This basically means you can't use ASP sessions AT ALL. You could have a session-disabled ASP page at the start of your site to present a "do you want to use cookies?" option - but then you've got to code your site without sessions at all.
Even then, on the session-enabled ASP pages, you have to have a check that they've picked the "go ahead and use cookies" option - if they haven't, redirect back to the (session-disabled) option page. I'm not even sure that a session cookie wouldn't be set in the process.
Okay... so I start imagining this... and then one microsecond later I start wondering why the licence.gpl file I distribute with my software has supposedly just gone up in smoke.
Oh, wait, it hasn't...
Which encoding are you using here? It doesn't seem to be base64...