• (disco)

    Rule number one of showcasing your work: remove all non-functional buttons.

    People can see the feature is "done" and no amount explaining can convince them otherwise.

  • (disco) in reply to JBert

    If you remove them you may forget to finish them, I'd just leave them there but disabled. But yeah, good point.

  • (disco) in reply to LB_
    LB_:
    I'd just leave them there but disabled

    Or make them pop up a dialog saying “Not yet implemented”.

    And never implement functionality that lets you delete everything with one click. No production interface ever ought to have that capability; too Belgium­ing hazardous…

  • (disco) in reply to dkf
    dkf:
    And never implement functionality that lets you delete everything with one click.
    *shifty eyes* I've never done that on accident, no siree! (Insert link to status thread detailing how a missing comment managed to wipe the table, in this case accomplishing the same thing as the article, but backwards)
  • (disco)

    While it appears to be de rigueur to give a junior dev a lambasting for having a dangerously incomplete button on a page, TRWTF is Tim, butting in on a dev session unannounced and unscheduled, pressing buttons at random on a still-under-development application.

    It happens all the time. Happens to me on a regular basis, someone comes waltzing up to tell me an unfinished web page looks rubbish because I haven't done the styling. It's the same mentality that has people swanning onto a building site and complaining that the floor's all muddy and the joists are visible.

  • (disco)

    I think the real WTF is to have a dev machine connected to an actual production database, especially if it's not read-only access.

  • (disco) in reply to Quite

    I would agree to an extent. I don't think there is ever a reason to have a button that does an unconstrained delete on a database, even if you are developing (unless the button has a label along the lines of "Wipe Table"). But at the same time, Tim has the bigger WTFs. Why would you click a delete button on an incomplete interface without checking first, and more to the point, why are your developers working on production? That is just asking for trouble!

  • (disco) in reply to Quite

    The look on some people's faces after you exclaim "A-HA! Crashed! Excellent!" is priceless, though.

  • (disco) in reply to Nocha
    Nocha:
    I would agree to an extent. I don't think there is ever a reason to have a button that does an unconstrained delete on a database, even if you are developing (unless the button has a label along the lines of "Wipe Table"). But at the same time, Tim has the bigger WTFs. Why would you click a delete button on an incomplete interface without checking first, and more to the point, why are your developers working on production? That is just asking for trouble!

    Particularly as Tim knows the app is connected to the Production database, he is bound to be careful of a button saying "Delete". As a junior dev, it is not Scott's call to involve in configuration (mis)management.

  • (disco)

    Raise your hand who never had similar "delete" accident on production :smile:

  • (disco) in reply to ThieMaster

    Me with bank production database login:

    http://s3.amazonaws.com/images.hitfix.com/assets/8675/scrooge-mcduck-e1363347903905-640x362.jpeg

  • (disco) in reply to martin
    martin:
    Raise your hand who never had similar "delete" accident on production :smile:

    :wave:

    Though I had to fight tooth and nail recently for that, because someone wanted to start using the application already despite it being deep in test phase, so they tried to just push everyone to prod and shut the dev environment down, because why manage two servers when you can manage one?

    I told them to go fuck themselves, I'm not pointing my potentially buggy application at production, especially not while I'm developing it, especially not when I have no idea where I can put test data so that they don't interfere, and if they shut down our dev environment I'll just stop doing features and start making mocks.

    Then, of course, it turned out some people have been using the test version of the application running on the dev database to do their reports anyway, so...

  • (disco)

    Please, the problem is not the button, the query or the PM. TRWTF is the whole database setup. Not only the delete, but guy was also running not optimized queries and inserting dummy data. Just plain stupid.

  • (disco) in reply to Nocha
    JBert:
    Rule number one of showcasing your work: remove all non-functional buttons.

    Well, yeah...if you have warning you're going to be showcasing your work...

    ThieMaster:
    I think the real WTF is to have a dev machine connected to an actual production database, especially if it's not read-only access.

    No kidding. That's TR :wtf: here...testing, once again, in production. Sigh. When will they learn?

    Nocha:
    I would agree to an extent. I don't think there is ever a reason to have a button that does an unconstrained delete on a database, even if you are developing (unless the button has a label along the lines of "Wipe Table"). But at the same time, Tim has the bigger WTFs. Why would you click a delete button on an incomplete interface without checking first, and more to the point, why are your developers working on production? That is just asking for trouble!

    There's no reason for it, but it can happen in development code. Here's a goodie of mine in Rexx that nearly destroyed the testing database.

       query = 'update shared_table' ,
           'set code = ?'
           'where group = ? and method = ?'

    Now, you noticed the missing continuation comma right off, right? The one that meant the "update" did not have a "where" clause? Neither did I. Fortunately, I was saved by the fact that "code" was a key of a unique index and setting all the rows of the table to the same value for "code" wasn't possible (failed). But that is why I now do this with all my Rexx queries:

       query = ( ,
             'update shared_table' ,
             'set code = ?' ,
             'where group = ? and method = ?' ,
           )

    (If a continuation comma is left out, this becomes an expression with imbalanced (), which causes the script to fail with a syntax fault.)

    Anyway, the important lesson here is that we learn this stuff by experience.

  • (disco) in reply to martin
    martin:
    Raise your hand who never had similar "delete" accident on production

    Well, let's just say I learned how dangerous "ON DELETE CASCADE" can be.*

    *It was technically correct, but I accidentally made the foreign key point to the "cache" table that was re-created from the actual table every month. TRWTF is that MySQL doesn't support proper materialized views…

  • (disco) in reply to dkf
    dkf:
    And never implement functionality that lets you delete everything with one click. No production interface ever ought to have that capability; too ■■■■■■■­ing hazardous…
    He didn't. He had a button that let you delete *one thing* with one click--which actually makes perfect sense--and the manager just happened to come by at the one disastrous moment when, for debugging purposes, he had commented out the WHERE clause and not yet rewritten it.

    You know similar "this could destroy everything" moments have happened to you from time to time; you just didn't have someone show up and actually hit the Big Red Button at the worst possible moment. Right?

  • (disco) in reply to martin

    That depends... are you referring to in your day job or on a toy project?

    If the former... raises hand

    Then again, for the past 10+ years, I always write a DELETE statement as a SELECT statement first to see what it will affect.

  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    ``` query = ( , 'update shared_table' , 'set code = ?' , 'where group = ? and method = ?' , ) ```
    Is that language as shitty as it looks?
  • (disco) in reply to ChrisH
    ChrisH:
    CoyneTheDup:
    ``` query = ( , 'update shared_table' , 'set code = ?' , 'where group = ? and method = ?' , ) ```
    Is that language as shitty as it looks?

    Is , in Rexx like _ in VB?!

  • (disco) in reply to aliceif
    ChrisH:
    Is that language as shitty as it looks?

    Well, that depends on your religion, mostly. It has a few ugly moments, of which continuation comma is one of the worst.

    But as a glue language, like TCL, it's pretty powerful; I've done some pretty heavy scripts in it.

    aliceif:
    Is , in Rexx like _ in VB?!

    Yes..and no. It is used the same way, to continue statements (last non-blank on a line). But to make it miserable, comma also is used as a parameter separator in "call" and function references:

       call my_routine parm1,,
                   parm2,,
                   parm3, parm4

    That's four parameters, with continuation comma on the end of the first two lines; the other commas are parameter separators. Really easy to sort that out, isn't it?

    Rexx is often clever in its structure, but Mr. Cowlishaw should have been made to suffer for his choice of continuation characters.

    SQL statements are some of the worst because they're often long. Otherwise, you don't need to use continuation all the time.

  • (disco)

    TRWTF is newbie developer given access to build a new app and test on a production database with no supervision

  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    query = 'update shared_table' , 'set code = ?' 'where group = ? and method = ?'

    I inherited a script which I foolishly ran without arguments. Whoever had programmed it didn't think of this case, because without arguments the script simply deleted everything rather than the specified subset (I think it was by date).

    We didn't have best practises. The script directly called from the production server. As root user.

    I restored the data from the dev server. Nobody ever found out.

    The part I'm still trying to remember is the syntax. The where clause (in MySQL) would have been intact but for the empty value. Maybe it was wrapped in a LIKE '% + string + %' or something.

  • (disco)

    This quote just got better:

    blakeyrat:
    Fucking Tim.
  • (disco)
  • (disco) in reply to Mason_Wheeler
    Mason_Wheeler:
    He didn't. He had a button that let you delete one thing with one click--which actually makes perfect sense--and the manager just happened to come by at the one disastrous moment when, for debugging purposes, he had commented out the WHERE clause and not yet rewritten it.

    So he did have a delete-everything button, even if just transiently. ;)

  • (disco) in reply to martin

    raises hand

    In my now almost 15 years doing development and maintenance on data acquisition systems i have done:

    segfaulted the main data logging server program (writing and reading fro GPIB) by asking for channel 0 (the program had no bounds check on the array containing the channels it knew) and at that time, i was quite new and did not know the system well, so had to call the senior dev (it was evening) in order to find out how to start it again (no measurements could be performed while the server program was not running).

    Rebooted the main database server unintentionally (was only off line for 30 seconds, but boy did it feel like a long time.....)

    as well as:

    rm * (as root, on one of the data acquisition servers, and while in /etc. ) it was intended to be in an other window, but luckily we DO have good backups and only a few noticed that one :-)

  • (disco) in reply to Yazeran
    Yazeran:
    only off line for 30 seconds

    FML, most of my server-type stuff takes orders of magnitude longer to reboot. Lets see, about 5 minutes from cold boot for the file server, two minutes after that to start the embedded media and web services, three minutes after that for Domain services (if it's not doing Windows Updates), and at least five minutes for everything else after that (other toys and VMs et al).

  • (disco) in reply to JBert

    The button was irrelevant. It'd have happened sooner or later. Untested software connected to the production database = death.

  • (disco) in reply to Yazeran
    Yazeran:
    Rebooted the main database server unintentionally (was only off line for 30 seconds, but boy did it feel like a long time.....)

    30 seconds? What DBMS were you using?

    Goddamned. SQL Server won't boot in 30 seconds on the world's fastest computer and SSD even if it didn't have to go through and double-check the transaction log. Unless your database was minuscule, on a SQL Server box I'd expect close to 30 minutes before it was ready to go again.

  • (disco) in reply to blakeyrat
    blakeyrat:
    What DBMS were you using?

    Little known technology called "Load .csv file to RAM". :trolleybus:

  • (disco) in reply to Tsaukpaetra

    Along that line, we're using a proprietary read-only key-value store which is ready for use after less than a millisecond.

  • (disco) in reply to PleegWat

    I've developed a super-fast database for my product, it's called "having no customers at all".

  • (disco) in reply to blakeyrat

    The primary is on oracle, which can be slow as molasses at times. The key-value stores are cache, and much faster, especially for those binaries where it completely replaces the database connection.

  • (disco) in reply to blakeyrat
    blakeyrat:
    SQL Server won't boot in 30 seconds on the world's fastest computer and SSD even if it didn't have to go through and double-check the transaction log.

    Even a many-GB Progress database server will start up in under a minute, but that's partially because it does a lazy startup. The first thing it does is bring up a broker, which spawns extra server processes on demand.

  • (disco) in reply to blakeyrat

    Well we are not that database intensive. All our research data are stored in normal flat text files in order for the data to be always readable and not prone to vendor lock-in. The efect is that we have the data online even for experiments done 10 years ago even though the data has been moved to new hardware twice since aquisition.

    Our main database in our department (which is the only ones I have access to) is a postgresql on a linux system running on consumer hardware worth roughly 800 Euro. The data is roughly 300 MB, and I expect that the type of RDBMS does not matter much for such a small db.

    The database handles user permissions and safety information for our test systems as well as our reservations system and work request system ans other small administrations systems with the important part being the user permissions (without that dab running no-one could log in to our test systems and change conditions for anyone of our 70+ experimental systems.....)

  • (disco) in reply to Quite

    Hey, it works for James Bond. Swanning into Q's lab to play with all the newest toys.

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    FML, most of my server-type stuff takes orders of magnitude longer to reboot. Lets see, about 5 minutes from cold boot for the file server, two minutes after that to start the embedded media and web services, three minutes after that for Domain services (if it's not doing Windows Updates), and at least five minutes for everything else after that (other toys and VMs et al).

    The worst is spending $50,000 on an HP server with all the bells and whistles just to spend the same five minutes watching the POST screen as on a $500 server. Meanwhile my HP desktop would be logged in within 10 seconds. HP really badly needs to work on their server hardware boot times.

  • Axel (unregistered)

    TIL a new word: "swanning": to move or go about in a casual way. Never heard it before.

    Thanks, TDWTF!

Leave a comment on “Don't Click That”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article