• Matthijs (unregistered) in reply to pif
    pif:
    > sane systems implement functionality in a library or batch-mode program first and build the GUI on top

    You may s/sane/Unix/.

    Yeah.. except for that little issue that a lot of Unix programs never really seem to grow past the library / batch-mode stage, or with a GUI that is really spiffy but has about half the functionality and tends to crash every five minutes, and then what should be a two-click operation turns into a half-hour manpage search and a string of command-line arguments that would scare the heck out of any nethack player.

  • Art (unregistered)

    Unix is like a lawn mower. It is great for when you want to do the same operation to 100,000 blades of grass. However, if you don't know what you're doing, and you aren't careful, you can cut off your own toes.

    Windows is like a fingernail clipper. It is very easy to figure out how to clip that first blade of grass. If you only ever do one, you're fine. But if you ever want to scale up... well try mowing your lawn with a nail clipper and you'll understand why Unix people hate the hell out of everything from a certain glitzy but clueless vendor.

  • Meep (unregistered) in reply to pif
    pif:
    > sane systems implement functionality in a library or batch-mode program first and build the GUI on top

    You may s/sane/Unix/.

    Captcha: immitto; indeed, I'm "immitting" my comment.

    Right, plenty of systems, like Unix, implement functionality in a library etc. and are still bat-shit crazy.

    Just not as barking mad as Windows.

  • A. Nonymous (unregistered)

    I wouldnt think twice about firing the developer in question. Even thinking about running excel on the server... And he kind of cheated the task to fulfill the requirement that business logic should be reusable. His implementation clearly is not reusable at all. And he must be aware that he cheated. No mercy for him!

  • Meep (unregistered) in reply to Jack
    Jack:
    pif:
    > sane systems implement functionality in a library or batch-mode program first and build the GUI on top

    You may s/sane/Unix/.

    That's pretty much a tautology.

    In other words, s/sane/Unix/g

    You've either never used Unix, or you're insane. Not that there's anything wrong with either possibility.

  • Huzzah (unregistered) in reply to Art
    Art:
    Unix is like a lawn mower. It is great for when you want to do the same operation to 100,000 blades of grass. However, if you don't know what you're doing, and you aren't careful, you can cut off your own toes.

    Windows is like a fingernail clipper. It is very easy to figure out how to clip that first blade of grass. If you only ever do one, you're fine. But if you ever want to scale up... well try mowing your lawn with a nail clipper and you'll understand why Unix people hate the hell out of everything from a certain glitzy but clueless vendor.

    Nice Analogy.

    I think (sort of related) that MS's biggest mistake has been trying to accomodate the dumb user. The more a system is designed for dumb people, the dumber your userbase becomes.

    Admittedly, UNIX can be a little too unforgiving for home users (sometimes it would be nice if "rm" had some failsafe - either prompting the user or having a temporary Recycle Bin type thing) - although I think the GUI interfaces for it (which I'm guessing is the less technical people would use) have those sort of measures in place....

    The one that has caught me out many, many, many, many times on UNIX (to the point where I aliased the commands) was crontab -r (for some reason I have "r" in my head as READ not REMOVE)....

  • Bill (not that one) (unregistered) in reply to Art
    Art:
    Unix is like a lawn mower
    and you'll have problems if you try to use it for a nail clipper. Nobody ever said it was good for that. Plus, you'll probably lose a finger.

    Really, I think one of the biggest mistakes of Linux developers is joining the dumb-it-down stampede to the point where people expect it to play games and imitate their familiar GUI, candy-coated-bug for bug.

  • Jack (unregistered) in reply to Meep
    Meep:
    You've either never used Unix, or you're insane.
    s/sane/Unix/
    You've either never used Unix, or you're inUnix.
    Huh???
  • VictorSierraGolf (unregistered) in reply to Bill (not that one)
    Bill (not that one):
    Really, I think one of the biggest mistakes of Linux developers is joining the dumb-it-down stampede to the point where people expect it to play games and imitate their familiar GUI, candy-coated-bug for bug.
    Bill (not that one):
    where people expect it to play games and imitate their familiar GUI, candy-coated-bug for bug.
    Bill (not that one):
    play games and imitate their familiar GUI

    This. Also, you forgot lots and lots of eye-candy.

    To be honest, I want to visit every KDE developer and kick thier face in.

  • Mr.Bob (unregistered) in reply to Little Bobby Excel
    Little Bobby Excel:
    emaNrouY-Here:
    I'm wondering if an enterprising hacker would be able to insert a little code injection into those forms and have excel pwn the web server.
    Exactly. This situation does not call for persuading management to do The Right Thing, because they've already demonstrated that their comprehension of such matters has drifted inside the event horizon of a black hole.

    Instead, this is where compliance is your friend. If you can't get them on the license* nonsense, go to an unsecured wi-fi and use TOR to upload a malicious spreadsheet that splatters ugly colors all over the place but does no real harm. (They need to see the threat to understand it.) Then arrange for your company's auditor to hear that OMFG our server was haxxor3d!! Stand back and watch in amazement as idiots get fired and management takes a day off from playing golf to try to figure out WTF is going on.

    • Seriously, if paying good money for something that's available free doesn't bother you, then what about the legal risk? And all the hassle of license management? Free software is so much better even if the only thing it adds is freedom from the abuse heaped upon you by license-checking mechanisms

    My surly and pessimistic side predicts that this scenario would play out differently. Instead of being called out for their ineptitude, management will throw the admins and developers under the bus for "allowing" such a security hole to exist.

    Prove me wrong, kind sir...

  • (cs) in reply to TheCPUWizard
    TheCPUWizard:
    Microsoft Office Licenses specifically prohibit the applications from being used in a Server Environment.
    WTF are you on about? Office installed in a Terminal Services environment is completely allowed and useful. The end user needs a valid license for Office, though. You can't license office for a single server.

    You didn't hear me say that makes it any easier.

  • (cs)

    In the project I'm currently working on, there is a component for which I've managed to preserve the designation Custom Role Assignment Package. It's one of the few things about the project that makes me happy.

  • foo (unregistered) in reply to Huzzah
    Huzzah:
    Admittedly, UNIX can be a little too unforgiving for home users (sometimes it would be nice if "rm" had some failsafe - either prompting the user
    I thought "alias rm='rm -i'" was the default on most systems these days ...
    or having a temporary Recycle Bin type thing) - although I think the GUI interfaces for it (which I'm guessing is the less technical people would use) have those sort of measures in place....
    Yes. But indeed, a system-wide recycle bin would be a big improvement.
  • (cs) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    I don't see the WTF here. I mean, Excel is Turing-complete, right? Party on!
    It's more than Turing-complete. It's self-aware.
  • Abe (unregistered)

    This brings memories. Decade ago I was working for a company which abused Lotus Notes into performing unimaginable things. We had a set of "web applications" which was total mess of lotus forms printing HTML full of IFRAMEs and Javascript. A big "colorizing" function (as we called it) was triggered from onLoad(), scanned the html and changed the look of fields, buttons and many other objects. Validations were all also done by Javascript on the client browser, by which I mean IE only. And of course, there was a button which triggered a Loutsscript Agent running on the Domino server, which summoned up some data, invoked the Excel (yes, installed on the server), filled the data in, saved XLS into a temp directory and then attached the XLS to the LotusNotes document the user was working with. I remember having long argument with my boss about the "IE only", he literally swore that it will never be ran on anything else than IE. Recently, an ex-colleague told me that few months after I left he was assigned to make it work with Firefox. Yeah. He said wanted to kill me.

  • Iain (unregistered) in reply to Code Master
    Code Master:
    LoremIpsumDolorSitAmet:
    I was expecting the story to end like this: he found out that the spreadsheet just did simple multiplication and addition, so he simply inlined the calculation into the code and got rid of the Excel nonsense altogether. Wishful thinking, apparently!

    In my experience the excel spreadsheet would be running several VBA add ins, and few COM libraries, plus maybe some xlls, and the calculation would involve calling serveral of these. Replacing this functionality in your code would be difficult assuming it wasn't all documented (fairly safe assumption).

    And those of us who have experienced it know that TRWTF beyond all other WTFs is when a simple Excel formula/macro that some business person spent years on (yes, that juxtaposition of simple and years is deliberate) somehow becomes enterprise critical because their clueless colleagues have come to depend on it.

  • (cs) in reply to WC
    WC:
    It's an excel spreadsheet. It's got formulas in it. Turn them into server-side code and eliminate all that craziness.

    I've written some seriously crazy Excel formulas in my day, but every one of them would have been a lot easier in a normal language that would run on that server with no problems.

    The client side has Excel. You need to implement, on the server side, the notion of a spreadsheet, possibly multiple worksheets, as a DAG and the formulae as relationships between them, and get these formulae to recalculate when the data changes.

    Not trivial to do.

  • turist (unregistered)

    This would make a great scenario for advertising MS SharePoint Server with Excel Services -- they allow you to do exactly this (drive calculations through Excel) in a somewhat more sensible manner.

  • Tom (unregistered)

    Well I don't know what happened, exactly. I mean, I put the spreadsheet on the server like we discussed, but then the server immediately crashed. Next, everybody started calling in saying that their spreadsheets wouldn't open -- every computer, every spreadsheet! They were all just getting a pop-up that said "license violation". I've heard the software vendors have crazy new ways to "validate" your "genuine" software but I never heard of this before.

    No, I haven't tried deleting the spreadsheet from the server.

    You really think so?

    OK... how about now?

    Excel is working again? And you're sure you didn't do anything different? Wow. Ask someone near you to try a spreadsheet. Yeah? OK then I guess we're good.

    Great idea, by the way, deleting the spreadsheet from the server. I'm going to tell all the techies I know about your insightful solution.

  • Neil (unregistered) in reply to foo
    foo:
    a system-wide recycle bin would be a big improvement.
    Novell Netware had undelete back in the 1980s. If you weren't careful your disk would run out of directory entries for deleted files. (One of the volume repair options was to purge all the deleted files.)
  • W. (unregistered) in reply to Medinoc
    Medinoc:
    It means that there is nothing, nothing, that prevents the automated Office application from displaying (visibly or not) a modal dialog box.

    I have this all the time.

    We have a system which generates a cover sheet in Word for every document that needs to be transmitted to our clients. In the background it starts a process on a "special server" - actually a box on the server room floor running WinXP professional. It opens Word and "prints" the cover sheet to PDF and then attaches it to the document using antiquated PDF freeware. Then the resulting file magically appears in the user's %temp% folder and that then has to be dragged and dropped into our document management system.

    It only takes some joker to use a font that isn't installed on the "special server" to make Word popup with a message and then nobody can make files for clients until they get hold of me to log into the remote server and click okay.

    Or someone makes their file read only.

    Or adjusts the print margins.

    Or uses any non-Latin encoding.

    Etc etc.

  • foo (unregistered) in reply to Neil
    Neil:
    foo:
    a system-wide recycle bin would be a big improvement.
    Novell Netware had undelete back in the 1980s. If you weren't careful your disk would run out of directory entries for deleted files. (One of the volume repair options was to purge all the deleted files.)
    Or out of disk space, which is of course always a danger with unrestricted "recycling".

    Or do you mean plain Dos style optimistic undeleting, i.e. if nothing happened to overwrite a sector it may work? Slightly better than nothing, but these days I'd rather have something more deterministic to rely on.

  • Paul Neumann (unregistered) in reply to LANMind
    LANMind:
    Michael:
    Amazing! TRWTF is that my old workplace (a German Investment Bank in London) did something similar about 10years ago. And it was waved through with the same arguments: The front-office people love Excel and want to be able to update their formulas easily.

    It would be nice if dot net provided a runtime interpreter. I manage a bunch of contantly changing pricing formulas that I would love to present to the users in a UI, and if it isn't right then it isn't my problem...

    It's just awful that .NET doesnt have some AssemblyBuilder class which could emit generated code at runtime. Maybe when they release the 1.1 SDK they'll consider this.

  • (cs) in reply to Little Bobby Excel
    Little Bobby Excel:
    * Seriously, if paying good money for something that's available free doesn't bother you, then what about the legal risk? And all the hassle of license management? Free software is so much better even if the only thing it adds is freedom from the abuse heaped upon you by license-checking mechanisms

    Yeah, if only the entirety of Excel 2007 or Excel 2010 was "available free", you might have a point.

    • Pain-free, transparent running of complex Excel code written in VBA, which might use COM automation to drive instances of Word, Access, or other non-Microsoft software?

    • Pivot tables and pivot charts, with data slicers, and the ability to store more than 1 million rows of data underlying the table INSIDE the Excel file?

    • Native consumption of OLAP cubes/SQL Analysis Services cubes by a pivot table?

    While free alternatives to Excel can do a lot for a lot of customers, don't make the mistake of thinking that everything Excel can do is "available free". It's not.

    Addendum (2012-11-14 12:54):

    • PowerPivot?
  • (cs) in reply to El Ka-Ben
    El Ka-Ben:
    It sounds mostly like a stopgap measure to me -- they get it working now and add this to the bug tracking list. When they get a chance to tackle it then it can be rewritten in code.

    Right now someone has disabled the current production version, not their development version, and that needs to be addressed before the root cause can be tackled.

    It'd be like putting the doughnut spare back on the car to get to the shop and have a tire replaced.

    NO NO NO BAD DOG NO BISCUIT NO! You do not implement a stopgap measure of "reinstall the app and make it license compliant" when a few lines of fresh code on the server will take LESS time to implement than reinstalling that bulky crap.

    function process_the_crap ($box1,$box2,$box3,$box4,$box5) { return $box1 * box2 ($box3 - abs(box4)) more fictional math; }

    I think thats TRWTF.

  • (cs) in reply to justanotheradmin
    justanotheradmin:

    Not quite. It prohibits installing it to a server for the purposes of serving requests to unlicensed clients. In other words, doing Excel-y things for users who don't have Excel installed.

    As long as Excel is installed as part of your standard build, so all users using the server app have a local installation, you're golden.

    I don't know exactly how the Volume Licenses work for companies, but does it actually need to be physically installed on the workstation to be licensed?

  • Spudley (unregistered) in reply to tim
    tim:
    TheCPUWizard:
    Aram got it all re-installed and added to the License Compliance system, but he had one question.

    That is the real WTF. Microsoft Office Licenses specifically prohibit the applications from being used in a Server Environment. This is the biggest reason why Server Applications that must create Office "documents" need to use the OpenXML implementation.

    Adding something to the "License Compliance System" does NOT make something actually comply with legal licensing requirements.

    and TRWFT is, no they don't - get your facts straight

    Shhhhhh! Don't correct him! The more people who believe what he said, the fewer systems will be created like the one in the story.

  • (cs) in reply to PiisAWheeL
    PiisAWheeL:
    a few lines of fresh code on the server will take LESS time to implement than reinstalling that bulky crap.

    function process_the_crap ($box1,$box2,$box3,$box4,$box5) { return $box1 * box2 ($box3 - abs(box4)) more fictional math; }

    I think thats TRWTF.

    Congratulations, you just hard-coded a behavior that the client wanted both soft-coded and compatible with Excel. And which used to work, so on top of not satisfying the client it's a regression.

  • Rester (unregistered)

    Mark Antony: "The evil that men do lives after them; The good is oft interred with their bones".

  • Jonathan Wilson (unregistered) in reply to LANMind

    I dont know exactly how its done but I have a program where one of the files is a .cs file that gets compiled at run-time and can be edited by the user.

  • Jonathan Wilson (unregistered) in reply to LANMind

    I dont know exactly how its done but I have a program where one of the files is a .cs file that gets compiled at run-time and can be edited by the user.

  • consultan (unregistered) in reply to foo2

    Most of the time it's well-behaved: setting Application.DisplayAlerts to False suppresses the overwhelming majority of modal dialogs. However, I just recently stumbled across a corner case where this doesn't work.

    Turns out that, if (1) your VBA code populates a cell with a formula, and (2) the formula points to another workbook, and (3) the target workbook is password-protected, you will always get a modal dialog asking you to enter a password. This is true even if you've set Application.DisplayAlerts to False. There is no way of suppressing it. The behaviour is of course completely undocumented.

    (The background here is that the client had a financial reporting workbook with c. 100,000 distinct references to data in other workbooks, and they wanted to centralise all of those into a single sheet for easier update and auditing. The solution involved writing about 1/3 of a full Excel formula parser, and getting to grips with the fact that, for references like 'MyWorkbook.xlsx'!MyObject, it's impossible to tell whether MyObject is a worksheet or a global named range without looking it up. Happy days.)

    I vaguely recall also having problems with COM add-ins throwing modals, but it's probably not fair to expect Excel to be able to suppress those.

Leave a comment on “Excel-lent Design”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article