• (cs) in reply to loneprogrammer

    loneprogrammer:
    (and you don't care about people who are colorblind and can't see red things).

    We can too see red things!  They just don't look red

  • Konrad (unregistered) in reply to Yeah...Right...
    QUOTE
    The mentor /still/ shouldn't have been groaning.  If it was a flat text file surely a quick search and replace (ie sed "s/
    END QUOTE
     
    ASP Website = Windows (only) Programmer who the extent of his reading probably consisted of one ASP book brough at 75% off when it was 2 years out of date.
     
    My guess: he would know what a regular expression was if one came up and bit him.
    Probably used Windows Notepad to make the changes.  
     
    regs
     
    Konrad
  • John Hensley (unregistered) in reply to MikeMontana
    MikeMontana:
    Another perfect stinker! On a side note, where does one find a reference "Here's the best way to do a task..." for a particular language? Reading through the programming manual will give you the syntax structure for what needs to be done. To understand how to best apply a toolset seems to be reading through tons of posts on the web, skimming past flame wars on where to put the "{" etc.

    I ask because I am now starting off with Flex-2 development. I'm ok with sytax, structure and relationships (to a degree at least), but, stuck at "whats the best way to do things like check for login status, cross communicate between panels/forms...is that a 'no/no' " and so on. Any suggestions on the best way to quickly get up on application-level-development for a particular language (is there a book series slanted this way??) - and if you have any particularly good suggestions on Flex2, I'd much appreciate it!

    If the language or implementation has a large company behind it, check that company's web site for online resources and book recommendations.
    If there is a magazine for developers using the language, subscribe to it.

  • John Hensley (unregistered) in reply to loneprogrammer
    loneprogrammer:
    Cooper:
    The real WTF is that 'style=' is allowed in any element, ever.

    At some point in time, (early 2003,) XHTML 2.0 was going to have the STYLE attribute removed completely.

    But people must have whined enough to get it put back.  :-(

    The real WTF is that the W3C is developing XHTML 2.0. Who has adopted 1.0?

  • John Hensley (unregistered) in reply to Cooper
    Cooper:
    The real WTF is that 'style=' is allowed in any element, ever.

    When I waste time thinking about this (not often except when confronted with WTFery like today's example), I wonder just what they were thinking.

    They were thinking "How are we going to repair the damage that Netscape did with FONT, COLOR, and overlapping elements?"

    Yeah I know, three posts in a row. That's life.

  • Marvel (unregistered) in reply to John Hensley

    The even bigger WTF is, that they put h1-h6 back in.

  • Charles Duffy (unregistered) in reply to Gunther

    MySQL in the list of "real databases"? Sure, it probably qualifies as one by now -- but any Real DBA still resents the MySQL development team saying that relational integrity, views, transactions &c. were a waste of time back in the late 90s (when they supported none of those features), and still insists that it's a toy for that reason.

    (Having been through the hell of maintaining databases and database-driven applications built by people who believed the MySQL team back in the late 1990s and built DBs without relational integrity, views, transactions, &c., I can't really blame the folks who refuse forgiveness).

  • (cs) in reply to Happy
    Anonymous:
    Heck, no search and replace is necessary.  Just put in at the top:
    h2 { font-size: 18px !important; }
    and that should override all the inline styles.


    I'm pretty sure that's incorrect. The inline styles will override the style element; the !important designation only has effect within a specificity level. Specificity trumps everything.
  • loneprogrammer impersonator (unregistered) in reply to Bus Raker
    Bus Raker:

    We can too see red things!  They just don't look red


    I realize that, but some people can't read red words on a green background.  Just like people with average eyesight can't read white words on a light grey background.
  • Alex (unregistered) in reply to loneprogrammer impersonator
    Anonymous:

    I realize that, but some people can't read red words on a green background.  Just like people with average eyesight can't read white words on a light grey background.


    Why are you putting red text on a green background... that's like hitting your page with an ugly stick :)
  • Danny (unregistered) in reply to Alex

    I am a network admin. I don't use a passwords.txt file. It is too insecure.

    I tell all of our users to write their usernames and passwords on post-it notes and place them on their monitors.

    That way they don't have to ask me when they forget their username or password. And it's secure because they can place the post-it note in a drawer to hide it.

  • Grant Hutchins (unregistered)
    Alex Papadimoulis:

    The database contained all of the formatting. And I mean *all* of the formatting. The headings pulled directly database looked like this ... 

      <h2 style="font-family: Arial, Helvectica;font-size:14px;
         text-decoration:underline;"    >Chotchkie's: A Review</</SPAN>h2>

    ... so, Chris started to understand why this was such a pain. Each heading would need to be updated in the database.

    Maybe he'll see why the fonts aren't quite right too. I for one have never heard of the font Helvectica.

  • Voice of Reason (unregistered) in reply to Grant Hutchins

    <PostsWithHTMLTagsAreCool></PostsWithHTMLTagsAreCool>

  • (cs) in reply to John Hensley
    Anonymous:
    MikeMontana:
    Another perfect stinker! On a side note, where does one find a reference "Here's the best way to do a task..." for a particular language? Reading through the programming manual will give you the syntax structure for what needs to be done. To understand how to best apply a toolset seems to be reading through tons of posts on the web, skimming past flame wars on where to put the "{" etc.

    I ask because I am now starting off with Flex-2 development. I'm ok with sytax, structure and relationships (to a degree at least), but, stuck at "whats the best way to do things like check for login status, cross communicate between panels/forms...is that a 'no/no' " and so on. Any suggestions on the best way to quickly get up on application-level-development for a particular language (is there a book series slanted this way??) - and if you have any particularly good suggestions on Flex2, I'd much appreciate it!

    If the language or implementation has a large company behind it, check that company's web site for online resources and book recommendations.
    If there is a magazine for developers using the language, subscribe to it.



    If there is an official mailing list or newsgroup or forum for developers, check those out as well.  I got myself relatively up to speed on Linux (in preparation for buying and maintaining a home server) by reading relevant parts of comp.os.linux.* for a few months.

  • (cs) in reply to NancyBoy
    NancyBoy:
    loneprogrammer:
    Cooper:
    The real WTF is that 'style=' is allowed in any element, ever.

    At some point in time, (early 2003,) XHTML 2.0 was going to have the STYLE attribute removed completely.

    But people must have whined enough to get it put back.  :-(

    It's still in the draft specification.

    Note: use of the style attribute is strongly discouraged in favor of the style element and external style sheets. In addition, content developers are advised to avoid use of the style attribute on content intended for use on small devices, since those devices may not support the use of in-line styles.

    Just curious, what difference does it make?



    Style element (and external style sheets) are referenced by elements needing style. Using inline style attributes means that changes to styles need to be done every frigging element in document instead of just in stylesheet. Ring any bells?
  • bramster (unregistered) in reply to Alex
    Anonymous:
    Anonymous:

    I realize that, but some people can't read red words on a green background.  Just like people with average eyesight can't read white words on a light grey background.


    Why are you putting red text on a green background... that's like hitting your page with an ugly stick :)


    Hey, I had to pick someone to put a reply to.

    I'm an "old" time programmer, very close to collecting a pension.  Doesn't necessarily make me smart, but it might help make me wise.

    Way back in my typesetting days. . .   paper tape and all that, and the paper tape was way better than how it was being done up till then. . . .  a really good typesetting machine, (with 16K (yes, kilobytes, with included a pretty good hyphenation algorithm and dictionary, believe it or not -- it was the 1970's) and it was real Core Memory "ferrite donuts with windings. . .    didn't die when the power was turned off)  -- we had something called "formats".   One could store 32 keystrokes to a format, give it a name, and then call those 32 keystrokes back. 

    One could create larger "formats", but if format 11 had more than 32 keystrokes, then format 12 was unavailable. 

    A great way to learn how to write REALLY EFFICIENT CODE.

    Now, formats aren't a whole lot different from CSS style sheets, as I understand them.  Except, you're not limited to 32 keystrokes. (I'm not one of the four Yorkshiremen, even if it sounds like I might be an honourary one).

    If, dear reader, you're still awake. . .

    I see on this site a considerable prejudice against programming with flat files.

    Donald Knuth said that 95% of data processing was searching and sorting.

    One a file is sorted, then searching is pretty simple.  (binary search).

    With a good "search and replace" routine (anybody heard of "FILETRAN"), you can build a search/replace table, pull your input flat file into it, and produce an output file.

    And do it again, and again, until you get it right.

    I wrote my own version of FILETRAN, so that I could execute it from the command line, being completely ignorant of piping.  (still less than doctorate level on piping).

    The point is (is there a point?)

    There are many, many ways in which to solve a problem.  

    There are a lot less ways to solve a problem that let one backtrack to see where "something went wrong".

    Packaged systems. . .    click the menu. . .   etc. . .

    Well, I suspect, somewhere, a pointer file or linked list is built. . .  it's sorted, according to a user-specified criterion, and then an extraction is done.

    Hey, folks, you can do that with flat files.

    It might take a little longer to write the correct code, but I'll guarantee that when it comes to execution time, repeatability, consistency of results, being able to tell your customer "this is where the problem in YOUR data was. . ." dealing with flat files, even for very complex projects, will allow one to sleep at night.

    Oh, yeah, I wrote my own sort program. . .     Kernighan and Ritchies algorithm, with a good front-end and a good back-end.  It scales to what disk space allows.




























































  • Kiss me, I'm Polish (unregistered) in reply to bramster

    I won't take style advices from someone who can't correctly use the ellipsis and makes me scroll to the end of his message just to find out there's just a huge blank.
    You failed to be a mentor.

  • DiamondJim (unregistered) in reply to WeatherGod

    Anonymous:
    With that password, the student can become the mentor!

     

    Well...whaddya know? Eat this... http://stuff.chovy.com/txt/passwords.txt. [:^)]

  • (cs) in reply to loneprogrammer

    loneprogrammer:
    The point of CSS is that it controls the way HTML documents appear to the user.

    Uh, you can get a little less granular.

    <snip potted summary of what styles and classes are -- not my question>

    loneprogrammer:
    tag means "this is a paragraph" but it does not have to be any particular font or color or size, or in any particular place on-screen.  Some people might be blind and need to have the paragraph read aloud, others might have bad sight and need a very large font, or different colors that they see better.  The user might be using a phone and have a very small screen.

    Again, this has nothing to do with the difference between a "style element" and an inline style.

  • (cs) in reply to Magic Duck
    Magic Duck:
    NancyBoy:
    loneprogrammer:
    Cooper:
    The real WTF is that 'style=' is allowed in any element, ever.

    At some point in time, (early 2003,) XHTML 2.0 was going to have the STYLE attribute removed completely.

    But people must have whined enough to get it put back.  :-(

    It's still in the draft specification.

    Note: use of the style attribute is strongly discouraged in favor of the style element and external style sheets. In addition, content developers are advised to avoid use of the style attribute on content intended for use on small devices, since those devices may not support the use of in-line styles.

    Just curious, what difference does it make?



    Style element (and external style sheets) are referenced by elements needing style. Using inline style attributes means that changes to styles need to be done every frigging element in document instead of just in stylesheet. Ring any bells?

    I wasn't asking about external stylesheets.  Style elements and inline styles are both still "embedded" with the HTML.  And you can still manipulate the style property for any given element using scripting.  Or is that verboten by purists as well?

  • Benjamin Smith (unregistered) in reply to bullseye
    bullseye:

    PCBiz:
    Correct me if I'm wrong but what happens when the client inputs thousands of records and the text file database gets bigger and bigger?  It might not be today or next month but if the client continues to use this for several years this could become a problem.

    I'm convinced that many sub-par consultants actually engineer these disasters as a form of job security.  If you think about it, it makes sense. 

    Rather than deal with all that planning and design crap, you mash something together that works for the current situation. If you build a system that will inevitably fail as the client's business grows, you have an opportunity to come back in and do the same thing on a larger scale (interpreted, more $$$).  If the client dies out, then you saved some otherwise unrecoverable brain cells.

    I'll call it... Consulting 2.0.



    Ahem.

    As a software engineer/consultant, what I more typically find is a customer unwilling to pay for  anything beyond the simplest, stupidest, who-cares-if-it's-insecure  applications, despite repeated and dire warnings. So, in order to make any money, you do hackish things to compensate. In these cases, I make it pointedly clear that it will cost more in the long run.

    Then, when it all does go up in flames, I get the phone call, and the "cost more in the long run" becomes the short run.

    It's sad, and more than just a little depressing. I can't tell you how many times I've successfully predicted MAJOR expenses, often YEARS IN ADVANCE. I point it out, I make it clear. I advise of the dangers of the compromised position. But, if I bring it up when the expenses start mounting, then I'm "pointing fingers" which is "inconducive to smooth co-operation".

    I've got plenty of work now, so I've simply stopped accepting work that only pays at "slap-hack y"levels. I bid high, and don't always get it, but I have the money (time) to do quality work.

    It's so much  better this way!
  • (cs) in reply to NancyBoy
    NancyBoy:
    stuff


    What is your question, exactly?

    The difference between what and what?
  • (cs) in reply to Benjamin Smith
    Anonymous:


    Ahem.

    As a software engineer/consultant, what I more typically find is a customer unwilling to pay for  anything beyond the simplest, stupidest, who-cares-if-it's-insecure  applications, despite repeated and dire warnings. So, in order to make any money, you do hackish things to compensate. In these cases, I make it pointedly clear that it will cost more in the long run.

    Then, when it all does go up in flames, I get the phone call, and the "cost more in the long run" becomes the short run.

    It's sad, and more than just a little depressing. I can't tell you how many times I've successfully predicted MAJOR expenses, often YEARS IN ADVANCE. I point it out, I make it clear. I advise of the dangers of the compromised position. But, if I bring it up when the expenses start mounting, then I'm "pointing fingers" which is "inconducive to smooth co-operation".

    I've got plenty of work now, so I've simply stopped accepting work that only pays at "slap-hack y"levels. I bid high, and don't always get it, but I have the money (time) to do quality work.

    It's so much  better this way!


    You've apparently found that sweet spot between bidding low to get lots of jobs for a stead cash flow, and bidding really high to get a splooge of cash after each big project.
  • (cs) in reply to Noam Samuel
    Noam Samuel:

    Just use google:


    Which reminds me of a kind of related phenomenon - try googling for "5fcfd41e547a12215b173ff47fdd3739"... (MD5 hash for "trustno1" =)

  • (cs) in reply to NancyBoy
    NancyBoy:

    I wasn't asking about external stylesheets.  Style elements and inline styles are both still "embedded" with the HTML.  And you can still manipulate the style property for any given element using scripting.  Or is that verboten by purists as well?


    For God's sakes, YES!

    If you can't see the point of CSS classes, then you have missed the point completely, and I can't help you.
  • (cs) in reply to Bus Raker

    I heard that if you put mentors in a bottle of cola it'll explode up to 15 feet in the air...

    Ooops...that was Mentos, not Mentors...

    Jim

  • (cs)

    You gotta be kidding me...

    I usually never post here... i just read what NOT to do on my projects lol.

    But this one caught my attention... this mentor had to be real stupid, honestly.

    5-star WTF

  • (cs) in reply to APAQ11
    Anonymous:
    It's pretty bad that the mentor was writing code like that. It's even worse that the mentor thought he was a good enough programmer to teach others his bad ways. Ignorance FTL [:P].


    Unfortunately, this is pretty much a given, since recognizing your own lack of competence would already require a certain level of competence. Recommended reading: http://www.apa.org/journals/features/psp7761121.pdf
  • (cs)

    This was just very very very scary... are there people actually doing stuff like that ?

    Oh God...  

  • SomethingSomethingBurtWard (unregistered) in reply to Bus Raker

    How do you know how red is supposed to look?

  • (cs) in reply to NancyBoy
    NancyBoy:
    loneprogrammer:
    Cooper:
    The real WTF is that 'style=' is allowed in any element, ever.

    At some point in time, (early 2003,) XHTML 2.0 was going to have the STYLE attribute removed completely.

    But people must have whined enough to get it put back.  :-(

    It's still in the draft specification.

    Note: use of the style attribute is strongly discouraged in favor of the style element and external style sheets. In addition, content developers are advised to avoid use of the style attribute on content intended for use on small devices, since those devices may not support the use of in-line styles.

    Just curious, what difference does it make?

    Dunno, maybe the one that using the style attribute links your styles specifically to a precise element, and mixes the data and presentation layers of your page, which is what CSS are originally set to prevent?

    Anonymous:
    loneprogrammer:
    Cooper:
    The real WTF is that 'style=' is allowed in any element, ever.

    At some point in time, (early 2003,) XHTML 2.0 was going to have the STYLE attribute removed completely.

    But people must have whined enough to get it put back.  :-(

    The real WTF is that the W3C is developing XHTML 2.0. Who has adopted 1.0?

    People who like shiny things, see XHTML and say "hey it's XML and it's semantic, HTML was not semantic, XHTML is better, more different, and it's XML so it's good!

    NancyBoy:

    you can still manipulate the style property for any given element using scripting.  Or is that verboten by purists as well?

    It's bad practices.

    See it that way: CSS control the way things are displayed, Javascript control the way things behave, change, evolve. They're linked, but they're not the same. They just work together. Or you make them work together, when you're somewhat good and know about your craft, if only because it makes your work simpler and your pages snappier.

    So you could, say, use Javascript to add and remove classes, and then create rules according to the added and removed classes (or even specific, nonstandard attributes if you don't have to support MSIE too much) that'd modify the way your page is displayed.

    For example a while ago I created a little page, this page (which I won't link to for ugly as a sin it is) is a simple list of links, some in french and some in english, with a "lang" attribute set for each list item.

    For I wanted to tell "the reader" (just about no one, really, but the "use case" was a reader population made up mostly of french people, some of them unable to read english and therefore uninterrested in english websites) whether the website he'd reach would be in english or in french.

    So I set out to use the CSS attribute selector to display little flags near the links, to explain the language of the destination site.

    And then I wondered whether I could put some kind of filter so that the user could select the languages he'd be interrested in. I could've parsed repeatedly my DOM through javascript, modified the display state of each element to display it or not based on whether it was going to be filtered in or out.

    But I had my language attributes already, and I had the Cascade, and I knew jack about CSS and JS.

    So I just added 2 simple rules, something along the lines of:

        *[lang] {
        display: none;
    }

    body.en *[lang=en],
body.fr *[lang=fr]  {
    display: block;
}</pre></blockquote>

    

    And the only javascript i had to do was add or remove a class on the body whenever languages were selected or deselected.
    

    A single DOM call, a simple string substitution, no loops, to filter in or out dozens if not hundreds of links in a single move, instantly, automatically, asking the browser itself to do all the heavy work.
  • (cs) in reply to masklinn

    Note: I dumbed down the rules slightly, the real ones use one more class on body (on every rule), created at the initialization of the JS stuff, so that the elements are always displayed if Javascript is disabled. With the rules I wrote in my previous post, a user with Javascript disabled but CSS available wouldn't see any item (everything would default to "display: none", which isn't much graceful of a degradation).

  • Reginald (unregistered) in reply to masklinn

    There's nothing you can't accomplish with Javascript.

  • (cs) in reply to Reginald
    Anonymous:
    There's nothing you can't accomplish with Javascript.

    You can use Javascript to turn Javascript back on?

    Don't think so.
  • (cs) in reply to AC
    Anonymous:

     If PHB's had any brains at all, they'd think, in this order:

    1. I'm smooth, but I don't know jack about programming.
    2. I know a ton of people like me.
    3. This consultant is smooth.
    4. Therefore, there's a decent chance s/he doesn't know jack about programming.


    there might be a ton of people that are smooth and don't know programming...  however, there are a ton of people who are smooth and know programming, a ton of people who aren't smooth and don't know programming,  and a ton of people who aren't smooth and know programming.  Assuming someone that knows programming can't be smooth is accepting the fallacy-filled stereotype that programmers are nerds who can't communicate with normal human beings and should be confined to their cubicle-dungeons.
  • (cs) in reply to Reginald

    WTF!!!!!!!!!!!

    -----

     

    Maybe we should just write webpages in C++ and that would cut out at least 31% of the stupidity in the net.  Or not.....I'm just spit-ballin here.

     

     

  • (cs) in reply to loneprogrammer
    loneprogrammer:
    Anonymous:
    There's nothing you can't accomplish with Javascript.

    You can use Javascript to turn Javascript back on?

    Don't think so.

    And you're wrong !

    Let's say you're using firefox, and let's say you're using NoScript do unactivate Javascript. If you want to reactivate javascript then you ask NoScript to reactivate it, NoScript is a Firefox extension, therefore NoScript is in XUL which is Javascript and a bunch of XML, RDF and CSS files, you're therefore using Javascript to turn Javascript back on. QED
  • (cs) in reply to tster
    tster:
    Assuming someone that knows programming can't be smooth is accepting that programmers are nerds who can't communicate with normal human beings and should be confined to their cubicle-dungeons.

    And they damn well are, even though they don't like it pointed to them, which is exactly what you just did you insensitive clod.
  • steve (unregistered) in reply to Bus Raker

    REally? How about this?

    First Captcha: register -- could that be a hint?
    second captcha: picture -- ah yes picture the captcha not working, not very hard is it?

  • steve (unregistered) in reply to steve

    dammit the quote f'ed up.
    that was supposed to be in reply to "we do see red things.. "

  • (cs) in reply to masklinn
    masklinn:
    NancyBoy:

    you can still manipulate the style property for any given element using scripting.  Or is that verboten by purists as well?

    It's bad practices.

    See it that way: CSS control the way things are displayed, Javascript control the way things behave, change, evolve. They're linked, but they're not the same. They just work together. Or you make them work together, when you're somewhat good and know about your craft, if only because it makes your work simpler and your pages snappier.

    So you could, say, use Javascript to add and remove classes, and then create rules according to the added and removed classes (or even specific, nonstandard attributes if you don't have to support MSIE too much) that'd modify the way your page is displayed.

    For example a while ago I created a little page, this page (which I won't link to for ugly as a sin it is) is a simple list of links, some in french and some in english, with a "lang" attribute set for each list item.

    For I wanted to tell "the reader" (just about no one, really, but the "use case" was a reader population made up mostly of french people, some of them unable to read english and therefore uninterrested in english websites) whether the website he'd reach would be in english or in french.

    So I set out to use the CSS attribute selector to display little flags near the links, to explain the language of the destination site.

    And then I wondered whether I could put some kind of filter so that the user could select the languages he'd be interrested in. I could've parsed repeatedly my DOM through javascript, modified the display state of each element to display it or not based on whether it was going to be filtered in or out.

    But I had my language attributes already, and I had the Cascade, and I knew jack about CSS and JS.

    So I just added 2 simple rules, something along the lines of:

        *[lang] {
        display: none;
    }

    body.en *[lang=en],
body.fr *[lang=fr]  {
    display: block;
}</pre></blockquote>

    

    And the only javascript i had to do was add or remove a class on the body whenever languages were selected or deselected.
    

    A single DOM call, a simple string substitution, no loops, to filter in or out dozens if not hundreds of links in a single move, instantly, automatically, asking the browser itself to do all the heavy work.

    Hmmm... I wonder how you'd do something like JSNeko without per-element styles? (Basically, it works by showing, hiding and setting the position of various divs - possibly slightly WTF-worthy, but there you go). Note that this is only tested on relatively recent versions of IE, Firefox and Konqueror.

  • (cs)

    And thus the farce that experience brings wisdom...

     

    ___

    Don'tcha wish you could slap people through the internet?

  • The Sloth (unregistered) in reply to Danny
    Anonymous:
    I am a network admin. I don't use a passwords.txt file. It is too insecure.

    I tell all of our users to write their usernames and passwords on post-it notes and place them on their monitors.

    That way they don't have to ask me when they forget their username or password. And it's secure because they can place the post-it note in a drawer to hide it.


    No way man, the only secure place to hide the post-it note with the password on it is on the bottom of the keyboard!
  • Julie (unregistered) in reply to MikeMontana
    MikeMontana:
    Another perfect stinker! On a side note, where does one find a reference "Here's the best way to do a task..." for a particular language?


    There are various resources for different general programming topics.  Since this WTF points out a fairly obvious security issue, a good resource to bring up here is the OWASP's Top Ten Most Critical Web Application Security Vulnerabilities:

    http://www.owasp.org/documentation/topten.html

    As far as getting into the specifics of how to implement these in Flex-2, look on a Flex-2 user's forum or something.  I've never heard of this language. Is it obscure, or am I just living in a vacuum?  If it's obscure you might have a hard time finding support for how to do stuff in it, and I'd recommend trying something a little more standard - php, asp.net, java/jsp, etc.  If you're not building a web app, then you have a lot less to worry about!

    But it helps to use common sense.  Do not store passwords in clear text in a web-browsable directory on your server!  Generally, user passwords are stored using a one-way hashing algorithm (i.e. only the user knows its clear text version) in a database table, and admin passwords to database servers or other servers, are stored in an encrypted file on a portion of the web server that is not accessible to the outside world.  Same with the encryption keys to any password file - they shouldn't be in a web-browsable portion of a site, either! 
  • zbert (unregistered) in reply to Bus Raker

    How do you know?

  • (cs) in reply to tster

    Hate to say it, but your argument relies on a stereotype as much as his does.  Can you honestly say with any certainty that there are not an overwhelmingly larger number of programmers who lack business or social skills than those who have them?  You may be the exception, but that doesn't change the rule.

    I know some very good programmers.  I also know some people with very good social/business skills.  The two do overlap at times, but rarely.  In the end, most of the programmers I know lack these interpersonal skills.

    I think the important thing in Anonymous' argument is that a 'ton' means that he knows significantly more people who fit premise #1 than those who don't.  Thus, the conclusion follows (it's only a weak argument, not false).


    Some stereotypes are false, but not all.  Some are just conclusions formed over a long observation period.


    (I like that "do not allow replies" checkbox.  "No, I get the final word!" :D)

  • Julie (unregistered) in reply to zbert

    Anonymous:
    How do you know?

    Who's post are you replying to? 
  • (cs) in reply to RevEng

    I agree, the WTF is the forum software... (Why has nobody fixed this yet?)

    That was supposed to be a quote to tster.

  • John Hensley (unregistered) in reply to Magic Duck
    Magic Duck:

    Style element (and external style sheets) are referenced by elements needing style. Using inline style attributes means that changes to styles need to be done every frigging element in document instead of just in stylesheet. Ring any bells?

    On the other hand, requiring a class or ID just to use a style on one element of a document is an inevitable source of WTFs. Why have the style spec separate from the only element that uses it?

    The W3C has never gotten far by pushing ideology over practice. Does anyone remember HTML 3.0? I'd prefer they didn't make that mistake again.

  • (cs) in reply to John Hensley

    I guess no one grasped the basic question: He was asking what is the difference between

    <h1><style>font-style: italic;</style>Dude</h1>
    or something like that, and
    <h1 style="font-style: italic;">Dude</h1>

    You confused him because you called it a style element, instead of a stylesheet like every other designer on earth. What element holds the stylesheet (style, link, xml, etc) is inconsequential.

    Besides, why even bring up xhtml 2? It's not a standard yet (the draft seems to have stalled a year ago), browsers only support it in fits and starts (IE barely at all), and it requires a wholesale recoding of many parts of many websites.

    Removing style is a stupid way to try to legislate good style in a world full of humans who don't always think in terms of stylesheets. A lot of times people really do just want some red text, or positioned semi-alternately left or right (gee, using classes "left" and "right" is such a huge improvement, you never know when you might need to swap their styles in a hurry. welcome to wtf web) but not entirely regularly, or need bouncing marquee text that randomly changes colors. Admittedly it would be nice to tell someone asking for the latter "sorry, you just plain can't do that anymore".

Leave a comment on “Mentors, the Freshmaker”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article