|
| |
User Groups : Forums : SiteExperts :
The Lounge
:  |  Bump the ceiling
I know this is the Lounge, although this topic is still technical stuff, it's also just a chat of sharing experiences (hence, the funky title). I just don't know exactly where to put it, and I guess it wouldn't matter anyways.
Anyway, what I meant by bumping the ceiling is in fact reaching some sort of limitation when building scalable projects, be it a browser limitation or a server limitation, etc.
For instance, "nested HTML tables". Internet Explorer stop rendering the inner tables when the level of nesting reaches 28. Firefox will stop at 34. Here's a link about it: http://helephant.com/2007/08/extreme-nesting-experiment-in-ie-and-firefox/. There was a time I code this thing and bump into this problem when I started to scale it, and obviously I started doing exactly what that guy did, and I searched, found that article, and basically said, "what a bumber.", had a cup of coffee, and started re-writing my thing from scratch.
What a day that was. I would have expected a very big number, but 28? 34? Come on. I knew tables were devils, I just didn't expect them to creep up behind my back this way.
And I also did something pretty dumb in classic ASP, where I did a pair of recursive functions, where Function_A would call Function_B, and B would call A, etc, up to a point when a condition is met, it should properly terminate. The code is technically pretty solid and everything is basically handled. However, when I started to scale and test and benchmark, boom, I get a "Out of Stack Space" when large amounts of data get dumped in.
Those were pretty good lessons for me. Yeah, I'm probably dumb in the first place, I should have gone back to CS 101, and I should have researched and verified that the logic I was about to code would be scalable before I even start to code it. But they still are interesting lessons aren't they?
I was wondering if any of you may have some other kinds of interesting ceiling-bumping or wall-banging web development experiences in the past which you could share. I'm sure things like this could happen if you are at some point trying to build and test something that was meant to be scalable.Started By Terry Young on Aug 14, 2009 at 3:35:39 AM
This message has been edited. | | | 3 Response(s) | Reply |
| Earlier Replies | Replies 2 to 3 of 3 | Later Replies | | | ChrisRickard on Sep 11, 2009 at 10:04:57 PM (# 2) A fond memory of mine is an old ASP app where I routed documents through a "workflow" approval process. User A would fill out a form, approval routing goes through users B, C, and D who edit/approve or could reject which kicks it back to the original user. The problem wasn't so much technical (at least at first) as it was me just going out and implementing it without doing a thorough analysis and getting the business to sign off on an approved process.
It worked beautifully at first. Then the requests started coming in. Well it should go to suchandsuch if the office is in this State. Then suchandsuch comes to me wondering why their getting all these requests. Well if its in this state and the submitter's supervisor is a regional director and the part class is "construction" it should skip this person and go directly to this person. If it then gets rejected at that point it should go back to Bob in accounting who will either delete it or modify it and send it back to the submitter's branch manager.
I ended up writing so many rules and exceptions to rules that I ended up with like 1000 lines of VBScript that were incredibly fragile. It would take a day to make a simple change because of all the debugging and verification of other rules.
Terry Young on Sep 16, 2009 at 8:58:37 PM (# 3)
This message has been edited."Workflow logic", ah, I can feel the pain already. And if the app's approval process is not configurable it might even be more painful, because company policies may change, and code logic has to adapt.
Which is why I always tend to break the code down into lots of functions, each of them being as generic as possible.
It really feels like over-doing it at first. But in time these become the gut internal knobs and buttons to configure the business logic. If you're lucky a simple change might possibly be just an addition to the existing GUI, and a bit of knob twisting in the back-end code.
VBScript has many weaknesses, and maintaining VBScript/ASP code is a pain. I actually spend more time documenting and formatting the code rather than writing the code itself.
| | Earlier Replies | Replies 2 to 3 of 3 | Later Replies |
To respond to a discussion, you must first logon.
If you are not registered, please register yourself to become a member of the SiteExperts.community.
|
