Close Encounters of the WTF



  • <background story>

    I work in a small web debelopement company based in switzerland.
    Despite our small size, we managed to get big customers, I won't cite them.
    As an intern I don't get the most glamorous tasks but I think i'm almost the only sane person in this company.

    In some of my co-workers code I once found this:
    $time = mktime(substr($strdate, 0, 2), substr($strdate, 3, 2), substr($strdate, 5, 2), ...);

    The apropriate would be:

    $time = strtotime($strdate);

     </background story>

    But that's a minor WTF compared to the one I encountred today. We manage the After Sales Service (No I won't use the acronym) for a big luxury watch company i will call the SWatch. The SWatch After Sale Service is a perl-cgi WebApp with a MySQL db that imports flat text files (Like CSV but not CSV) from their ERP system. As you probably guessed this is my job to keep it working and that's not easy.
    But recently, after multiple debates, we finally are allowed to re-build it from scratch. Well that's what I hoped until we got their "requirements" (29 pages, mostly text).

    With one of the elder developers who I converted to ZendFramework we convinced my boss that it was the best solution to avoid the maintenance nightmare.

    From what de de-cyphered from the requirements we will have to deal with a webservice that is interfaced with their internal web server to manage authentication and retreive a local copy of their data to our MySql server. A Crontab would periodically update the data in background.

    After they got to audio conference with the SWatch I asked the developer to give me a feedback about what has been decided.
    He announced me that we had to deal with an MsSql server 2005 that is interfaced with their ERP.
    To illustrate this I will give you a small picture:

    Object select/insert/delete will be done via stored procedures on the mssql server. So now we have to replace the Zend_Db_Table abstraction layer by one that supports the use of stored procedures for object interaction.

    Stay tuned I'm sure there will be plenty of others on this project



  • @ltouroumov said:

    $time = mktime(substr($strdate, 0, 2), substr($strdate, 3, 2), substr($strdate, 5, 2), ...);

    The apropriate would be:

    $time = strtotime($strdate);

    The ... in mktime(): they're passing every param after substr()'ing it out of the text date?  Otherwise, I could see that they just want part of the date but not all of it so strtotime() wouldn't work.  More likely is they just forgot strtotime() exists, which is a pretty minor WTF.  If they didn't know about it in the first place, that's a bit more WTFy.



  • @morbiuswilters said:

    The ... in mktime(): they're passing every param after substr()'ing it out of the text date?  Otherwise, I could see that they just want part of the date but not all of it so strtotime() wouldn't work.  More likely is they just forgot strtotime() exists, which is a pretty minor WTF.  If they didn't know about it in the first place, that's a bit more WTFy.

    In this case they substr() every part of the date to put it in mktime. I agree this is a minor WTF. 



  • @ltouroumov said:

    <background story>
    Invalid XML detected!  Parser stopping.



  • @ltouroumov said:

    Object select/insert/delete will be done via stored procedures on the mssql server. So now we have to replace the Zend_Db_Table abstraction layer by one that supports the use of stored procedures for object interaction.
    So the TWTF is that you are going to have to use SPs with a system that doesn't understand SPs? So you have to roll your own interface layer? Isn't that what programming is all about - connecting things together?



  • @bstorer said:

    @ltouroumov said:

    <background story>
    Invalid XML detected!  Parser stopping.

    It gets worse: the part that follows isn't enclosed in tags at all!



  •  @OzPeter said:

    So the TWTF is that you are going to have to use SPs with a system that doesn't understand SPs? So you have to roll your own interface layer? Isn't that what programming is all about - connecting things together?

    TWTF is that it adds a lot of developement time and we are already Überloaded of work and short on a lot of deadlines.

    The problem is that our infrastructure is entirely Unix based and we're gonna need a dedicated server to run only MSSQL with WinServer. They will manage all the stored procedures but we need to keep it working.

    Bah for the money they give us we can make a little exception. The positive point is that we'll charge them lots of money (to buy aspirin).



  • @ltouroumov said:

     @OzPeter said:

    So the TWTF is that you are going to have to use SPs with a system that doesn't understand SPs? So you have to roll your own interface layer? Isn't that what programming is all about - connecting things together?

    TWTF is that it adds a lot of developement time and we are already Überloaded of work and short on a lot of deadlines.

    The problem is that our infrastructure is entirely Unix based and we're gonna need a dedicated server to run only MSSQL with WinServer. They will manage all the stored procedures but we need to keep it working.

    Now I am confused. You - a Unix shop - are going have to host a MSSQL machine (and probably have very little in house expertise to do it) in order to host some specific SPs that will be controlled/maintained by the SWatch people in order to effectively implement a web service between your shop and SWatch?? And you have already spent a large amount of development time on a system that doesn't deal with SPs in the first place?? Is that what it amounts to? If so, that is crazy talk.



  • @OzPeter said:

    Now I am confused. You - a Unix shop - are going have to host a MSSQL machine (and probably have very little in house expertise to do it) in order to host some specific SPs that will be controlled/maintained by the SWatch people in order to effectively implement a web service between your shop and SWatch?? And you have already spent a large amount of development time on a system that doesn't deal with SPs in the first place?? Is that what it amounts to? If so, that is crazy talk.

    There should be some kind of website where people can tell of outlandish technical and management failures like this.



  • @OzPeter said:

    Now I am confused. You - a Unix shop - are going have to host a MSSQL machine (and probably have very little in house expertise to do it) in order to host some specific SPs that will be controlled/maintained by the SWatch people in order to effectively implement a web service between your shop and SWatch?? And you have already spent a large amount of development time on a system that doesn't deal with SPs in the first place?? Is that what it amounts to? If so, that is crazy talk.


    I probably wrote this the wrong way but the coding itself has not begun yet. It's just meetings, planning, cost estimates, etc. We have to re-build the application from scratch and it has already been planned to about 4 to 5 weeks without testing and demos (do frontend but not backend we need to show fancy stuff not creepy table listings).

    You have to add a "hoster" layer because we don't really maintain our servers in-house.
    So we have to ask our hoster to setup a MSSQL server that will be maintained by us but controlled by SWatch. The Application itself will be PHP/ZF based on a Unix server that will communicate with the MSSQL server. To retreive objects from the Database (maintained by SWatch) we will need to use stored procedures (maintained by SWatch) instead of SELECT/INSERT/UPDATE queries. To do that we need to replace the Zend_Db_Table layer by a custom Data Abstraction Layer that will use the stored procedures.


  • Garbage Person

    @ltouroumov said:

    To do that we need to replace the Zend_Db_Table layer by a custom Data Abstraction Layer that will use the stored procedures.
    This is the only stupid part. Use a framework better suited to your situation.

     And I'm not sure I can appreciate the existence of a framework that isn't compatible with stored procedures out of the box. Of course, this IS PHP we're talking about.



  • @ltouroumov said:

    To do that we need to replace the Zend_Db_Table layer by a custom Data Abstraction Layer that will use the stored procedures.

    I'm currently deeply involved in another thread trying to convince some people that stored procedures are an inferior solution to an easily solved problem, so you'd think I'd agree with you.  But, any abstration layer that has a hard time actually abstracting data access is the real WTF.  The whole point of having an abstraction layer is so that you can tweak it to match any implementation.  I couldn't imagine it would take more than a few days to write a few Perl scripts that could generate the entire abstraction layer from the database schema.



  • @ltouroumov said:

    $time = mktime(substr($strdate, 0, 2), substr($strdate, 3, 2), substr($strdate, 5, 2), ...);

    It looks entirely appropriate to me, if you don't trust the local settings of the machine where you run strtotime().  This method explicitly grabs each date field from its expected position in the input string and doesn't misinterpret 12/4 as December 4th while 13/4 is converted to April 13th.  This is also useful if you don't control the system producing the original string and it has non-standard seperator characters that strtotime can't cope with (dots, spaces, no spaces, nonstandard am/pm...)

    This is also a bit cargo-cultish.  I used to have problems with this on some system I've forgotten back in the Windows 3.1 days, so I keep doing it now even though strtotime() is much smarter now.  I don't consider it to be a WTF example of cargo-culting.



  • @morbiuswilters said:

    There should be some kind of website where people can tell of outlandish technical and management failures like this.


    OK: game over. morbius has definitely won this thread!



  • @Qwerty said:

    It looks entirely appropriate to me, if you don't trust the local settings of the machine where you run strtotime().  This method explicitly grabs each date field from its expected position in the input string and doesn't misinterpret 12/4 as December 4th while 13/4 is converted to April 13th.  This is also useful if you don't control the system producing the original string and it has non-standard seperator characters that strtotime can't cope with (dots, spaces, no spaces, nonstandard am/pm...)

    This is also a bit cargo-cultish.  I used to have problems with this on some system I've forgotten back in the Windows 3.1 days, so I keep doing it now even though strtotime() is much smarter now.  I don't consider it to be a WTF example of cargo-culting.

    In other part of the code strtotime($date); is used.

    From the PHP documentation:

    @PHP Manual said:

    int strtotime (string $time[, int $now] )

    The function expects to be given a string containing a US English date

    format and will try to parse that format into a Unix timestamp (the number of seconds since January 1 1970 00:00:00 UTC), relative to the timestamp given in now, or the current time if now is not supplied.

    From what I read the date format to read is always US English date and in the DB the data are in US English date format.

    But you're right it also looks like superstition.



  • @ltouroumov said:

    <background story>

    I work in a small web debelopement company based in switzerland.
    ....

    In some of my co-workers code I once found this:
    $time = mktime(
     
     
    pbbbbt.. like the Swiss know anything about time... 


  • @ltouroumov said:

    @OzPeter said:
    So the TWTF is that you are going to have to use SPs with a system that doesn't understand SPs? So you have to roll your own interface layer? Isn't that what programming is all about - connecting things together?

    TWTF is that it adds a lot of developement time and we are already Überloaded of work and short on a lot of deadlines.

     

    Oh, I'm sorry, I thought you wrote somewhere that you worked for a business? I am sure your boss is very suportive and will be very appriciative of the unpaid overtime  and might even celebrate at the end of the development cycle by ordering free pizza's for everyone.

     

    Now on to the actual interesting bit.

    strtotime can be dangerous. It doesn't "just" expect US date format, it will swallow just about everything you throw at it. including and not limited to random int values that get interpretted as timestamps. Now the intersting line of code is the one where it is verified that the variable contains an actual date, I don't care how hard some spec defines that the value will always be a correctly formatted date, without validating that first you (or more likely your co-workers) are just inviting intersting debugging sessions in the future. If said line exists then as far as I'm concerened it's a moot point if you use mktime or strtotime, although I would imagine that mktime is technically faster.
    But even then, putting all those substr's in the mktime call is just fugly. 


    Now on the the least intersting bit.

    The setup sounds  wonderfully convulate, but just remember, as terry chay once said, PHP is like a ball of nails, you throw it against the wall and it sticks. Now I forgot what this was a metaphor for, but it fits anyway. Just as long as you don't try to over engineer the solution you can pretty much keep even the most insane combination of parts working perfectly with an easy to maintain code base.

    Having said that, zend framework is still on my to-do list of stuff I need to pick up because everyone and his dog is asking for it today,but my own personal gut feelling is that a lot of it actually suffers from over engineering, but then again, if it doesn't force me to use all their pattern heavy "solutions" it is probably workable. (unless said solution is actually needed to solve something)

    But I doubt they don't support calling stored procedures. Heck, I doubt they don't support that custom CSV format. This is PHP were talking about.



  • @stratos said:

    convulate
     

    zuh?

    convoluted? convolved?

     



  • @dhromed said:

    @stratos said:

    convulate
     

    zuh?

    convoluted? convolved?

     

    -edit-

     Other spelling mistakes and typo's from my previous reply for your amusement.

    - suportive
    - appriciative
    - interpretted
    - intersting
    - concerened
    - feelling
    - intersting

     



  • @morbiuswilters said:

    There should be some kind of website where people can tell of outlandish technical and management failures like this.

    You don't want to go there. First, it runs on an outdated free version of community server...


  • @alegr said:

    You don't want to go there. First, it runs on an outdated free version of community server...
     

    And the difference between a mod and a troll is damn hard to tell.



  •  A delusion, in everyday language, is a fixed belief that is either false, fanciful, or derived from deception


Log in to reply