Comment On Imaging In Line

Shortly after taking a new job, Graham noticed that his new colleagues had a rather peculiar metric for determining software quality: cleverness. The standard measurements of cost, performance, maintainability, and so on, were afterthoughts -- nay, hindrances -- to their vision. Oh no, they were special, and so would be the software that they developed. [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4Next »

Re: Imaging In Line

2006-01-05 13:54 • by anon
Frist Pst!!!!!!!!!!!1111111111111one

Re: Imaging In Line

2006-01-05 13:57 • by David
55675 in reply to 55674
Clearly you can't understand the genius of this design!  The graphics artists can modify images with notepad!  Imagine how much easier that must be on them than opening up something like photoshop. 

Re: Imaging In Line

2006-01-05 13:57 • by Daenetha
Oh.... My... God....

Bile just rose in my throat.

A greater horror has never been perpetrated.

--D

Re: Imaging In Line

2006-01-05 13:57 • by Matt
Because browser caches are clearly not clever.

Re: Imaging In Line

2006-01-05 13:59 • by Jason
I wonder whether or not these employees were paid "by the line" or not.

Re: Imaging In Line

2006-01-05 14:01 • by Matt
55679 in reply to 55677
I should note that I once worked with an PHP-based OSS photo album that worked in a similar manner. Every image in the album was one PHP script that loaded the image from disk and echo'd it to the browser with a faked MIME type. The justification for this was security -- the author wanted a simple way to enforce privacy levels for different images within the same directory. It worked, but prevented browser caches from operating properly and was terribly slow, all for a feature that very few people used. It was one of the first things I ripped out of the script.

Re: Imaging In Line

2006-01-05 14:03 • by cconroy
55680 in reply to 55678
Sweet merciful crap.  That's beyond hideous.



Re: Imaging In Line

2006-01-05 14:04 • by nobody
55681 in reply to 55679
Um, displaying images through a filter script like that is a fairly reasonable way to deal with security. Done correctly, the browser can still cache the image, and the performance hit is not that great.

Re: Imaging In Line

2006-01-05 14:05 • by Tdog

Other than their internal process of getting the images to the designers, I don't see the problem with this one.  Whats the difference between this and putting the images into the database.  In fact, this is a more portable solution than a database would be. 

Re: Imaging In Line

2006-01-05 14:06 • by David
55683 in reply to 55681

Anonymous:
Um, displaying images through a filter script like that is a fairly reasonable way to deal with security. Done correctly, the browser can still cache the image, and the performance hit is not that great.


 


Yep yep, cause you wouldn't want people to be doing evil stuff like viewing your *gasp* pdf file icons if they're not authorized! 

Re: Imaging In Line

2006-01-05 14:06 • by retnuh
This is giving me all kinds of ideas for a new product line!

Re: Imaging In Line

2006-01-05 14:09 • by Joe
Special just doesn't do this code justice.

Let me guess.  If they needed an animated GIF they would just use a timer and For Loop to display the images in a specified order.

Re: Imaging In Line

2006-01-05 14:12 • by Martin
55686 in reply to 55681
It's really a bad way to solve the security problems. It does have far
to much overhoad and it is not secure against cross scripting.(Anyone
who can read the script can get the image).



A better and more secure way would be to simple have the images stored
a place where the webserver will not serve them, and then use something
like the php readfile function to show the file, it the user is allowed
to read it. Much faster and more easy to manage.





Re: Imaging In Line

2006-01-05 14:13 • by Gene Wirchenko
Alex Papadimoulis:
Shortly after taking a new job, Graham noticed that his new colleagues had a rather peculiar metric for determining software quality: cleverness. The standard measurements of cost, performance, maintainability, and so on, were afterthoughts -- nay, hindrances -- to their vision. Oh no, they were special, and so would be the software that they developed.


The software industry has many clever people.  It also has many smart people.  These are not the same.  <SIGH>

Sincerely,

Gene Wirchenko

Re: Imaging In Line

2006-01-05 14:14 • by David

I'm surprised no one has mentioned this yet:


 


The real WTF is that they should have stored the images in XML.


 


*ducks and runs*

Re: Imaging In Line

2006-01-05 14:15 • by Satanicpuppy
Okay, that's pretty freakin funny.

I can see storing the images in base 64, but why would they put that in a flat file? Jeez, at least put it in a database, if you can't stand the idea of a simple directory.

Re: Imaging In Line

2006-01-05 14:17 • by WWWWolf
Well, you know, this might make sense if those were .svg files (which are at least in some form human-readable and even human-editable), but doing this for binary files is just utterly ridiculous.

It's not a completely stupid strategy for stand-alone apps though (think bitmap resources in form of .xpm or something) - but for web apps, argh.

Re: Imaging In Line

2006-01-05 14:20 • by sadmac
55691 in reply to 55686
We have a winner.

PHP has some pretty impressive imaging functions. This isn't the way to use them. Not to mention you'd have to create at least one other script to encode the data reliably and format it quickly.

Re: Imaging In Line

2006-01-05 14:23 • by nikolas
55693 in reply to 55688
i would have extended the script to accept image uploads and include them via self-modification  =D

Re: Imaging In Line

2006-01-05 14:23 • by Satanicpuppy
55694 in reply to 55679
Anonymous:
I should note that I once worked with an PHP-based OSS photo album that worked in a similar manner. Every image in the album was one PHP script that loaded the image from disk and echo'd it to the browser with a faked MIME type. The justification for this was security -- the author wanted a simple way to enforce privacy levels for different images within the same directory. It worked, but prevented browser caches from operating properly and was terribly slow, all for a feature that very few people used. It was one of the first things I ripped out of the script.


The problem with that, for this, is that the "program" will serve whatever picture is passed to it in the $_GET['image'] field, which, as it's a get, can be hacked from the browser a la "http://www.stupidprogrammer.com/image.php?image=your_mom_naked.gif"

Completely insecure.

Re: Imaging In Line

2006-01-05 14:26 • by nikolas
55696 in reply to 55694
Satanicpuppy:

 "http://www.stupidprogrammer.com/image.php?image=your_mom_naked.gif"

where have you got this picture from ?

Re: Imaging In Line

2006-01-05 14:31 • by clu82
/**********************
__images.php__

Displays an embedded image file

(C) Initech Solutions, 2001
**********************/



Is this the same Initech from "Office Space"?

Re: Imaging In Line

2006-01-05 14:32 • by masklinn
55698 in reply to 55690

Holy mother of god...


Did they, like, know that some browsers even allow you to embed the images into the HTML document? Cause if they didn't Graham should tell them, they may like it

Re: Imaging In Line

2006-01-05 14:32 • by frosty
55699 in reply to 55697
Anonymous:
/**********************
__images.php__

Displays an embedded image file

(C) Initech Solutions, 2001
**********************/



Is this the same Initech from "Office Space"?


Yes.  Alex used to work there.  He was the guy who had his stapler taken away.

Re: Imaging In Line

2006-01-05 14:33 • by DaveNY
55700 in reply to 55697
Anonymous:
/**********************
__images.php__

Displays an embedded image file

(C) Initech Solutions, 2001
**********************/



Is this the same Initech from "Office Space"?


Yep -- a common TDWTF-ism to protect the guilty.

Re: Imaging In Line

2006-01-05 14:35 • by frosty
55701 in reply to 55700
Anonymous:
Anonymous:
/**********************
__images.php__

Displays an embedded image file

(C) Initech Solutions, 2001
**********************/



Is this the same Initech from "Office Space"?


Yep -- a common TDWTF-ism to protect the guilty.


Awww, you weren't supposed to tell them.  They were supposed to wallow with uncertainty about the inside joke for weeks until it came up again.

Re: Imaging In Line

2006-01-05 14:40 • by ellion
Wow, now the artist can edit all graphics via ssh. How awesome is that?!

What about a function to vote the most innovative wtf? This one's surely gonna rock :D

Re: Imaging In Line

2006-01-05 14:41 • by WTF Batman
55703 in reply to 55701
Sorry, Mr Frosty. I'll endeavor to be more evil in the future.

I believe you have my stapler.

Sincerely,
WTF Batman
(aka DaveNY)

Re: Imaging In Line

2006-01-05 14:43 • by Satanicpuppy
55704 in reply to 55696
Anonymous:
Satanicpuppy:

 "http://www.stupidprogrammer.com/image.php?image=your_mom_naked.gif"

where have you got this picture from ?

Heh. Just an example. Pretty much any site that has images worth swiping has them archived using a sequential identifier, linked to the page through a database. When those images are pulled using get data, you can use any one picture to iterate through their entire catalog, and rip out every single picture.

I was working for a company, and we were doing a project and needed picture data that belonged to another company that was owned by the same company that owned my company. Theoretically we were supposed to be cooperating, but it boiled down to a permanent pissing contest over resources. I got fed up with it one night, and wrote a scraper to pull every single picture and store it based on data that was easily croppable from their pages. Then I set it to run on our internal corporate network (so their admin's wouldn't notice the bot traffic on their external web address) and in the morning, we magically had all the data that we needed.

Got the idea from a project a roommate of mine put together...He called it "The Unstoppable Sex Machine" and it basically did the same thing, but with porn sites, and it didn't limit itself to one site. Hence, "your_mom_naked.gif".

Re: Imaging In Line

2006-01-05 14:49 • by dasmb
If I could do the first 6 years of my career all over again, I'd do it without the cleverness.  It's always cost me time, energy and precious patience.

Except in my UI.  That type of cleverness gets me work.

Re: Imaging In Line

2006-01-05 14:50 • by Sean
55706 in reply to 55699
frosty:
Anonymous:
/**********************
__images.php__

Displays an embedded image file

(C) Initech Solutions, 2001
**********************/



Is this the same Initech from "Office Space"?


Yes.  Alex used to work there.  He was the guy who had his stapler taken away.


O RLY?  I think he was my cube neighbor.

Re: Imaging In Line

2006-01-05 14:52 • by uniq
It doesn't work.
I thought that at least first 2 images (not cutted) should work.

Re: Imaging In Line

2006-01-05 14:52 • by frosty
55708 in reply to 55704
Satanicpuppy:
Got the idea from a project a roommate of mine put together...He called it "The Unstoppable Sex Machine" and it basically did the same thing, but with porn sites, and it didn't limit itself to one site. Hence, "your_mom_naked.gif".


Right, because if there are two things that both the internet and computer science were developed to serve, it's downloading porn and making jokes related to the former.

Re: Imaging In Line

2006-01-05 14:54 • by WTF Batman
55709 in reply to 55705
Anonymous:
If I could do the first 6 years of my career all over again, I'd do it without the cleverness.  It's always cost me time, energy and precious patience.

Except in my UI.  That type of cleverness gets me work.


I found that I learned a lot when I was trying to be clever. As you said, it cost me time, energy, and frustration, but in the process of debugging it all, I learned a lot about the languages I was dealing with.

Some say that work isn't the place to be learning new things, but I say that they benefit in the long run when you understand your craft and tools better. After all, most places pay for training programs for just that reason.

Re: Imaging In Line

2006-01-05 14:56 • by Gene Wirchenko
55710 in reply to 55709
WTF Batman:
Anonymous:
If I could do the first 6 years of my career all over again, I'd do it without the cleverness.  It's always cost me time, energy and precious patience.

Except in my UI.  That type of cleverness gets me work.


I found that I learned a lot when I was trying to be clever. As you said, it cost me time, energy, and frustration, but in the process of debugging it all, I learned a lot about the languages I was dealing with.

Some say that work isn't the place to be learning new things, but I say that they benefit in the long run when you understand your craft and tools better. After all, most places pay for training programs for just that reason.


There is a big difference between learning new things and compulsively being clever.

Sincerely,

Gene Wirchenko

Re: Imaging In Line

2006-01-05 14:58 • by frosty
55711 in reply to 55709
I think it depends on what type of "clever" you are being.  There's stupid-clever and there's good-clever.  This was stupid clever.

Using good design patterns, organizing the structure of the application, re-using code properly to make it easier to maintain and less prone to bugs is good-clever.  Even if it hurts more the first time, you'll be glad if you have to come back to maintain it (or glad that you don't have to debug it as much later).

Re: Imaging In Line

2006-01-05 15:05 • by Mike
55712 in reply to 55709
WTF Batman:
Anonymous:
If I could do the
first 6 years of my career all over again, I'd do it without the
cleverness.  It's always cost me time, energy and precious
patience.

Except in my UI.  That type of cleverness gets me work.


I
found that I learned a lot when I was trying to be clever. As you said,
it cost me time, energy, and frustration, but in the process of
debugging it all, I learned a lot about the languages I was dealing
with.

Some say that work isn't the place to be learning new
things, but I say that they benefit in the long run when you understand
your craft and tools better. After all, most places pay for training
programs for just that reason.

Re: Imaging In Line

2006-01-05 15:06 • by David
55713 in reply to 55710

Gene Wirchenko:
WTF Batman:
Anonymous:
If I could do the first 6 years of my career all over again, I'd do it without the cleverness.  It's always cost me time, energy and precious patience.

Except in my UI.  That type of cleverness gets me work.


I found that I learned a lot when I was trying to be clever. As you said, it cost me time, energy, and frustration, but in the process of debugging it all, I learned a lot about the languages I was dealing with.

Some say that work isn't the place to be learning new things, but I say that they benefit in the long run when you understand your craft and tools better. After all, most places pay for training programs for just that reason.


There is a big difference between learning new things and compulsively being clever.

Sincerely,

Gene Wirchenko


 


Not always.  If it wasn't for me trying to be clever I never wouldve learned how to deal with cookies in vbscript.  Or learned about the number and size limitation of cookies.  Or that it probably wasn't a brilliant idea to cache 7k worth of data in a cookie to increase page load times.


 


But hey, at least I was being clever at the time.  ^_^

Re: Imaging In Line

2006-01-05 15:07 • by phearlez
I can't believe nobody has pointed out that in the midst of being clever, there's no effort to check that the array index is in bounds!

I guess error checking isn't clever.

Re: Imaging In Line

2006-01-05 15:09 • by frosty
55715 in reply to 55713
David:
Not always.  If it wasn't for me trying to be clever I never wouldve learned how to deal with cookies in vbscript.  Or learned about the number and size limitation of cookies.  Or that it probably wasn't a brilliant idea to cache 7k worth of data in a cookie to increase page load times.


You were trying to increase the load times, so you made a 7k cookie?  Cleverness asside, how does that accomplish the goal?

Re: Imaging In Line

2006-01-05 15:10 • by Bugbear
55716 in reply to 55681
Anonymous:
Um, displaying images through a filter script like that is a fairly reasonable way to deal with security. Done correctly, the browser can still cache the image, and the performance hit is not that great.


Except that each time you want to view a single image, no matter how small, the PHP script has to be parsed in its entirety. Way. To. Go.

Re: Imaging In Line

2006-01-05 15:19 • by Rank Amateur
55717 in reply to 55693

Anonymous:
i would have extended the script to accept image uploads and include them via self-modification  =D


If you do, keep it a secret. All new employees are expected to type the image directly into the script one byte at a time. Why do you think they gave Graham the task? It's his rite of passage. If he succeeds, he gets the honor of the next level: typing a mpeg into a script.

Re: Imaging In Line

2006-01-05 15:30 • by A
This isn't clever, it's just fucking stupid.

Re: Imaging In Line

2006-01-05 15:30 • by JoeyLemur
Things you shouldn't read just after eating lunch...  ye gods and little fishies...

Re: Imaging In Line

2006-01-05 15:30 • by Volmarias
55721 in reply to 55717
Sweet mercy...

I was not strong enough today. This TDWTF has broken me. I'm going to find a cubicle, and sit down and cry.

Re: Imaging In Line

2006-01-05 15:31 • by BlueEagle
There is actually a script that will base64encode images for just this purpous.

...and I helped build it. *sob*

Re: Imaging In Line

2006-01-05 15:40 • by yerMom
55724 in reply to 55681
it's not the displaying of the images through a "filter script" that's the problem, it's the hardcoding of image data in the filter.

E.g.: perhaps better to cycle through all image files on disk at startup, read them into memory, and then serve them directly from memory ... which would cut down on disk IO.hardcoding the actual image data is retarded.




Re: Imaging In Line

2006-01-05 15:41 • by Skippy
55725 in reply to 55682
Anonymous:


Other than their internal process of getting the images to the designers, I don't see the problem with this one.  Whats the difference between this and putting the images into the database.  In fact, this is a more portable solution than a database would be. 


Putting images in a DB is pretty dumb as well (yes, there are times when it can be appropriate, but they are few and far between). There are much better ways to deal with it than putting the binary image in the db.


Re: Imaging In Line

2006-01-05 15:44 • by mysql101
55726 in reply to 55704
Personally, I like to generate a md5 hash of the image's contents, and use that as the filename. It helps me not duplicate content, but also renders image1.jpg - image10.jpg issues gone.

Re: Imaging In Line

2006-01-05 15:46 • by Anonymous
Those images seem to be missing all their null bytes.

« PrevPage 1 | Page 2 | Page 3 | Page 4Next »

Add Comment