What actually takes the most time?

Next time I write a web page, I'm going to try to keep track of how much time I spend on each task. It seems like I spend the most time doing repetitive things. These are the types that are most easily done by the computer. Two things quickly come to mind. The first is creating a row in a table that has a label and a form field and the second is collecting the form input and putting it into a data structure.

The first could be solved by a user control. I haven't created one yet because it's not trivial. It needs to be able to handle every option on every form control and it needs to be flexible enough that my designer won't nitpick that it doesn't look exactly like the screenshot. This makes me think about whether it's worth the time investment because creating the row is really quick. I've forgotten about the secondary gain: having a form-independent way to create a form.

The Pragmatic Programmer makes the point that it's better to work closer to the domain. This means using their jargon and letting the domain experts define the requirements. It would be very quick and productive if they could type up something that the web site will parse directly into a form, even it's just a prototype.

The second thing isn't just to save time. A class that takes the form response and fills in properties on a data class would be very useful. I haven't done this so far because of the myriad validation possibilities and it requires reflection (which makes me pause but it shouldn't). There are many possible ways to handle validation, including the Validation Application Block or to handle it completely separately.

Web Site Frameworks

My current project has me working in Coldfusion, which is very different from ASP.NET. The most fundamental difference is that it doesn't try to use controls and objects in a codebehind. Coldfusion makes it easy to run queries and output results but mixes database code in with HTML. On one hand, pages are in one file and database access is very easy. On the other hand, the form is strongly typed and you can easily modify page elements in code but the viewstate is quirky but too useful to turn off. They're quite different and I don't know which I like better.

Given only those two choices, I'd go with ASP.NET. Subsonic takes away a lot of the pain of the database access and it's just really handy to be able to say "DropDownList1.Items[1].Selected = true". I think the Coldfusion / ASP method may have more potential with an awesome IDE that's realizes that it's creating a web app (make it easy to get to the querystring / session / database). A hybrid method may be good, something like using HTML controls with properties but that don't get persisted across postbacks.

Rails has a completely different paradigm where you don't create pages, you create controllers and views. I think the best thing about this is that all of the code concerning an object is in one place. Each page has its own view that has very little code. The distinction seems to get murky if you want AJAX because you need javascript code in the view. Also, the view and controller are loosely connected with only an implied contract and unit tests, so I don't know if this is the best way to go either. It probably has the most potential with an awesome IDE, but it doesn't have corporate backing which means that IDE isn't coming anytime soon.

Javascript as a Learning Language

A popular question is what language to start with when teaching a novice how to program. I've seen C and C++ dismissed as too complex and I agree. Java / C# are usually passed over because of all of the explanations necessary for Hello World. I agree with this too because you'd have to tell the student to ignore import, static, void, arrays, braces and explain what the Console is. Usually the next things considered are Perl, Python, Ruby and Bash. I'd go with Javascript.

First, good tools are very easy to obtain. The novice is probably using Windows and would need to download the script interpreter. All you need for HTML and Javascript is a text editor that colorizes such as Crimson Editor or Programmer's Notepad. Running the test involves double-clicking on the HTML icon on the desktop which is not intimidating at all.

Teaching JavaScript allows you to start with HTML, which is very easy to learn. It's easier to understand markup because it's easy to look at the HTML and see "The quick brown and then fox is surrounded by strong and then jumps over the lazy and then dog is surrounded by em which means emphasis." You get to make something cool very quickly when the teacher goes into colors, backgrounds and images.

This leads well into JavaScript. There's an instant UI using the alert, confirm and prompt functions. There's very little syntax that needs to be explained to get started and nothing needs to be skipped. "The tag is called script because we're going to use JavaScript. We're going to alert the user by telling them a number. Type alert(16)."

One day I'd like to put together a "Programming from Scratch" series of screencasts, but I doubt that I'll be able to do it soon.

MVP and Unit Testing in ASP.NET

His picture notwithstanding, it's pretty clear that J.P. Boodhoo is an intelligent guy. I watched one of his screencasts about MVP in ASP.NET and unit testing and I'm a little puzzled. He creates four class library projects to support this paradigm: one for the models, one for the presentations, one for tasks and and another for the DTOs. Even with Resharper, that seems like a lot of work to create a web form with four fields. I'm interested in hearing the arguments for unit testing something as simple as this.

Test Plan as Requirements

My first project at my new job was a pretty simple web site. I didn't use the data controls (like DetailsView), although they would have been appropriate. I didn't write unit tests either, mostly because the application fills out forms that directly reflect auto-generated SubSonic classes. There was one place where I should have written unit tests, but only one. I did write a test plan.

A test plan, in theory, should cover every behavior that the application should exhibit. If the application is supposed to flash the background color every 10 seconds, there should be an item on the test plan that says "The background color flashes every 10 seconds". If there's no requirement for that to happen, it shouldn't be in the test plan. So the test plan should echo the requirements document, if you have one. Which you probably don't, so writing a test plan gives you requirements.

The real reason to write a test plan is to separate you the developer from you the tester. Testing something that you developed is tricky, because if you just dive in and test, you're not going to test very well. You're going to test the things that come to your mind, which is probably the things you worked on the most, which probably doesn't have bugs since you worked on them the most. Writing the test plan properly, by looking at the UI and writing down everything it should do, separates these two personas.

Web Services with Prototype and ASP.NET Ajax

Here's a link to the handler: http://www.subtlereality.com/wsproxy.ashx.html

As I've mentioned before, I don't like using ASP.NET Ajax's client code. I like using web services because they're easy to develop, but I can't find a good SOAP library for Javascript. This makes calling web services difficult. After waiting for a while for someone to write one, I decided to take my own shot at it. My project already uses Prototype, so I decided to use those AJAX tools. It was a lot easier than I thought.

My approach was to figure out how ASP.NET Ajax called the web services and use that method. It clearly knows how to do it. I rolled up my sleeves and delved into the JavaScript library and found.. no SOAP envelope in the entire thing. I dug deeper and found that it sends POSTs with a content-type of "application/json" and the body is a JSON-serialized object. That was easy enough.

The trickiest part was the date serialization. Nikhil Kothari explains the issue in this blog post. Microsoft used "@1234@" in the Atlas betas but switched it to "\\/Date(1234)\\/" which is a lot more frustrating because you need to count slashes and try to figure out how often your string is being interpreted.

In the end, I came up with a HttpHandler that mimics the ".asmx/js" files that ASP.NET Ajax uses. You need to pass in the path to the web service and the .NET class name as arguments through the querystring. For example:


It doesn't deserialize DateTimes as the return value and you don't have as much control over it. If other people start using this, I'll start a real website for it. Feel free to ask me any questions about it.

SqlDataSource

I used the SqlDataSource for the first time today. I switched jobs and now I'm the only developer in the company. It's something I would hate to do if I thought someone else would see it or anyone (myself included) would have to maintain it. I needed to grab html out of the database and spit it onto the page and I did the quickest way I could think of: a SqlDataSource and a Repeater. The Repeater is pretty bad too because there will never be more than one record, but it was quick and it worked. Is the "proper" alternative to load the data in the code behind and stuff it into a literal? Too much work and no gain.

I've posted about unit tests and patterns recently because I thought that I'd need to be more vigilant because I'm the only developer. That may be so for more complex tasks, but spitting out the result of "SELECT html FROM dhtml WHERE id = 4" isn't complex enough to warrant that. I'll need to revisit it when I implement the page that lets you edit the html and I'll rewrite it then if necessary. By then, I'll have SubSonic ready to go.

I'll take the quickest and easiest path, as long as it's reliable.

UPDATE: I took them out today. I had two different kinds of SqlDataSources. One was easier to replace with one line in the code behind. I'm always in favor of less code. The other needed to be rewritten and it required more logic. It was in 4 places so I replaced it with a controller.