- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Executive summary: A bullet is an ultra-efficient mechanism for IPC (Inter-People Communication).
we can comment longer on its efficiency: not much latency and, the most important, generally the receiver will perform the requested action BEFORE receiving the message.
BUT it works only for receivers close enough to the emmiter, difficulty (impossibility) of dispatching/routing/..., lost messages due to incorrect adressing (highly depends on the skills of the emmiter), bullets do not work with XML.
Admin
hmm... it's hardly worse than any other flat-file storage method (XML, CSV etc.). Of course, not using a real database counts as a WTF in most real world applications; but it's hard to judge if this "database" with a few hundred records makes it worth the effort. Most applications in this world can be made more sexy by throwing lots of cash at it. Buy me a database server, buy me a middleware, send some consultants for 250 USD/h and we will make the most buzzword compliant system in the world. But please never mention the ROI.
Admin
You're right. Things like this are often the result of a Second-System-Syndrome-afflicted programmer who thinks he's going to "save" everyone a lot of work. Notice how proud the brain was that "all you have to know is arrays." Evidently he was convinced the other programmers were incapable of anything more than that.
The fewer programming teams this "brain" is permitted to infect, the better. At least until he learns to write code that does the job well instead of trying to be so "helpful."
Admin
That's my favorite part!
THE STORRAY ENGINE!!! echo. echo.. echo...
Admin
There are a fairly limited number of people who understand these things, and lots more work than there are people. And if you are someone who's a bit afraid to jump into something like an SQL database and don't really understand concurrency that well, yet still have to write a functioning web app, the solution presented isn't all that awful. In fact, the use of self-modifying code in that way is kind of clever, even if it is also ugly, bad and a poor fit for the problem if more than one person needs to update the product list at a time.
So, I hold out hope for the programmer who did that. He's definitely overly proud of himself. And he is clearly afraid of various technologies he doesn't yet understand. But better a solution you understand than making some horrible SQL monstrosity because you haven't a clue what you're doing.
Admin
You must be from the middle generation. Code is Data. Lisp for ever.
(in a lot of Lisp frameworks, data is saved as runnable code)
Admin
It's scary, but that's a good thing.
Even if he was (and that happens) it's still a crap solution.
A) He's obviously reading and writing files - this data can and should go in a simple CSV (comma separated value) or XML style file or something - writing it back into the application like that is just weird and wrong. It has a certain cuteness, but in the same sense that a two year old drawing on the walls can be cute even if you know it's going to be hard to clean.
B) It's not even a little bit scalable - if every write operation rewrites part of the application, then they can't be writing to it often. Therefore even if a full SQL engine (Oracle, SQL Server, or even MySql) is out of the question, a tiny thing like SQLite ought to be usable.
C) WTF? While writing an update, anyone attempting to read any page dependant on that file is risking a failed access? Sure, that may be a rare option, but attention to detail is important, dammit! Really, I'ld love to see the spec that makes that the best option available. And then I'ld go to the bar, too.
Admin
You just listed the three reasons why to use generated code (like in the OP).
1) Most firms don't have a DB admin, they have a VB devlopper coder -er.
2) Most firms had only a 5-connection license (not true any more)
3) Code scales better than DB
4) Thread-safety? For read-only data?
Admin
The WTF here is that he uses self-rewriting code when many far simpler and less likely to explode solutions exist. For example, why not just write the data to a file and read it back in in the included ASP page? Why not put in in the Application object? Even better, have the accessor code in the included file, have that check for existing Application data, if that's not available, load it and return it. If the data is in the Application object, compare the current file last modified date to one previously stored in the Application object, if too old, dump and reload. Add an included COM object for thread synchronization written in a real language. In an hour he could have built a rudimentary cache system that would probably have supported many thousands of data items as long as the data is rarely changed. Instead he built a ready-to-explode beast and was proud of it.
This reminds me of the "put the images in images.php" WTF where "cleverness" was seen as the defining characteristic for code quality.
Admin
At my last job, myself and a graphic designer turned coder were tasked with creating an internal knowledge base, but all we had was some file storage - no dynamic scriping allowed because IT convinced management that giving us any thing else would compromise the security of the server. They refused to even let us have one of the surplus desktop boxes and slap a WinXP / IIS / MSSQL Express or LAMP solution on it.
We ended up writing the whole thing in client side JScript that would load up XML from the small file stores they gave us.
That KB was constantly months out of date because it was so hard to maintain. Shortly before I left, the other person on the project discovered a security flaw in the internal server that allowed him to execute arbitrary classic ASP code, but still no database.
Idiotic management can make even good programmers take drastic measures.
Admin
I can't believe that people are defending this as not so bad.
The guy could've simply used a flat file and read it into memory at start-up, and changed the contents of that file whenever a data change was required. Instead, he had the program rewrite itself whenever data changed.
My god!
Admin
the worst part is that they're always so confident. if you're in the predicament of having to teach them, not only do you have to start from design basics (and maybe why programming languages support more than just arrays), but first you need to completely destroy their self-confidence and tell them that everything they hold dear is ruining the world.
Admin
I would have loved to see how this performed on some of my past projects I've had to deal with, such as databases that have in excess of 1.7million rows in some tables! I know they say memory is cheap, but not that cheap, and unless you already have LINQ (Even so I don't think it could cope with huge datastores in RAM that easily), or maybe you skilled enought to use MultiIndex in C++ / Boost, then I wouldn't want to think how slow it would be on something that is in the magnitude of 1'000'000 ARRAY elements!
Admin
WOW! What a concept! A database without actual database.
What exactly would be wrong with "having to use SQL, ADO, or any of that stuff"
Admin
Yeah... but the Ryobi is less than a tenth of the price of the Dewalt, so that's okay. Good eye. Wonder how many other little overrides are sprinkled about the *database*?
Admin
At least with XML you can change individual entries using XUpdate. On the other hand, this guy's format is a POS because it requires rewritten the entire database everytime you save a change. Even an idiot would nkow this is a stupid way to implement data storage.
Admin
A simple CSV file used to store the data -- separate from the code -- is far preferable to the mess we see here. And the JET engine using a simple MDB file, while certainly not ideal for a busy site, is 100% free when using ASP and far more robust, flexible and maintainable then what we see here.
The #1 rule any programmer should know: always separate your code from your data.
Admin
It's not difficult to compile stuff at runtime with .NET ... this could be easily accomplished with .NET's System.CodeDom.Compiler namespace using your .NET language of choice.
Admin
yeah, I just can't figure out how to bring this into .NET; I'm thinking using classes instead, but man, it's hard to compile stuff at run-time!
Now I think I understand what my boss was asking, when he wanted to know how to get the web site to compile files it had created...
Admin
Do you think that if he didn't know how to persist data in a RDBMS, that he would know about a hash table? The *real* WTF is the manager that hired this dipswitch.
Admin
Of course this is coming from the same person who couldn't stop laughing for 5 minutes after thinking about the idea of pcAnywhere'ing into a remote box, then pcAnywhere'ing back into my own box. Speaking of which, I need to try that sometime.
Back when I was starting on 'nix, I couldn't figure out how to su but be able to use X. My solution? ssh -X to my other box, then ssh -X root@ this one.
Well, it worked.
Admin
I'd hate to see the memory use of that IIS server o_O
"A million webservers cried out at once... and then silence"
Admin
Is it just me or are the responses here getting even dumber?
I'm sorry but storing all your data in your source code IS far, far worse than using a flat file storage method and if you can't see that then you are beyond help.
Admin
It's just you ;-)
Technically it is source code but in practice it's just a serialisation method. As long as there is no other code in Products.asp, I couldn't care less. The main drawback compared to CSV or XML is that the data cannot be loaded into e.g. Excel.
Admin
Are prolog programs data or code?
Are Postscript, PDF and WMF data or code?
Admin
Ideally he should have used a fully scallable database system, such as SQL Server, Oracle, MySQL, DB2 or whatever. Choose your fave. They all have pros and cons. Some of these offer free versions so "we can't afford that" isn't much of an excuse.
Failing that (such as not having a suitable server or needing it to be file-handled), he could have used a smaller-scale database system, such as Paradox or Access.
Failing that, he could use a collection of CSV files or an XML file. Hell, even Excel would have been a better choice than the one he used (he could interact with the .xls through COM). Personally I'd have probably gone for XML if I couldn't use a full database system. Parse it with SAX and it's not too slow, you can generate reports straight from it using XSL, you can perform queries on it so searches and filters become a lot easier. If his requirement was to avoid databases, then XML offers many of the same features, even if it can be hard to set all that up.
What you should not do is put it in a hardcoded array like that. I was wondering what happens if I have 5 products and #3 is discontinued so I delete it...? And what was that stuff about compiling at runtime?
Admin
.. suspension of disbelief!
Admin
I think you missed the point how the storray engine works. The "data file" looks like hardcoded (in fact it is obviously source code), but it is not hand written. All you have is an array. Change a record? Delete a record? Insert a record? Do it in the array. Afterwards, the new version of the array is written to the "data file". (Of course, this is neighter efficient nor thread safe).
Instead of XML which requires an additional parser, the programmer wrote ASP code that can be directly imported. I guess it's also faster than parsing an XML file. But of course, on the downside, other tools cannot process it.
Admin
"Are prolog programs data or code?"
data(prolog_program).
no.
code(prolog_program).
no.
Admin
*LOL* good answer :-))
Admin
I hope the original programmer got the opportunity to fix the problem: A happy ending to a sad Storray.
ducks
Admin
...and let's not forget the 'BRILLANT' technology!
Admin
"we can comment longer on its efficiency: not much latency and, the most important, generally the receiver will perform the requested action BEFORE receiving the message.
BUT it works only for receivers close enough to the emmiter, difficulty (impossibility) of dispatching/routing/..., lost messages due to incorrect adressing (highly depends on the skills of the emmiter), bullets do not work with XML."
Sounds a bit like PERL.
BTW: The funniest thing, when searching the classified ads for a job, is to see Programmer positions that require;
PEARL and SEQUEL skills
Makes me laugh out loud every time
Admin
Not sure what your point is ... do you write applications in PDF ?
Any particular file format might ultimately contain both data and instructions/code (i.e., display instructions, macros, etc) but that is different from writing an application in which your data is embedded in your code.
Admin
ammoQ, can you post your real name so we can all avoid ever working with you in the future?
Admin
Yeah, it sucks that you have to use proper data types and everything ... even worse, sometimes you even have to declare variables!
Admin
look at www.ammoq.com
Admin
In this particular case, data is encoded as source code. But since it seems that Product.asp does not contain anything else, "source" is just a file format and I wouldn't call that "embedded".
Admin
XML *requires* an additional parser only if you are using uber-complex XML files. For simple stuff (like this), I would hope any programmer who can parse a simple string should be able to figure out how to pull some data from it.
And remember -- XML is only a file format. If you have list of items on your site, don't have any database availabilty to use at all (again, dubious -- MDB is free and quite powerful, though not good for multi-users but certainly better than what we see here) then *you* can choose whatever file format you want. CSV? Delimited by "*jeff*" ? tabs? fixed width? One per line? As long as it works and is documented. Using XML because it's cool when you don't use any of its features is often overkill, especially if you now feel that you "need to use an XML parser" to parse simple data files.
Pretty much the only way you can mess things up is to say "instead of a data file in any format, I will just dynamically alter the code in my application that one-by-one fills in array with my harded coded data!"
Admin
I don't know ASP and I feel somewhat lazy at the moment.
Can you tell me whether entering quotes or brackets in the
item descriptions would affect the "engine"?
Admin
I guess the
part handles the problem of quotes; brackets don't matter
Admin
Well, based on some of the responses, it appears that some people actually do not consider this a WTF. Let me spell it out for you.
1) Let's pretend for argument's sake that writing saving data as code isn't a bad idea. At least do it "right" and use an array of a user-defined type.
2) If any product information changes, it requires editing script code. With any other reasonable method, updating product information could be done by a chimp.
3) If your website is worth a damn, you will offer query capability like show me all the hammers you sell, etc.. Implementing query capabilities on 2d arrays is pathetically stupid and a waste of time re-inventing the wheel.
4) CSV, XML, Jet, Access, MSSQL and VB record I/O are all FREE viable alternatives to the Storrary Engine.
5) If you weren't writing pathetic, throw away code, your system might have to be maintained (instead of rewritten). If you use standard techniques and don't overengineer, other people can easily maintain your code. No one with any sense would do anything but throw away the Storrary Engine.
How can anyone defend this? I can think of no set of circumstances under which I would call the Storrary Engine an acceptable solution. People mention performance and overhead as reasons. Are you kidding
Admin
Right, I've also done that. Handfull of lines in Java. But this imposes many restrictions on the XML file, so it's a good candidate to end as a WTF once someone mistakes it for a real XML parser.
It would have to be a very bad database to be worse than that ;-)
This guy choose "ASP script" as his file format. It works and I think it is even documented. And the best thing is: the parser is already built-in ;-)
Probably the most efficient way to mess this up would be an attempt to understand and alter the file, instead of completely rewriting it. Definitely a no-go. This file must be written as a whole, and read as a whole.
Admin
Wow .... can't tell if you are goofing around or serious. Your comment about MDB files is a good indication of your overall ignorance on this topic, but again, hopefully you are just trolling or having some fun.
Admin
Yeah, ammoq, I did miss the point about what he was doing. But then, if it's not hand-written, the data obviously comes from somewhere. I dunno, maybe I'm just missing something but I'd be interested to see how the array that was being passed to that function was actually generated.
Thing is, a lot of modern languages actually include XML parsing as part of the package. If you use .NET, it includes the System.Xml namespace, which has classes to work with the DOM. If you want speed, then there's a SAX parser available as well. And, as I mentioned, you can do more with XML than you can with this. However, it's still not as good as having a proper database (even if your database system is Access) because that's not really what it was intended for. But it would be an improvement over this.
Admin
Since the storray engine is implicetely Q&D, "doing it right" makes it only worse (still D, but no longer Q).
As far as I can read from the code, the whole file is rewritten. It is probably never edited in a conventional way, maybe except for Q&D changes.
Simple queries like "all the hammers" that are not especially complex on a 2D string array. I hope they never implement a "show me all your hammers where the same company provides at least 5 types of nails" query feature.
IMO CSV and XML are nearly as much a WTF for this task than the storray engine. The hard facts (speed, reliability, concurrency etc.) are probably not better. Well, CSV needs less space.
It's always easy to say "throw it away, do it right" if you have the budget. Don't get me wrong, the storray engine is not my baby and I don't feel like using it for my next project. But at least it's Q&D, a big advantage compared to many pathetic WTFs which are so large and complex that "throw it away" is something the ties won't accept.
Admin
Read the OP. does the job.
Honestly, if someone takes this system and translates it to (handwritten) XML I would call it a big big WTF.
The closest resemblance of the original concept would be to serialize and deserialize the array.
But as many have pointed out, a lot of free databases is available in the year 2006.
I didn't mean to say MDB is bad. And yes, playing the WTF's advocate is more funny to me than joining the "oh my eyes" chorus.
Admin
At least someone wrote an HTTP server in Postscript.
http://www.au.horde.org/pub/pshttpd/
So while Postscript files can be considered data (mostly images), they are also programs. To some extend, the same is true for PDF and WMF.
Admin
I think written back to itself isn't a really terrible idea if your application write very little but read often. If data only write back when using admin functions and we assume only one admin using at one time, then why we should reject this form of flatfile "database"?
I just wonder if ASP has caching of compiled code just like PHP so that it can minimize the impact of flatfile?
Admin
I think I would have to break my rule and join Steve in the bar for that drink.
Yeah this solution works. However the pride of the creator was too much.
Here is a clue: there are a number of free SQL databases that you can link to. (The much hyped MySQL is perhaps the worst) Most hosting providers will give you access to one for very little extra change - it doesn't cost them much to provide it, and they can make some money.
Even if they won't provide a database sqlite is plenty good, and provides all the thread safety you really need in a web app.
Yes you can do something in code without a database. You can even provide the thread safety (not to mention the rest of ACID) that a database provides. If you are working with a small number of records (like this), your solution probably is faster. However it is faster and easier (for the programmer) to use a database anyway. In today's world programmer time it more expensive than computer time.
Considering the lack of thread safety, and the small size, it is faster to re-parse this file as needed. However the users will not notice the extra time it takes after you convert to a real database. This will notice the lack of random problems caused by threading issues.