Run, RUn, RUN for you lives - ....it's DYNAMIC SERVER CONTROLS!!!!!

That's it, I give up! That's right, I'm finally admitting defeat to dynamic server controls in that they are simply not worth the trouble. And believe me when I tell you, it's not for a lack of trying; anyone who knows me very well is fully aware of my die-hard perseverance when it comes to tackling challenges, especially programming ones.

What, you may ask, brought on this sudden and extreme conclusion? Well, after posting yet another question to the asp.net forums regarding some inexplicable and bizarre behavior amongst my dynamic server controls, I received a very helpful and eloquent reply from a fellow developer. Contained within this reply was a link to an article written by the developer titled Dynamically Created Controls in ASP.NET. I highly recommend visiting the link. In it you will find a series of scenarios involving dynamic server controls, revelations about said controls, followed by more questions. In my own quest for decrypting dynamic server controls, I had made it about 3/4 of the way through scenario 2 when I discovered this article. I relived each agonizing, recursive cycle of question, discovery, revelation, followed by additional confusion while reading this narrative.

And then it hit me like a ton of bricks: I have neither the desire nor the free-time to invest in a topic so complex and unpredictable that I cannot even effectively use it until I've spent countless hours and days delving into the idiosynchracies of ControlState, ViewState, Page events, control properties, etc. And more importantly, I'm not alone in this struggle. I give you exhibit A; an extensive and in-depth article detailing the struggles of understanding dynamic server controls written by a developer who is clearly far more fluent in asp.net-ese than myself, with an inconclusive ending suggesting a semi-foolproof, hackish sequence of steps to follow when implementing dynamic server controls.

The irony here is that the entire precedence and purpose of web/server controls is to reduce developers' coding time substantially while reducing redundancy and simplifying the old-school, do-it-yourself controls comprised of your own custom HTML and JavaScript. While I have found Microsoft's non-dynamic web and server controls to serve those functions marvelously, their dynamic server controls have incorporated far too many subjective elements as to the behavior of the controls and nothing remains intuitive. Furthermore, they have done an inferior job of providing documentation citing exactly how and why dynamic server controls' unpreditable and seemingly erratic behavior is determined which leaves developers no options other than inefficient, tedious trial-and-error methodology. which has taken me far more time and energy then it would have to build my own old-school custom HTML and JavaScript controls.

[Descend from Soap-box].

No, wait...this is MY blog, my own little television station where it's all Tracy, all the time.

[Re-ascend to Soap-box].

So I'm a Yuppie? There are worse things.

I finally tried it. I did, I really did.
Yesterday I drove 6 blocks out of my way to get my morning coffee at the local one-of-a-kind, not-some-giant-chain coffee shop named Influx.
And I did it again this morning.
And tomorrow, I'm going back to my Starbucks.
You can go ahead and hate me if you want, but I love Starbucks. I love coffee. And I love that I can be in virtually any city in the world and still get exactly the coffee I'm used to prepared exactly the way I'm used to.
I've heard about all the evil and devious things Starbucks does to chase away helpless, tiny, little, local coffee shops just so they can rule the coffee world and make a few more bucks. But I don't care.

The Influx Cafe is everything Starbucks haters love; it's hip, it's reasonably priced, it's got eclectic, healthy food like sandwiches with beets and sprouts, and it's chock full of all sorts of interesting people who would probably be fascinating to talk to, but I don't care.

On a good day, I spend approximately 3.5 minutes in my local Starbucks, getting my morning coffee, and that's how I like it. Because, true to my nature of Yuppie-dom, I must hurry off to work so I can make my millions. Is that so wrong? Why should I have to apologize for appreciating efficiency and convenience? Well, I'm through apologizing, I'm through cringing in anticipation of people's reaction when I tell them how much I love Starbucks, and I'm through strategically concealing my Starbuck's cup as I sneak past the locally owned coffee-cart outside my office building.

Loving Starbucks doesn't make me a money hungry, self-absorbed, victim of corporate America anymore than hating Starbucks makes those who do, tree-hugging, starving-artist, hippies.

Good 'Ole Engineering Estimates

Just how much dynamite does it take to blow up a whale? Apparently less than half a ton.

Exploding Whale - November 12, 1970, Florence, Oregon

Well, Kiss Maaa Gritz!

A Liddle Riddle:
There was a woman who lived on the top floor of a very tall apartment buliding. Every day when she would come home from work, she would ride the elevator all the way to the top ONLY when it was raining or when there were other people in the elevator. When none of the above was a factor, she would ride only half way up the building, then climb the stairs the rest of the way to her apartment. Why?

It took me a while to get this one - the image I attached is a hint (probably an obvious one).

Cooking with XSLT

At the risk of sounding like the biggest geek in the world (waaaaay to late in the game to be worried about that anyway) - XSLT is starting to reveal itself as a remarkably flexible language with a high coolness factor. Short for eXtensible Stylesheet Language Transformation. XSLT is a functional language designed to transform XML into HTML, XHTML, PDF, other XML formats, or basically anything else you want to output from it. XML is basically just style-stripped text organized into a meaningful hierarchical format. If you've every worked with SGML, XML is basically just the well-formed version of SGML (think Twins, the movie, with Schwartzneggar and DeVito - XML is the kid every parent wishes for and SGML is its job-hopping, looser, screw-up brother).

Anyhoo, back to the coolness factor surrounding this language. I first had the pleasure of working with XSLT when a former employer dubbed me the team "Stylesheet Expert" and tasked me with converting numerous XML military technical manual documents into HTML and PDF format. I refer to it as a pleasurable experience now, but the language of XSLT is very far removed from the functionality of most other mainstream languages out there (C, C++, C#, Java, etc.) and it was a serious pain in the brain trying to understand how it does what it does. For instance, XSLT does not have true variables in the way most other languages do, rather its variables are more like constants and the language itself is purely recursive, not iterative; another far cry from most other languages I'd worked with.

In spite of our initial quarrels, eventually XSLT and I learned to get along quite well and my most recent employer stumbled onto my hidden talent and tasked me with developing stylesheets for their military technical manual XML documents. This time, though, I had some slightly more severe requirements from the client and I've gotten a real taste of just how powerful XSLT can really be.

The website itself was quite straight-forward; some simple Javascript for dynamic table of contents behavior, a slew of internal/external cross-document links, but otherwise quite static and mellow. There was, however, an enthusiastic request for some search box functionality. Not a big deal until I learned the clients (military peepz) were not real excited about any third party packages or extensions being included on the distribution CD and the red tape required to get approval for such an inclusion was soooooo not worth the time or effort.

After some google searching I found a couple of simple scripts that would strategically escape a search phrase typed into a text-box and then hunt through delimited strings of text within an array for a match. Would this be a truly useful methodology for a traditional website; probably not if it were a sizable site with plentiful content, but for my situation, it was absolutely perfect. I could dynamically construct, not only the Javascript itself, but the javascript array of content; dividing the text into chunks according to the pages and URLS I was creating on the fly. It worked like a charm and took me maybe a couple of hours to write code that filled a couple thousand element sized array with every bit of content of the entire website. And best of all, I would never have to worry about updating the array when changes/additions were made to the site content; just a simple command line utility to reprocess the updated XML and viola - any new content is automatically integrated into the site.

Composing a website using XSLT is alot like writing a recipe that matches all the ingredients you already happen to have lying around your kitchen, to prepare exactly the meal you're craving. XSLT is not necessarily ideal for all situations, but if you're responsible for maintaining/developing multiple sites with virtually identical templates, or the content of your site changes heavily and frequently, but the template in which you display it does not, ooooor you're just a big geek like me and feel like tinkering around with some "cool" [in every un-cool sense of the word] technology - then take it for a test drive.

Some useful links:

• XSLT on Wikipedia
• Xalan - The Apache Freeware Processor I use for performing transformations.
• W3C XSLT Specs
• If you're more of a book person, I reccomend O'Reilly's XSLT.
  

There is no 'I' in style-sheet so feel free to drop me a line if you need any assistance my fellow XSLT-ers.
Good luck and happy transforming!!

Bubble Girl

It really is true what they say; that adversity forces you to improve; whether it's physically, mentally, emotionally, or a combination of all three. Given the option I think I'd still prefer to avoid adversity at all costs, but short of confining myself to a giant impenetrable, sanitary bubble; I'm bound to encounter adversity in this world.

A few recent encounters with a particular source of adversity have forced me to really question why I religiously pursue a modular program design for all of my coding. Up until now, I probably did so because that's what my instructors repeatedly pounded into my brain throughout my education and that's what all the books I've read, written by brilliant, experienced software engineering minds, said was the right way to code. But none of those books ever did a very good job of explaining 'why' it is in fact a better way to code and I'd like to take a shot at it.

Let me start by saying that there is one unique situation in which a modular approach to software design will not be beneficial: A program that is completely error free, will never need to be modified in any way, and for no reason will ever need to be looked at or edited for the rest of its existence in this world. I'm gonna go out on a limb here and say that none of the programs you or I ever work on have or will meet that criteria.

Having established that, let's move on. I've had the opportunity, nay the pleasure, of working in multiple environments where one of my primary duties was enhancing and debugging code written by developers who are no longer employed within said company. Such code has broadly ranged not only technologies, but scales, and coding style (most of it very bad - see my Coding Kharma post below). My general response to encountering such code has been a negative one at best with enthusiastic communications to my superiors of my intention to remedy and rectify the current state of their code from this moment on. Surprisingly, I have met with some contention.

Why should I bother investing the extra time to ensure organized, modular code when the program's behavior and performance will indicate no difference between haphazard, uncommented, disorganized code?

I'll tell you why, it's simple math. When I open up a single page of your 8 page application and it's 4000 lines of code long, containing a total of 2 functions (each 800 lines long) and complete with embedded SQL and mystery session variables that suddenly and briefly appear before quickly and quietly slipping back into the black void that is your web-site state; consider for a moment the amount of time I am going to have to invest just to understand the general flow of your application, not to mention reach the granularity I need to in order to perform whatever task it is that I need to do. Now calculate the amount of time it would have taken you to incorporate a simple 3 tier (view, business logic, data access) architectural approach to your application complete with meaningful variable/method names and some simple comments indicating the business logic behind your commands, and I guarantee the first value will far exceed the second.

Software design architecture isn't about the amount of memory you're using or the performance of your application (although indirectly it can benefit these elements), rather it's about abstraction. Nobody would write a book that was just one giant string of text in random order. A book has a first page followed by a second page, further divided into organized chapters, paragraphs, and even sentences; so should your code!

Looking at the view component of your application should give me the visual elements (and that's it). Your business logic code should do just that and do it in a modular/functional way so that each individual task is placed within its own (short) function with a meaningful name. Scanning your function titles should be the cliff's notes of what takes place on the page itself. The Data Access layer should consist of nothing more than a bridge between your business logic and the database.

Knowing how to write code that works might make you programmer, but the ability to write code that can be effectively, efficiently, and repeatedly maintained and upgraded with little to no direct input from you the author, makes you a good programmer.

Coding Kharma

For the love of all that is holy in this godforsaken world...pleeeez, pleeeeez, pleeeeez, when you're writing your code, consider the people who are going to have to modify and debug it down the road. I am fully prepared to launch myself off the 2nd story of this building right now because I'm trying to fix yet another program written by my nemesis, we'll just call him T.C., for Terrible Coder (oh, yea, I went there). T.C. is the programmer whose place I took in my current position whom I've never actually met, but from all accounts by my co-workers was a squirrely, unhygienic fellow with a preference for hippo-like women and who, hands down, has written the most unmaintainable, nightmarish code I've ever seen in my limited life.

Here are a few token characteristics of TC's code:

1. Never a single comment of any kind.
2. Never any modularity of any kind; if TC does write functions, there's no logical separation and they're typically anywhere from 100-600 lines of code per function.
3. No logical organization of any kind within the code itself; the order of the programs seem to simply mimic TC's haphazard thought patterns.
4. Extraneous code (this is the worst part). TC will often leave code in his programs that does absolutely nothing; like requesting session variables that don't actually exist at the beginning of the file and then never actually using them.

Fellow programmers, we're all in this together, writing code, modifying other's code; it's like one big programming circle of life. We're all ultimately serving the same purpose and none of us wants to be considering ending our own life because of a lazy, incompetent fellow developer's work. Furthermore, it is a well known fact that all of the coding horror you create for fellow programmers due to your malicious and incompetent coding practices will be visited upon you 10 fold. So do yourself a favor and practice friendly coding techniques so your coding kharma will be good.