• Anonymous (unregistered)

    I nominate this article for the "worst pun in a title" award.

  • (cs)
    Alex Papadimoulis:
    It was Seth's first day on the job.

    Don't you mean Seth?

  • jason (unregistered)

    Maybe Gabe misheard somebody talking about ExcEmEl as a proven configuration technology...

  • (cs)

    Problems all around here.

    Ugly-arse way of storing/processing config data notwithstanding...

    The written instructions said to update the field with the new value. Nothing was mentioned regarding implied formatting. The user did a perfectly normal thing, didn't notice that the apostrophe showed up as part of the actual text, and saved it (can't really fault the user here).

    The validation code didn't take this likely scenario into account (though the developers claim a macro update would solve this).

    TRWTF is Gabe.

  • Yep (unregistered)

    This all looks awfully familiar..

  • JD (unregistered)

    The .NET framework includes a multitude of possibilities for storing and retrieving configuration settings. Problem is, the .NET framework has only been around for a few years and is not yet mature enough to be trusted for mission-critical functionality. This is why I prefer to use Multiplan for DOS. With 26 years of service under its belt, you just can't get a better time-tested solution.

    Anyway, time to update the address of our partner's billing web service...

    [image]
  • (cs)

    Sounds like Gabe is Canadian, eh?

  • Teh Irish Gril Riot (unregistered)

    It's stories like these that boost my morale at my current job.

  • Not Dorothy (unregistered)

    This may be the first case using Access would be an improvement (marginal though it is).

  • (cs)

    Hi everyone. I have been gone a while because I have been in training, and what I was in training for would be perfect to solve this problem: Filemaker Pro.

    There really isn't a problem that Filemaker can't solve better than Visual Basic OR any of the Office products that Microsoft has written.

    In fact I am in the process of converting our main business application to use Filemaker Pro right now, based on my recommendation after coming back from training.

    I just put all of our config information into Filemaker. Problem solved.

  • Wretch (unregistered) in reply to TopCod3r
    TopCod3r:
    Hi everyone. I have been gone a while because I have been in training, and what I was in training for would be perfect to solve this problem: Filemaker Pro.

    There really isn't a problem that Filemaker can't solve better than Visual Basic OR any of the Office products that Microsoft has written.

    In fact I am in the process of converting our main business application to use Filemaker Pro right now, based on my recommendation after coming back from training.

    I just put all of our config information into Filemaker. Problem solved.

    I agree. The real WTF is why anyone uses anything other than Filemaker for anything. It's the greatest.

  • a fan (unregistered) in reply to TopCod3r

    so...already busy on writing the third installment of MFD?

  • silent d (unregistered) in reply to Wretch
    Wretch:
    TopCod3r:
    Hi everyone. I have been gone a while because I have been in training, and what I was in training for would be perfect to solve this problem: Filemaker Pro.

    There really isn't a problem that Filemaker can't solve better than Visual Basic OR any of the Office products that Microsoft has written.

    In fact I am in the process of converting our main business application to use Filemaker Pro right now, based on my recommendation after coming back from training.

    I just put all of our config information into Filemaker. Problem solved.

    I agree. The real WTF is why anyone uses anything other than Filemaker for anything. It's the greatest.

    Of course Filemaker Pro is great for the front end, but I would think you'd want something really robust like Access as the back end.

  • Pramod (unregistered)

    Clearly their problem is they allowed their dumb users to type in apostrophes. All they had to do was install a Win32 hook that would intercept keystrokes sent to Excel and swallow invalid key entries. I suspect the OCR code to detect if cursor's on a text field would've been pretty elegant.

  • Anonymous (unregistered) in reply to TopCod3r
    JD:
    ...Multiplan for DOS...
    TopCod3r:
    ...Filemaker...
    Interesting - a "cross troll". What are the odds?
  • JD (unregistered) in reply to Anonymous
    Anonymous:
    JD:
    ...Multiplan for DOS...
    TopCod3r:
    ...Filemaker...
    Interesting - a "cross troll". What are the odds?
    Excuse me, but not trolling over here. Just exercising my sense of humour in a way that cannot possibly be taken seriously. This is not a troll, just a bit of light humour.

    I'm suprised that TC couldn't think of anything more original though ;)

  • kbiel (unregistered) in reply to silent d

    TRWTF is that they didn't use Cardfile which is easier than Excel, more proven, and has source code available.

  • (cs)

    Since it appears that the customer is expected to edit configuration information in their application, I don't really see a huge problem with using Excel here. Most office workers are familiar with Excel and Word.

    Many people know Access, but not quite as many as those that know Excel and Word. Even less know how to navigate a real database system.

    Other options for customer editable config information include:

    1. the registry, in which a user could really screw with the OS
    2. a proprietary config file format, in which a user could really screw up the custom parser
    3. XML, in which a user could easily forget to close a tag or something similia (although XML validators are common in most language distributions)

    The only true WTF from the application in the article is the lack validation before injecting a user input string into an SQL statement. I'll even give them a pass on any SQL injection arguments since the config file isn't web facing.

    Oh, and Gabe is an idiot.

  • (cs)

    Excel's VBA uses VB6 instead of VB.NET.

  • Tom JP (unregistered) in reply to mjk340
    mjk340:
    Since it appears that the customer is expected to edit configuration information in their application, I don't really see a huge problem with using Excel here. Most office workers are familiar with Excel and Word.

    Many people know Access, but not quite as many as those that know Excel and Word. Even less know how to navigate a real database system.

    Other options for customer editable config information include:

    1. the registry, in which a user could really screw with the OS
    2. a proprietary config file format, in which a user could really screw up the custom parser
    3. XML, in which a user could easily forget to close a tag or something similia (although XML validators are common in most language distributions)

    The only true WTF from the application in the article is the lack validation before injecting a user input string into an SQL statement. I'll even give them a pass on any SQL injection arguments since the config file isn't web facing.

    Oh, and Gabe is an idiot.

    Or... you know, number 4: Make a settings dialog? Like normal apps?

  • BJ Upton (unregistered) in reply to TopCod3r
    TopCod3r:
    Hi everyone. I have been gone a while because I have been in training, and what I was in training for would be perfect to solve this problem: Filemaker Pro.

    There really isn't a problem that Filemaker can't solve better than Visual Basic OR any of the Office products that Microsoft has written.

    In fact I am in the process of converting our main business application to use Filemaker Pro right now, based on my recommendation after coming back from training.

    I just put all of our config information into Filemaker. Problem solved.

    I've missed you so much. The site isn't the same without you.

    Captha: consequat - one of the lesser known citrus?

  • (cs) in reply to silent d
    silent d:
    Wretch:
    TopCod3r:
    Hi everyone. I have been gone a while because I have been in training, and what I was in training for would be perfect to solve this problem: Filemaker Pro.

    There really isn't a problem that Filemaker can't solve better than Visual Basic OR any of the Office products that Microsoft has written.

    In fact I am in the process of converting our main business application to use Filemaker Pro right now, based on my recommendation after coming back from training.

    I just put all of our config information into Filemaker. Problem solved.

    I agree. The real WTF is why anyone uses anything other than Filemaker for anything. It's the greatest.

    Of course Filemaker Pro is great for the front end, but I would think you'd want something really robust like Access as the back end.

    What about Filmmaker Pro?

  • Mark (unregistered) in reply to mjk340
    mjk340:
    Since it appears that the customer is expected to edit configuration information in their application, I don't really see a huge problem with using Excel here. Most office workers are familiar with Excel and Word.

    Many people know Access, but not quite as many as those that know Excel and Word. Even less know how to navigate a real database system.

    Other options for customer editable config information include:

    1. the registry, in which a user could really screw with the OS
    2. a proprietary config file format, in which a user could really screw up the custom parser
    3. XML, in which a user could easily forget to close a tag or something similia (although XML validators are common in most language distributions)

    The only true WTF from the application in the article is the lack validation before injecting a user input string into an SQL statement. I'll even give them a pass on any SQL injection arguments since the config file isn't web facing.

    Oh, and Gabe is an idiot.

    You're forgetting one other MAJOR alternative: Include a GUI in your application to let users alter configuration information. It's a standard part of any app, even web apps.

  • SomeCoder (unregistered) in reply to Tom JP
    Tom JP:
    mjk340:
    Since it appears that the customer is expected to edit configuration information in their application, I don't really see a huge problem with using Excel here. Most office workers are familiar with Excel and Word.

    Many people know Access, but not quite as many as those that know Excel and Word. Even less know how to navigate a real database system.

    Other options for customer editable config information include:

    1. the registry, in which a user could really screw with the OS
    2. a proprietary config file format, in which a user could really screw up the custom parser
    3. XML, in which a user could easily forget to close a tag or something similia (although XML validators are common in most language distributions)

    The only true WTF from the application in the article is the lack validation before injecting a user input string into an SQL statement. I'll even give them a pass on any SQL injection arguments since the config file isn't web facing.

    Oh, and Gabe is an idiot.

    Or... you know, number 4: Make a settings dialog? Like normal apps?

    Yeah, I was going to suggest this exact thing. Settings dialogs in .NET take like 10 seconds to create :)

  • (cs) in reply to SomeCoder
    SomeCoder:
    Yeah, I was going to suggest this exact thing. Settings dialogs in .NET take like 10 seconds to create :)

    And to make them dynamic and editable, you can put the dialog's controls into an Excel spreadsheet...

  • BottomCod3r (unregistered) in reply to Tom JP
    Tom JP:
    mjk340:
    Since it appears that the customer is expected to edit configuration information in their application, I don't really see a huge problem with using Excel here. Most office workers are familiar with Excel and Word.

    Many people know Access, but not quite as many as those that know Excel and Word. Even less know how to navigate a real database system.

    Other options for customer editable config information include:

    1. the registry, in which a user could really screw with the OS
    2. a proprietary config file format, in which a user could really screw up the custom parser
    3. XML, in which a user could easily forget to close a tag or something similia (although XML validators are common in most language distributions)

    The only true WTF from the application in the article is the lack validation before injecting a user input string into an SQL statement. I'll even give them a pass on any SQL injection arguments since the config file isn't web facing.

    Oh, and Gabe is an idiot.

    Or... you know, number 4: Make a settings dialog? Like normal apps?

    That'd waste so much dev time, it's not worth it. Just tell them which code file to edit. If they can edit a text file they can edit code.

  • Survey User 2338 (unregistered) in reply to kennytm
    kennytm:
    silent d:
    Wretch:
    TopCod3r:
    Hi everyone. I have been gone a while because I have been in training, and what I was in training for would be perfect to solve this problem: Filemaker Pro.

    There really isn't a problem that Filemaker can't solve better than Visual Basic OR any of the Office products that Microsoft has written.

    In fact I am in the process of converting our main business application to use Filemaker Pro right now, based on my recommendation after coming back from training.

    I just put all of our config information into Filemaker. Problem solved.

    I agree. The real WTF is why anyone uses anything other than Filemaker for anything. It's the greatest.

    Of course Filemaker Pro is great for the front end, but I would think you'd want something really robust like Access as the back end.

    What about Filmmaker Pro?

    Isn't Filemaker Pro redundant???

  • (cs) in reply to JD
    JD:
    I'm suprised that TC couldn't think of anything more original though ;)

    Sorry JD, I really didn't read any of the comments before I posted. Didn't mean to step on your toes ;)

  • Brompot (unregistered) in reply to kennytm
    kennytm:
    Excel's VBA uses VB6 instead of VB.NET.

    Yes, but the actual application was written in VB.NET, not the macros. Though why anyone would want to use VB.anything is a mystery to me. A text file and a shell script are a much more sensible solution for config files.

  • Sanity (unregistered) in reply to JD
    JD:
    Anonymous:
    JD:
    ...Multiplan for DOS...
    TopCod3r:
    ...Filemaker...
    Interesting - a "cross troll". What are the odds?
    Excuse me, but not trolling over here. Just exercising my sense of humour in a way that cannot possibly be taken seriously...

    Didn't you learn anything from the article? PHBs don't understand sarcasm!

    Seriously, FileMaker gives me nightmares. Among the more fun things I've seen:

    • An invoice system in a single table, meaning several rows per product (for that product's name, price, quantity this customer purchased...) I was called to help them fit it onto a single page.
    • A table which worked fine in FileMaker, but when queried via its SQL bridge, caused some script to go into an infinite loop. I say "some script" as an educated guess, because all other databases (or tables) worked just fine with a simple query.
    • The scripting engine, of course -- point and click, entirely. Ok, I get it -- easy to use. Also a royal pain compared to just typing in any text-based language.
    • The above and more, as mission-critical apps, that some semi-experienced users know how to tweak and script. If you think programmer cruft over the years is bad...
    • Proprietary, of course. The only fix for the above problems is, get them to export an XML file for you, open it with a text editor to make it valid, and import it into a brand-new, professionally-developed app.

    But hey, at least it's better than Excel.

  • (cs)

    Elegant. He keeps using that word... I do not think it means what he thinks it means.

  • C10B (unregistered)

    I've used filemaker pro on smaller projects for years. I've got a filemaker installation that's been running for 12 years and has never in all that time either crashed or gone wrong. It's noddy, but hell is it robust!

    You see it's not the tool that's the problem, like excel in this WTF, excel is great. It's the application that the tool is used for that's the problem.

  • revenant (unregistered)

    Excel, Filemaker, Access... Why don't they just hardcode the parameters into .exe, and use hex editor to change them? Saves a lot of time for developers. Even better, there is be a nonzero probability that when another excel expert types extra apostrophe in the hex editor, she would accidentally add new useful features to the program.

  • Anonymouse (unregistered)

    Your father's Microsoft Word. This is the weapon of a true programmer. Not as clumsy or random as Excel. An elegant solution, for a more civilized age.

  • NoWayAmILoggingInForThisOne (unregistered)
    There were three distinct ways to read values from the configuration file, but only two seemed to work.
    The third was File Not Found?
  • (cs) in reply to Anonymouse
    Anonymouse:
    Your father's Microsoft Word. This is the weapon of a true programmer. Not as clumsy or random as Excel. An elegant solution, for a more civilized age.
    Why not notepad.exe? Just layout the data in key=value format, one entry per line. Ignore blank lines and extraneous whitespace characters. Each group (stanza) can have a header surrounded by square brackets. Then, you just save the (text) file as .ini

    Your application can read this text file and parse all the values; which can be easily edited by a human being with only (128) ASCII characters to worry about!

  • (cs) in reply to snoofle
    snoofle:
    TRWTF is Gabe.

    Um, to quote myself when I was about 13, "No shit, Shirlock"

  • (cs) in reply to campkev
    campkev:
    snoofle:
    TRWTF is Gabe.

    Um, to quote myself when I was about 13, "No shit, Shirlock"

    And your spelling has not improved since age 13, eh?

  • (cs) in reply to ParkinT
    ParkinT:
    campkev:
    snoofle:
    TRWTF is Gabe.

    Um, to quote myself when I was about 13, "No shit, Shirlock"

    And your spelling has not improved since age 13, eh?

    No, you just missed the double insult of spelling Sherlock like Shirley, thereby calling him a girl as well. Yeah, that's it. That's the ticket.

  • Bizzle (unregistered)

    I was just thinking about how great it would be if TopCod3r came back. And what do you know, he did!

  • 5|i(3_x (unregistered) in reply to mjk340
    mjk340:
    I'll even give them a pass on any SQL injection arguments since the config file isn't web facing.

    I'm not so forgiving. Input is evil and should be treated with prejudice. It doesn't have to be intentionally malicious to be harmful: http://en.wikipedia.org/wiki/Hanlon's_razor .

  • ShatteredArm (unregistered)

    We thought of this idea where I work... What we would do is create a database table for user settings, and the application would read those settings from the database. Now here is the novel part: we actually created a UI using standard, out of the box ASP.NET controls, and this UI would actually allow users to change the application settings from their own workstations!

    We've already filed the patent application, so don't even try stealing it.

  • FMP FTW (unregistered)

    I know someone who would say all those great things about FileMaker Pro and mean them.

  • SwedishChef (unregistered) in reply to ParkinT
    ParkinT:
    Anonymouse:
    Your father's Microsoft Word. This is the weapon of a true programmer. Not as clumsy or random as Excel. An elegant solution, for a more civilized age.

    I lol'd!

    Why not notepad.exe? Just layout the data in key=value format, one entry per line. Ignore blank lines and extraneous whitespace characters. Each group (stanza) can have a header surrounded by square brackets. Then, you just save the (text) file as .ini

    Your application can read this text file and parse all the values; which can be easily edited by a human being with only (128) ASCII characters to worry about!

    The return of Mr Facepalm

    Swooooosh! ducks Spaceball One!

  • Zapakh (unregistered)

    I always die a little inside upon reading a Featured Article. This time, I died a lot. Well done!

  • Mark (unregistered) in reply to ParkinT
    ParkinT:
    Anonymouse:
    Your father's Microsoft Word. This is the weapon of a true programmer. Not as clumsy or random as Excel. An elegant solution, for a more civilized age.
    Why not notepad.exe? Just layout the data in key=value format, one entry per line. Ignore blank lines and extraneous whitespace characters. Each group (stanza) can have a header surrounded by square brackets. Then, you just save the (text) file as .ini

    Your application can read this text file and parse all the values; which can be easily edited by a human being with only (128) ASCII characters to worry about!

    So basically you're referring to the entire /etc directory in Linux.

    #
    # Port: The port to which the standalone server listens. For
    # ports < 1023, you will need apache to be run as root initially.
    #
    Port 80
    
    #
    # If you wish apache to run as a different user or group, you must run
    # apacheas root initially and it will switch.  
    #
    # User/Group: The name (or #number) of the user/group to run apache as.
    #  . On SCO (ODT 3) use "User nouser" and "Group nogroup".
    #  . On HPUX you may not be able to use shared memory as nobody, and the
    #    suggested workaround is to create a user www and use that user.
    #  NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
    #  when the value of (unsigned)Group is above 60000; 
    #  don't use Group nobody on these systems!
    #
    User www-data
    Group www-data
  • No you're not. (unregistered) in reply to TopCod3r
    TopCod3r:
    Hi everyone. I have been gone a while because I have been in training, and what I was in training for would be perfect to solve this problem: Filemaker Pro.

    There really isn't a problem that Filemaker can't solve better than Visual Basic OR any of the Office products that Microsoft has written.

    In fact I am in the process of converting our main business application to use Filemaker Pro right now, based on my recommendation after coming back from training.

    I just put all of our config information into Filemaker. Problem solved.

    sigh

    Would the real Top Cod3r PLEASE stand up?

  • Top Cod3r's D4d (unregistered) in reply to ShatteredArm
    ShatteredArm:
    We thought of this idea where I work... What we would do is create a database table for user settings, and the application would read those settings from the database. Now here is the novel part: we actually created a UI using standard, out of the box ASP.NET controls, and this UI would actually allow users to change the application settings from their own workstations!

    We've already filed the patent application, so don't even try stealing it.

    Son? Is that you?

  • Peter (unregistered)

    I fairly recently worked with a gentleman (no longer with the firm) who chose to use Microsoft Word as his preferred source code (ABEL PLD programming language, if you must know) editor. He had used text attributes (color, IIRC) to delineate comments, source lines and preprocessor directives.

    He had also written a clever set of scripts to remove comment lines and convert to plaintext before running the code into the ABEL compiler.

    His system only worked with a particular rev of Word, which he had on his personal Windows 2000 system (at home) and his rev-locked system at work (the IT folks loved him almost as much as I did).

    The boss told me that I was taking over his code when he went on vacation. I think he knew what would happen. All the same, I made sure it was OK with him. Changed all the source .doc files to plain text and edited them with VIM. Since I never handed the files back to my co-worker, he never had any problem with my changes, either.

    True story, I swear. The suggestion is still made (in jest) by some of the folks in the department, that we use Word to write the source code. I would never have believed it if I had not seen it myself.

  • (cs) in reply to kennytm
    kennytm:
    What about Filmmaker Pro?
    No, because you're not allowed to edit video. But you can perform random playback. with SSDS. I like to video in a configuration. To ExCell. Just press XXX. And Jam It!
    Bizzle:
    I was just thinking about how great it would be if TopCod3r came back. And what do you know, he did!
    Now I'm thinking about a nice turkey sandwich. [/stargateatlantis]

Leave a comment on “Waiting to Excel ”

Log In or post as a guest

Replying to comment #:

« Return to Article