• Trawn (unregistered)

    You couldn't have some php/jsp/asp process use GD/.NET to generate the TIFFs/JPGs/GIFs server side and then store the hashes in the database?

    Then make the client dumb and just pull the data via http and print?

    This shouldn't take more than a month.

    Storage and bandwidth are cheap now...

    The WTF is improper business analysis, and continuing on this path of buck passing.

  • Anon (unregistered)

    WTF indeed. He could possibly imagine creating a hash from the row that produced the TIFF before the TIFF was created and using that. Presumably the same data going into the TIFF generator produces the same result, so just hash the data going in.

  • Davy (unregistered)

    Hey Scott. Do some work. "Weighed the effort of recommending throwing more hardware at the problem against actually doing any work at all", more like. You had an opportunity to seriously improve the performance right there, and you just didn't bother. Poor show.

  • fw (unregistered)

    Surely rather than generating the prints one store at a time, the system should loop through each product and generate the prints required for each store, any stores which are the same get the same print. Or am I missing something?

    captcha damnum

  • blah (unregistered)

    Viscous?

    This site is a curious perversion in linguistic shamobatics.

  • SNF (unregistered)

    Who else starting hoping, half way through the story, that it would at some point involve something called "ASS Munch OS"?

  • (cs)

    I don't get it --

    The premise is that the TIFF generation is the bottleneck.

    If so, we can pseudo-code this as follows:

    tiff <- generate_tiff(parameters) hash <- generate_tiff_hash(tiff)

    The article indicated that it was desired to suppress redundant generations of the same tiff. Which implies that the parameters are the same (or very similar; some programmers put unused information into parameters "just in case", but the reasoning still holds).

    Now, the hash should be identical, but isn't, according to the article. But, the tiff itself is dependent on "parameters", and apparently, the MAC of the server. So, why don't we just simplify:

    hash <- generate_hash(parameters) if (hash not found) tiff <- generate_tiff(parameters)

    The hash could be left as the 64 byte (or whatever) data it is currently. The generate_hash() function should only be dependent on the parameters, or parts thereof that will show up in the tiff image.

    The hash is probably (currently) being used to generate a storage tag for the tiff image. The "rewrite" preserves this property.

    So this cannot be the COMPLETE "WTF"? Inquiring minds want to know -- what is the missing link? This may also require normalizing the tiff store across the servers.

  • paul (unregistered)

    Why mess with a hash? This is an instance where you could easily make human-readable filenames for the images without worrying about collision or anything else. Just use the SKU.

    sku_priceincents_signcategory.tiff

  • Boris (unregistered)

    The TLA of your backend is literally ASS ?

  • (cs)

    Gotta watch out for those viscous cycles. They can get sticky.

  • (cs) in reply to ratboy667

    Wouldn't it just be easier to standardize parameters, store TIFFs by them, then if parameters match, use the same TIFFs if the parameters match ?

    Filed under 'tl;dr code, just improve the hardware'

  • (cs) in reply to blah

    Ah, the well known "viscous cycle." Ask your father.

  • (cs)

    The answer to why he did it in this manner is at the end of the article:

    enterprise-level VB5 code.
  • Anon (unregistered) in reply to ratboy667
    ratboy667:

    hash <- generate_hash(parameters) if (hash not found) tiff <- generate_tiff(parameters) else tiff <- retrieve_tiff(hash)

    FTFY

  • (cs) in reply to Shial
    Shial:
    The answer to why he did it in this manner is at the end of the article:
    enterprise-level VB5 code.

    That's an oxymoron, isn't it?

  • (cs) in reply to ObiWayneKenobi

    yes, but would you want to poke around in some b@#@#@ spawn of codethulu or just suggest they sacrifice some more hardware to it while you run away?

  • (cs) in reply to Anon
    Anon:
    ratboy667:

    hash <- generate_hash(parameters) if (hash not found) tiff <- generate_tiff(parameters) else tiff <- retrieve_tiff(hash)

    FTFY

    I think you want

    hash <- generate_hash(parameters) if (hash found) { # positive sense for readability tiff <- retrieve_tiff(hash) } else { tiff <- generate_tiff(parameters) store_tiff(hash, tiff) }

  • (cs) in reply to Code Dependent
    Code Dependent:
    Gotta watch out for those viscous cycles. They can get sticky.
    Yeah, you can always tell when you're in the thick of it.
  • Davy (unregistered)

    Just because VB5 isn't the nicest language in the world doesn't automatically mean it can't possibly be changed. This looks far more like laziness.

  • Gary Williams (unregistered)

    Buy a network card, get the MAC address from it, feed to the application as a static value, smash the network card.

    There you go. All the servers can use the SAME hash generated from a MAC address that can't be used anywhere else.

    Cheaper than buying more hardware.

  • Anonymous (unregistered)

    Scott made the right decision. Bollocks to maintaining your stupid app, chuck a bigger server at it.

  • AJ (unregistered) in reply to Gary Williams
    Gary Williams:
    Buy a network card, get the MAC address from it,

    ...

    Cheaper than buying more hardware.

    Well, technically, you did buy a little more hardware.

  • Jack Hardcastle (unregistered)

    Just pour some more money in, it's a viscous cycle!

  • (cs) in reply to Gary Williams
    Gary Williams:
    Buy a network card, get the MAC address from it, feed to the application as a static value, smash the network card.
    How about this? Store manager sits down at computer, brings up default list of sale items and prices for the coming week. Scans list, clicks checkbox by the ones he wants to feature at his store, edits prices as needed to allow for regional differences, adds a few items not on the list from the central database of stock items, and then hits "Print" and his text information is formatted and sent to the printer.

    No hashcode; no TIFF file; no smashed network card.

  • J (unregistered)

    Geez, this is pathetic. Unless they gave him a timespan of 2 days to fix it, just walking away from the problem is ridiculous. They need their application fixed. They hired you to program. Do your job.

  • SomeCoder (unregistered)

    At first glance, I agree with the rest of the posts about this. He should have just done the work to generate a hash from the params, create the tif, wrap an if around it and call it a day.

    However, being that this is probably a big ball of mud of VB5 code.... I too would be tempted to either say "Rewrite the damn thing" or "Throw more servers at the damn thing".

    Having dealt with some stuff like this before, I can understand why he just chose the hardware route shrug

  • Anon (unregistered) in reply to Maurits
    Maurits:
    Anon:
    ratboy667:

    hash <- generate_hash(parameters) if (hash not found) tiff <- generate_tiff(parameters) else tiff <- retrieve_tiff(hash)

    FTFY

    I think you want

    hash <- generate_hash(parameters) if (hash found) { # positive sense for readability tiff <- retrieve_tiff(hash) } else { tiff <- generate_tiff(parameters) store_tiff(hash, tiff) }

    I choose to assume that generate_tiff also took care of storing the tiff. It's arguable whether or not that would be good practice.

  • anonymous (unregistered)

    Talk about lazy! Spend the time, modernize the code and be the hero by saving the company some $$$ by reducing the server count.

    I also hope that they are not printing signs for all SKU's each day, and only printing signs that have changed (price changes).

  • Anon (unregistered)
    1. Retrieve price information from Oracle database
    2. Generate TIFF of sign
    3. Print sign, place on table
    4. Place handwritten note with MAC address of system below sign
    5. Take photo
    6. Scan into TIFF format
    7. Generate hash from TIFF to get your unique identifier
    8. Profit!
  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Shial:
    The answer to why he did it in this manner is at the end of the article:
    enterprise-level VB5 code.

    That's an oxymoron, isn't it?

    I see two:

    • enterprise-level and VB
    • VB and code

    To which are you referring?

  • (cs) in reply to anonymous
    anonymous:
    Talk about lazy! Spend the time, modernize the code and be the hero by saving the company some $$$ by reducing the server count.

    I also hope that they are not printing signs for all SKU's each day, and only printing signs that have changed (price changes).

    I was wondering the same thing.. I worked at a large grocery chain in college. they only changed prices once a week, and the new labels were for only the items that changed. They were snail mailed to every store every week.

  • (cs) in reply to blah

    Unlike inviscid cycles, viscous cycles are unstable; the medium doesn't conserve vorticity.

  • (cs) in reply to Anon
    Maurits:
    I choose to assume that generate_tiff also took care of storing the tiff. It's arguable whether or not that would be good practice.

    I'm with you. RatBoy667 was outlining an approach with pseudocode, not programming a detailed design. I totally got the point he was making, which was, why on God's green earth were they hashing the TIFF instead of the source data.

  • Adam (unregistered)

    s/time and time again/time and again/

  • OldPeter (unregistered)

    So why send TIFFs at all? Why not send just the small codes to the stores and leave it to some client application there to render the final signs.

    Yes, it takes considerable time to generate a pixel image like a TIFF. So why not take a different way here, by, say, using enormously big postscript fonts or else big fonts? There are a number of intelligent ways to generate such big-scale renderings like a snap.

    That would look like a new solution.

  • Pixel Slinger (unregistered) in reply to Shial

    Exactly! Doing work would cut into my DailyWTF reading-time.

    Shial:
    yes, but would you want to poke around in some b@#@#@ spawn of codethulu or just suggest they sacrifice some more hardware to it while you run away?
  • (cs)

    Ah, yes, those viscous cycles. The ones that cause the repetitive elastic rebounding of my forehead from my desk.

  • A Gould (unregistered) in reply to Davy
    Davy:
    Hey Scott. Do some work. "Weighed the effort of recommending throwing more hardware at the problem against actually doing any work at all", more like. You had an opportunity to seriously improve the performance right there, and you just didn't bother. Poor show.

    No, I'd say it was the correct call. If not from the purist programmer perspective, definitely from the submitter's boss' perspective. Let's see.

    Option 1: Use a proven solution, at a known cost, which can be implemented quickly.

    Option 2: Tie up personnel to work on something with no solid finish date (and remember, those leases end in 3 months!), and which may or may not actually work as advertised.

    Here's my thought process: The software works. The problem is that the lease is ending, and we need new equipment regardless. Getting faster equipment will improve performance now. Re-writing is a big scary unknown. Hence, get the equipment (which I was going to have to buy anyway), assign my guy to one of the dozen more pressing issues on the table right now.

    This story screamed "bonus duty" - sure, you could press to re-write (because it is the right long-term solution, no doubt about it). But it won't be a company priority. You'll end up doing it between other jobs, it will take four times as long, and you'll look bad even if it works.

  • Drew (unregistered)

    'Kay. Obviously we don't have all the information but one would assume that the decision was made to throw new hardware at it, so that valuable IT Human Resources could be used to tackle other problems or add new features to other systems to increase profitability.

    Could not his choice be one based on business realities and not just laziness!? D:

  • RBoy1 (unregistered)

    Processing Comment

  • RBoy2 (unregistered)

    Processing Comment

  • RBoy1 (unregistered)

    Comment

  • RBoy2 (unregistered)

    Comment

  • Eff Five (unregistered)

    Oh ok so the WTF is about why Scott has a job? No, maybe its Mark's writing style, the build up to a nothing ending? Perhaps its a TRWTF is about TDWTF, as in "WTF these articles are lame and getting lamer."

    So meta

  • (cs)

    Is it harder, then, pouring over something viscous?

  • Litote. (unregistered) in reply to blah
    blah:
    This site is a curious perversion in linguistic shamobatics.

    Your prize is half-an-internet for the word 'shamobatics'.

    ( o ) ( o )

  • JoeCoder (unregistered) in reply to Shial
    Shial:
    yes, but would you want to poke around in some b@#@#@ spawn of codethulu or just suggest they sacrifice some more hardware to it while you run away?

    umm, because you are supposed to be a professional?

  • J (unregistered) in reply to Publius
    Publius:
    Is it harder, then, pouring over something viscous?
    It's just a slow pour, than, viscously speaking.
  • (cs)

    Since most stores don't put the name of the widget on the price sign, but just put the sign on the display, short of fixing the code, why not just generate all the tiffs from $0.01 to $<select max(price)+RoomToGrow from products>, ONCE, in ADVANCE, and just ACCESS them when needed?

    And maybe do a check: (pseudo)

    price = select ...
if not exists tiff for $price
   create tiff for $price -- handle inflation as prices increase
fi
retrieve tiff for $price
  • my name is missing (unregistered)

    Give me that job and two weeks and a couple small servers and pay me the difference between the servers and your hardware cost. Jeez o Pete.

Leave a comment on “Throw Some Hardware at it!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article