Representative line



  • Some of our customers use a certain web shop framework, which – in theory – is powerful and highly extensible. In practice, it's a behemoth full of subtle bugs and without any useful documentation whatsoever. (Which is the reason we'll probably use it forever: Over the last two years we've spent so much time aquiring knowledge of the inner workings of the framework that it would be wasteful not to use it.)

    Recently, we've upgraded one of our customers to the latest version of this framework, which – among other things – fixes a horribly stupid JS date field validation bug. This is how they decided to fix it:

    day = parseInt(this.day.value.replace(/^0*/, ''))
    

    Yep, instead of specifing the radix (second parameter of parseInt, as every web developer should have learned years ago), they decided to remove leading zeros from the input using a regex.
    (This may look like a minor WTF, but unfortunately the framework is full of those.)


  • Discourse touched me in a no-no place

    @random said:

    Yep, instead of specifing the radix , they decided to remove leading zeros from the input using a regex.

    Sounds like the PHP way!

    The PHP hammer.



  • @FrostCat said:

    Sounds like the PHP way!

    No wonder, it's a PHP framework. (Which is not TRWTF, because – although the language itself is a huge pile of WTFs, without a doubt – good PHP frameworks actually exist.)



  • @random said:

    ... it's a behemoth full of subtle bugs and without any useful documentation whatsoever. (Which is the reason we'll probably use it forever: Over the last two years we've spent so much time aquiring knowledge of the inner workings of the framework that it would be wasteful not to use it.)

    Is it SugarCRM? It sounds like it is, or at least has similar issues. My previous job was maintaining the aforesaid pile of manure, and TRWTF was that it's high retarditude was not the reason the company is now shrinking.

    My current company, on the other hand, tried it and decided we'd stop using it despite months of work customisation, because it wouldn't do what we wanted (praise Cthulhu!). I've since struck the buzzword from my CV.



  • @Shoreline said:

    Is it SugarCRM?

    Nope, I'm talking about Magento CE. It's a very flexible framework and its code quality is gradually improving, but that are pretty much the only positive things I can say about it.



  • @random said:

    @Shoreline said:
    Is it SugarCRM?

    Nope, I'm talking about Magento CE.

    So my guess of Drupal was wrong too.



  • @random said:

    instead of specifing the radix (second parameter of parseInt, as every web developer should have learned years ago)
    parseInt is a bad way to convert a string to an integer (unless you really don't care that it silently eats invalid data and gives back a seemingly okay value).



  • @random said:

    day = parseInt(this.day.value.replace(/^0*/, ''))

    Maybe they're doing this on purpose, and they want to make sure that if there's space at the beginning, it'll still parse octal/hex numbers?


    Oh, wait, I found the WTF - it should be:

    day = parseInt(this.day.value.replace(/^0*/g, ''))
    

    So that they get all the leading zeroes.

  • Considered Harmful

    @Buttembly Coder said:

    @random said:
    day = parseInt(this.day.value.replace(/^0*/, ''))

    Maybe they're doing this on purpose, and they want to make sure that if there's space at the beginning, it'll still parse octal/hex numbers?


    Oh, wait, I found the WTF - it should be:

    day = parseInt(this.day.value.replace(/^0*/g, ''))
    

    So that they get all the leading zeroes.
    It needs to be:
    day = parseInt(this.day.value.replace(/^0*/gi, ''))
    

    To handle uppercase and lowercase zeroes.


  • @joe.edwards said:

    @Buttembly Coder said:
    @random said:
    day = parseInt(this.day.value.replace(/^0*/, ''))

    Maybe they're doing this on purpose, and they want to make sure that if there's space at the beginning, it'll still parse octal/hex numbers?


    Oh, wait, I found the WTF - it should be:

    day = parseInt(this.day.value.replace(/^0*/g, ''))
    

    So that they get all the leading zeroes.
    It needs to be:
    day = parseInt(this.day.value.replace(/^0*/gi, ''))
    

    To handle uppercase and lowercase zeroes.

    We also need to handle 0, so:

    day = parseInt(this.day.value.replace(/^[00]*/gi, ''))
    


  • @random said:

    (Which is the reason we'll probably use it forever: Over the last two years we've spent so much time aquiring knowledge of the inner workings of the framework that it would be wasteful not to use it.)
     

    Great, more people that don't understand sunk costs. Keeping the framework is sensible if there aren't any better frameworks around - but the reason you gave isn't a sensible reason. The same sort of thinking that created a market for object-oriented COBOL.



  • @random said:

    Yep, instead of specifing the radix (second parameter of parseInt, as every web developer should have learned years ago)

    Thankfully ES5 dictates that behavior is no longer correct. Numbers with leading 0's are parsed as decimal even if you don't give a radix (except 0x which are still parsed as hex). So if your code requires ES5 for other reasons, you can safely remove that hack.



  • @Paddles said:

    @random said:

    (Which is the reason we'll probably use it forever: Over the last two years we've spent so much time aquiring knowledge of the inner workings of the framework that it would be wasteful not to use it.)
     

    Great, more people that don't understand sunk costs. Keeping the framework is sensible if there aren't any better frameworks around - but the reason you gave isn't a sensible reason. The same sort of thinking that created a market for object-oriented COBOL.

    *




    * in case it's not obvious: I agree with that comment.



  • @Paddles said:

    @random said:

    (Which is the reason we'll probably use it forever: Over the last two years we've spent so much time aquiring knowledge of the inner workings of the framework that it would be wasteful not to use it.)
     

    Great, more people that don't understand sunk costs. Keeping the framework is sensible if there aren't any better frameworks around - but the reason you gave isn't a sensible reason. The same sort of thinking that created a market for object-oriented COBOL.

    That sentence wasn't meant to be taken literally. We're actually looking for a better framework to use in future projects, but haven't found a significantly better one so far.
    Besides, a new major version of Magento is currently being developed, featuring newfangled technologies such as support for an actual template system. (And they're even writing some documentation for it! And it finally dawned on them that their framework should rely on some coding conventions instead of requiring large XML configuration files for each module.) I'm still hoping it will turn out to be much better than its precedessor, because we'll have to maintain that one particular shop for a long time.



  • @random said:

    Over the last two years we've spent so much money aquiring knowledge of the inner workings of black jack that it would be wasteful not to use it.

    @random said:

    We're actually looking for a better casino but haven't found a significantly better one so far.

    This is how your Framework.User.WtfStory looks like when I cast it to LasVegas.Gambler.SobStory


  • Discourse touched me in a no-no place

    @random said:

    I'm still hoping it will turn out to be much better than its precedessor
    Is there a specific reason for believing that this might be true, or is it just wishful thinking?



  • @FrostCat said:

    Sounds like the PHP way!

    I never really got that sentiment. If you want to cast a string to int in PHP, you write "(int) $string" and it's done. That also removes leading zeros (naturally).

    I will not deny there are many things wrong with PHP, but saying that it "only has one tool" is pretty much the [i]exact opposite[/i] of what is wrong with it. Perl, now, is a one-tool language, and I would expect something like this there, but PHP? I can think of at least 5 ways to convert a string to an integer in PHP, all of them remove the leading zeros, and none use regexes.



  • @dkf said:

    @random said:
    I'm still hoping it will turn out to be much better than its precedessor
    Is there a specific reason for believing that this might be true, or is it just wishful thinking?

    They're regularly uploading their repository to Github, and they've already made a lot of important changes. And they've uploaded a lot of documentation in the past few months (still incomplete, but way more than ever existed for the previous version). Seems like there is hope.



  • @Ronald said:

    @random said:
    Over the last two years we've spent so much money aquiring knowledge of the inner workings of black jack that it would be wasteful not to use it.

    @random said:

    We're actually looking for a better casino but haven't found a significantly better one so far.

    This is how your Framework.User.WtfStory looks like when I cast it to LasVegas.Gambler.SobStory

    So you're saying that trying to find a decent web shop framework is like trying to find a casino where you can win money? I can relate to that.


  • Discourse touched me in a no-no place

    @FragFrog said:

    @FrostCat said:

    Sounds like the PHP way!

    I never really got that sentiment. If you want to cast a string to int in PHP, you write "(int) $string" and it's done. That also removes leading zeros (naturally).

    I will not deny there are many things wrong with PHP, but saying that it "only has one tool" is pretty much the exact opposite of what is wrong with it. Perl, now, is a one-tool language, and I would expect something like this there, but PHP? I can think of at least 5 ways to convert a string to an integer in PHP, all of them remove the leading zeros, and none use regexes.

    Whoa, whoa whoa[1]. No. I wasn't referring to a particular idiom. I meant this: PHP: a fractal of bad design.

    [1]That was, sadly, the best clip I could find. The original is a bit funnier, because it has a few more whoas.



  • @FrostCat said:

    @random said:

    Yep, instead of specifing the radix , they decided to remove leading zeros from the input using a regex.

    Sounds like the PHP way!

    The PHP hammer.

    [img]http://tnx.nl/php_small.jpg[/img]


Log in to reply