Business Cards!

My business cards have arrived from our new printer. They look AWESOME! Everyone else at Rubicite is going to be jealous!

The Bad Taste of ASP Classic Cookies

Recently, Rubicite performed a massive move for a client, transferring a few dozen sites from one server to another. Various things changed about the structure of the site once we moved to the new server, but it went pretty smoothly overall. Today, our client emailed me about an error they were seeing. I obtained a test-worthy login account, and proceeded to try to replicate the error.

And I failed. A simple login did not work. Yet they were able to login with exactly the same credentials I was using. So we start digging through their code, written in classic ASP. After sorting through the web of logic that runs everything, I arrived on a piece of the login system that was tied to writing and reading cookies. Adding debug statements confirmed that the data was there when the cookies were written, and that the data was not being read from the cookies on the other side. So I scanned my system and found that the cookies were indeed present. So I looked further. And read about common problems found in classic ASP cookie processing.

I found that the cookies were created with a path that matched the directory structure they were in on the new webserver. However, when they were retrieved, that directory structure was invisible to the client (as the browser saw the sites as located at the base of their respective subdomain). So the fix became simple: specify the path when the cookies are written. And indeed it was that simple - after making this change and clearing my cookies, everything was back on track and working properly. It's a pretty simple fix too. Just change:
To:

PHP $_SERVER vs $HTTP_SERVER_VARS

If you have ever found that your PHP code using $HTTP_SERVER_VARS suddenly stops working, this info could come in handy. In short, the solution to your problem is probably simply to replace $HTTP_SERVER_VARS with $_SERVER. Keep everything else the same and things should work again. All array indexes should be the same.

This weekend I regenerated the php.ini file that controls how Grinderschool's server interprets our PHP code. This adjustment was performed in order to enable some new server-side functionality that is required for upcoming features that we are adding. It was a very simple process to regenerate, in our host's cPanel. A side benefit is that the new version fits the current hardware model for our host, meaning we get a bigger share of resources now than we could be allotted when we generated the previous config file a few years ago. Access to more memory and more CPU cycles can only lead to better things for the site.

Shortly after the new config file was in place, we discovered major problems with the permissions functionality that controls which videos our users can see. The driver behind this code is a comparison between a user's IP Address and the IP address logged in our database for their session. Experimentation revealed that all users were being treated as anonymous, and thus were denied access to any video content.

Digging further led to uncovering the source of the problem: the IP Address being queried from the database was always an empty string. We were using $HTTP_SERVER_VARS['REMOTE_ADDR'] to access this information. And it was coming up blank. Obviously, something had changed when php.ini was regenerated.

I did not write the block of code in question, so the fact that I always use $_SERVER when referencing this set of variables had no bearing on the overall issue. Rather, we contracted it out during a time when I was far too busy to do all of the site's coding. We have tested it thoroughly since that time, but I never examined the code enough to notice this particular variable. So long as things worked, I probably never would have noticed. But when more things stopped working, I quickly zoned in on this difference in coding techniques. Testing showed that using $_SERVER let the rest of the code work properly. So I made the changes and got everything back up and running.

Then I decided to dig a bit further. Research revealed a few things. First, the major difference between $_SERVER and $HTTP_SERVER_VARS is that $_SERVER is a superglobal. Meaning that it will always be available to any script. That is not the case in $HTTP_SERVER_VARS. Still, both are supposed to have the same values, so long as $HTTP_SERVER_VARS is accessible and hasn't been overwritten by user code. So it is possible that my regeneration of php.ini resulted in a change in whether or not the server instantiated $HTTP_SERVER_VARS. The second difference is that $HTTP_SERVER_VARS has been deprecated. Which could easily lead modern configurations to remove it from the set of variables that are instantiated on the server. So, now the problem is solved and the reason for it is clear in my mind.

The ASP.Net MVC Option

In previous posts, I talked about the ASP.Net Postback Problem and using updatepanels and partial postbacks as a potential method to solve those problems. There's another solution, which may fit better with those like myself (who are moving into ASP.Net from a background with the LAMP stack): ASP.Net MVC

In short, ASP.Net MVC provides mechanism to follow the Model, View, Controller design pattern in ASP.Net development. For many, MVC is a more natural and cleaner way to produce and maintain code. In the ASP.Net realm, it also provides many benefits that address the issues I've railed against in traditional ASP.Net Webforms Applications. Specifically, discussions on StackOverflow repeatedly reference improvements in:

• Separation of concerns (SoC) • From a technical standpoint, the organization of code within MVC is very clean, organized and granular, making it easier (hopefully) for a web application to scale in terms of functionality. Promotes great design from a development standpoint.
• Easier integration with client side tools (rich user interface tools) • More than ever, web applications are increasingly becoming as rich as the applications you see on your desktops. With MVC, it gives you the ability to integrate with such toolkits (such as jQuery) with greater ease and more seamless than in Web Forms.
• Search Engine Optimization (SEO) Friendly / Stateless • URL's are more friendly to search engines (i.e. mywebapplication.com/users/ 1 - retrieve user with an ID of 1 vs mywebapplication/users/getuser.aspx (id passed in session)). Similarly, since MVC is stateless, this removes the headache of users who spawn multiple web browsers from the same window (session collisions). Along those same lines, MVC adheres to the stateless web protocol rather than 'battling' against it.
• Works well with developers who need high degree of control • Many controls in ASP.NET web forms automatically generate much of the raw HTML you see when an page is rendered. This can cause headaches for developers. With MVC, it lends itself better towards having complete control with what is rendered and there are no surprises. Even more important, is that the HTML forms typically are much smaller than the Web forms which can equate to a performance boost - something to seriously consider.
• Test Driven Development (TDD) • With MVC, you can more easily create tests for the web side of things. An additional layer of testing will provide yet another layer of defense against unexpected behavior.

For my part, SoC and TDD are minor issues, at best. I subscribe heavily to Joel Spolsky's idea that it is very easy for Test Driven Development to cross the line into excessive wheel-spinning. I test my products thoroughly, but to add the step of full blown TDD and unit-tests-for-everything crosses the line into more time spent than I can typically justify. I'd rather be getting stuff done.

That said, the other three benefits are great. They seem to perfectly address the parts of ASP.Net development which have thus far led to the most frustration for me.

I'm approaching the point of wrapping up my current project. When that is final (e.g. next week), I will be taking some time to do some learning. At the top of my list is to spend some time working with 1) UpdatePanels & Partial Postbacks and 2) ASP.Net MVC. Once I've played more with each, I'll report back here with my thoughts.

Introducing UpdatePanels and Partial Postbacks

In my last post, I discussed some problems and annoyances created by the standard behavior of ASP.Net controls. Today, I'll briefly touch on the method that I currently believe is the optimal solution in many cases. I have been delaying this post because I wanted to do more research/learning about the processes and methods discussed, and there have been time demands keeping me from that research. Those will fade away soon, and I'll end up doing that research in another week or two. Perhaps it will spawn another article to address everything I get wrong here :)

The issues I collectively termed the ASP.Net Postback Problem may all have a fairly simple solution. ASP.Net provides a container-style control called an UpdatePanel. By wrapping portions of the mark-up into an UpdatePanel, you gain the ability to perform a partial postback. In short, you can restrict the content that is updated during the postback process for ASP.Net controls so that only the content inside the UpdatePanel is updated. Doing this right should mean that you can avoid the "ASP.Net Postback Problems" however, of course, there's a trade-off.

As I understand things currently, the one major downside to using an UpdatePanel is that all of the content inside the UpdatePanel is updated as it would be during an full postback AND only the content inside the UpdatePanel can be updated (barring more complex Javascript loading logic). That means that every part of the page which you want to have affected by the changed control MUST be contained within the UpdatePanel. And those parts of the page will see the same types of behavior noted as the ASP.Net Postback Problems. That's less of an issue than a full postback creates. There's no back-button breakage. And in most situations, it shouldn't be hard to adequately deal with the other issues and create a product that presents a significantly improved user experience.

I don't have any code samples to walk through doing all of this. In my mind, it seems pretty straight-forward, but I don't want to publish code here until I've done it more myself. For now, check out the two tutorials linked above. Once I have done more of this myself, I'll put together a short walk-through.

The ASP.Net Postback Problem

Before we get into the meat of today's topic, I have a quick celebratory announcement: Things became legal today. I am now officially a partner in Rubicite Interactive. As of today I own 3% of the company - with a schedule in place for that amount to increase over the years so long as I remain with Rubicite. Huzzah!

---

Now then, back to our regularly scheduled topic. Last time, I discussed reasons that ASP.Net can make server-side interaction easier. There are some drawbacks. Using the javascript-driven update process, we control exactly which parts of the page are updated with our new data. This enables a more pleasant user experience by only having parts of the page reload when we make our changes. Unfortunately, this is not the standard behavior found with ASP.Net controls.

When you use an ASP.Net control and tie it to server-side code as we did in the previous article, any actions you take to execute your handling code must be run on the server. Put that way, it sounds obvious. The resulting implication is that each time your handling code is run, an HTTP POST is sent to the server, and the page is reloaded to reflect the current viewstate. All form elements are submitted as part of that POST request, and ASP.Net automatically refills each field of the form with the previous values before processing your handling code. The entire process is referred to as a postback.

A few things result from the postback process. First, users will see their entire page reload every time a postback occurs. In most situations, much of the page contents will be in cache, so the reload will not take as long as a normal page load. However, users are still likely to see the page flash, at the very least. From a user-interface enthusiast, this bothers me a bit.

The second result of the postback process is an interference with typical browser behavior. Since each postback is seen as a separate request by the browser, each one gets an entry in the browser history. This means that for each change of each server-side handled control, the browser will have a separate page in history. That's not too bad, until users start trying to use their browser's back functionality. Instead of moving back a page at a time as the user tends to expect, the user will have to press back for each change they made to each server-side handled control. For me, this type of user experience moves beyond being an annoyance and into a true issue.

To minimize these issues, one might choose to use standard HTML/javascript for all the elements that do not require server-side handling (e.g. if it doesn't have to interact with the database, keep it on the client-side). That way you minimize the impact to your users by avoiding the entire postback process for a lot of your actions. Most pages will seem more snappy that way. But it creates a slight complication in that the DOM elements resulting from ASP.Net controls are not as easy to interact with in your client-side code. By default, ASP.Net will adjust the ID of the elements generated for the controls to match an internal naming structure. This complicates the process of retrieving DOM elements through any kind of ID-based selector. Most of the time, that complication can be mitigated through use of the ClientIdMode="static" attribute within the ASP.Net control. Specifying this attribute will cause ASP.Net to use the exact ID that you specified for the DOM element it generates. The only place this falls apart is when the ASP.Net control generates more than one DOM element, as only the parent element will get the ID you specified. Even then, jQuery can come to the rescue through providing means to use parent/child selectors to nail down the exact DOM element you seek.

The choice to mix up implementation between standard HTML and ASP.Net controls feels a bit dirty to me. However, given the issues it helps with, I think it can be a valid choice. It certainly fits in the vein of incremental adoption that I like to think can work well. But it does create another problem, and it is perhaps the worst result of the postback process...

When a postback occurs, ASP.Net will automatically place the values for ASP.Net controls back into the related fields. If, however, you are using standard HTML form elements, they will not be given their previous values. A good way to deal with this is to set the default values for the HTML elements to be the result of the information pulled from the HTTP POST request. Since ASP.Net submits the form on each postback, these results will be available to load into the page each time. The only time this really fails miserably is when you already have a default value for a given element. Things get more complicated because you have to start tracking bits of state yourself in the code-behind (though often it is sufficient to set class variables with a default value and then update that variable with the result of the REQUEST variable, if it has a value).

This is all getting a bit hackish, but it works, and it enables you to get some of the benefits of both worlds. Still, you might be thinking that there has to be a better way to deal with the postback problem. In many situations, you would be right. Next time, I'll talk about using partial postbacks to make everything all better.

Easier Server Interaction Through ASP.Net

One of the nice things about using ASP.Net controls in place of standard HTML elements is the ability you gain to do server-side access, manipulation, and processing related to those controls. Let's consider a fairly simple page and look at how the coding process would work in the PHP world and in the ASP.Net world. Then I'll get to my complaints :)

Our simple page will consist of a dropdown selector and some corresponding text input fields. Based on the value of the dropdown selection, we want to populate the text input fields with data from our database.

In the PHP world, a good solution for this situation is to create the main page in HTML. Then you would attach javascript functionality to the dropdown, likely using the onchange event. Something like this:


Then in your javascript, you would provide the functionality to do something with this. Since we want to use it as a key to pull data out of the database, our javascript will basically be a pass through to send the data to our server-side PHP handler code, and then process the result back out to the HTML. Something like:


Then we finally do some PHP. We want a simple script that processes the input coming in, pulls the corresponding info from the database, and then writes the output as a stand-alone block of HTML. Our PHP could look like:


So in PHP, we have three distinct pieces: the HTML that presents the page to the client, the javascript that processes the interactions between the HTML and the server-side code, and the PHP which handles the javascript input and returns the appropriate output. There's a lot we could do to optimize this, such as using JSON to return smaller bits of the results and assign them as the value of the textboxes instead of rewriting the whole block of HTML. But that's not the point of this blog post, so I'm keeping things fast and simple.

In ASP.Net, it's different*. Instead of these three pieces, you have two pieces: a code-front (consisting of HTML elements and ASP.Net controls) and a code-behind (consisting of the functions that the server runs). You don't have to do the javascript processing code, as ASP will create its own javascript and do the attachments to the ASP.Net controls automagically.

*Note: It is certainly possible to do the three-piece approach in ASP.Net as well. You could completely replicate the PHP methodology through an ASP.Net HTTP Handler and avoid the user of ASP controls in favor of using standard HTML elements. The process of doing this would be extremely similar to the PHP process, and it would have most of the same good/bad points.

The code-front would look pretty similar to the HTML we had before:


The code-behind is actually a lot simpler than the PHP. Other than the difference in SQL syntax (which I'd just ask you to ignore, as this post isn't about LINQ to SQL), one big difference is that we can set the values directly to the ASP controls. There's no need for a javascript middleman:


All of that is well and good. The simplicity is great, and it is shorter code. But the really nice thing is that this difference only grows as you start doing more complex tasks. Smaller server-side code combined with minimal need for a javascript processor makes for some great savings in development cycles. But, of course, there are some drawbacks. Next time, I'll touch on the ones that bother me the most, as well as some possible solutions.

ASP versus Me: A struggle for control

I have long avoided the use of frameworks for most of my coding. In development of desktop applications, that is closer to the standard practice than it is in web development. Sure, in desktop development, you'll pull in a package here or there to provide some functionality. Or maybe interface with a dll instead of writing your own drivers. But In web development, there are TONS of frameworks which will do fantastic things for you.

I avoided frameworks for a few reasons. The first was simply that I didn't need them. Over the years, I have had to deal with a wide enough range of coding situations that I felt fully able to accomplish my tasks dealing with base language constructs. Switching to a framework seemed like something that would slow me down rather than speed me up, since that switch would require learning the framework instead of producing useful code. Why waste the overhead in hours when I can crank out the code myself?

The second reason for avoiding frameworks was that bad programmers use them. I have worked with people over the years who cobbled things together with frameworks without ever understanding the basic technology driving them. As soon as you asked for something that wasn't readily available from the framework or a plugin, they would be out of their depth. Why would I want to mimic what such a programmer was doing?

The third reason for avoiding frameworks was that I like having full control over my products. Through things that are abstracted away by frameworks, I stood to lose some of that control. I didn't want coding to become a process of "I know how to do this by hand, so how can I configure OMG-Code-It-Fast to provide the same thing?"

A shift in my thinking occurred when I took a class in AJAX web development at Johns Hopkins. There, I was forced as a part of the assignments to spend time with jQuery, Prototype, GWT, and a handful of others. I saw that while I didn't need them, their functionality could both speed up my development time and produce cleaner, clearer code. I saw that they don't have to be a crutch for bad programmers; they can also be a tool for good programmers to more easily do more with less code in less time. I saw that neither the learning process nor the coding process has to be all-or-nothing with frameworks. There are a lot of shades of grey along the way. If I wanted, frameworks could be used only for speeding up specific tasks. Making complex processes easier. And the learning process could be an incremental one - picking up the pieces I need when I need them.

In many ways, moving from the LAMP stack to ASP.NET development is a lot like adopting a framework. ASP.NET offers a plethora of controls which can then be configured in a dozen lines to accomplish things that might have taken hundreds of lines of code when done coded manually. But sometimes the simplest tasks are aggravatingly difficult due to that abstraction (made worse, I am sure, by my comparative unfamiliarity with ASP). I find myself continually sliding up and down on the scale of integration, using ASP.NET server-driven controls to generate some elements of the page in order to benefit from easier server-side access (especially for more complex database interactions) and using manually structured HTML elements for many others in order to benefit from easier client-side access (especially for actions based around Javascript and jQuery). I think either style is fine, but it does feel a bit dirty to mix the two. Hopefully I am right in thinking that another parallel between shifting to ASP.NET and shifting to frameworks is that incremental steps work perfectly well.

We All Start Somewhere

It has been a while since I maintained any sort of professional blog. I think the last real content I added anywhere was to my classified writings for the government, and for the last 6 months of that, most of the writing was product announcements - very little actual reflection. Today, I start again. I'm motivated to do this because I think it will help me to focus my professional development. Ironically, that thought is hitting home because of reading "How I Made My First Million In Poker", a book on how to progress as a professional poker player. It's an easy read though, with concepts that largely apply to a self-driven professional in any area.

Sometimes I think I'm a great programmer. Other times, I think I'm one of the worst. Most of the time, I tend to figure that having thoughts on both sides of the coin probably means I'm well above average. But I want this blog to help improve, if only through self-reflection.

So that's why I'm here. Now let's cover a bit about my back story. I'll fight my tendency to ramble and do my best to keep this snappy.

We'll start with where I've been: After a pre-college gig doing db-driven web development in classic ASP, I earned a BS and MS in Computer Science through the University of Tulsa. That was paid for by a government scholarship that tied me in to a position with the National Security Agency.

I can talk a bit about my first and last jobs with the NSA, but probably can't answer many questions. I started off working outside the NSA, doing work for a law enforcement agency. Since that work wasn't an NSA thing, I can share. In the span of 9 months, I created a half-dozen programs for detecting and extracting hidden data encoded by various stegonography tools. I rewrote a tool they had for scanning criminal computers resulting in new ways to find evidence while simultaneously improving scanning speeds by an order of magnitude. And I analyzed/tested a distributed password-cracking program to compare methods and results against industry standard tools.

I concluded my time with NSA developing an enterprise-wide collaborative Q&A tool which supported thousands of users. In short, I spent 18-months creating a PHP/MySQL-driven copy of StackOverflow by hand, with results that had many users convinced we had obtained a customized version from the StackOverflow developers.

Outside of NSA, I started a side-business based on my passion for online poker. I created Grinderschool.com, a video training site for providing poker strategy with a focus on low stakes players. I am proud of what the site has grown into, but have some regrets that over the years, most of the development for the site was fast-paced hack-it-out rather than professional quality. That is starting to change, but since it remains a side project, that process is a slow one.

After leaving the NSA six months ago, I joined Rubicite Interactive as a partner in the business. Our main thrust is web development for clients. I developed a site (which has yet to launch) for quickly customizing high-end frames - the kind a doctor would buy to show off his achievements. Currently I am working on a site for managing rental properties. The work with Rubicite is all on the ASP.NET stack, which is a different programming methodology than I've followed in the past. That's where a lot of hangups come from for me currently, and will likely be the subject of a lot of my posts here.