Jeff Perrin - Sexier Than You Are

October 2006 - Posts

Thoughts on Code in ASPX Pages

This post was inspired by a comment I saw on another person's blog (which I couldn't find for the life of me, so no linky for them). The comment was in regards to Ruby on Rails use of pure ruby code in the .rhtml view files, and how this was seen as a bad thing. I've written a similar post on my personal blog but I thought my point was worth bringing up again.

How many of you faithful devlicio.us readers would cringe at the sight of the following code snippet embedded within an aspx page?

	<% foreach( Item item in LineItems ){ %>
	    <p> <%= item.Name %> </p>
	<% } %>

On first glance, it looks bad because sometime in the past we were told that embedding business logic in the view is bad. But I'd urge you to look again. Is there actually any business logic in the above snippet? There's none, actually. We're just iterating over a list of Items and printing a property out to the rendered markup. We could accomplish the same thing with a repeater like so:

	
	<asp:Repeater id="repeater" runat="server">
	    <itemtemplate>
	        <p><%# Eval("Name") %>
	    </itemtemplate>
	</asp:Repeater>

Which one is easier to read? It's pretty subjective... The repeater declaration happens to look just like html or xml markup, so it blends in nicely with any other markup that may appear in our page. This blending can be seen as a good thing, or a bad thing if you like to be able to instantly see any dynamic stuff at a glance. The problem with repeaters it can be hard to see exactly what you're iterating over without also looking into the code-behind. The plus side is that you get nice support for alternating item templates, which can quickly make an embedded foreach look ugly.

The real question is, does using a control like the repeater prevent you from sticking business logic in your views? The answer is no, it doesn't.

Just something to think about.

Posted Oct 25 2006, 06:50 PM by Jeff Perrin with 7 comment(s)

Know Yourself

A couple of months ago I commented on Eric Wise's post titled Know Your Role, wherein Eric expounded on the need for a DBA on software projects. I took exception to the rule that DBA's are required, which sparked several comments and blog posts that seemed to fall just short of calling me an idiot for thinking this way. I don't have any real objections to having my ideas questioned... I'm not arrogant enough to think that I know everything. So I took a step back and thought about it for a while, and here's what I came up with.

I believe that one of the only absolute truths that can be stated is that there are no absolutes.

Very rarely is there a clear cut line drawn in the sand. One of my comments drew upon the experience I have gained as a developer on a large project. We have no formal DBA who controls or greatly influences our database design. We do have lots of developers with a great deal of experience designing systems, as well as several who were DBA's or database programmers in past lives. I asked around a bit, trying to get a feel for what the actual SQL gurus thought of our database design. The general consensus was that it was pretty good. Not perfect, but better than most.

Along the way, I did hear a few good stories about DBA's which may account for the developer comments paraphrased in Eric's post ("DBAs only get in the way" and "I'm not doing anything fancy, I don't need no stinking DBA"). In the minds of some of the developers I talked to, the term DBA is a synonym for difficult. I heard tales of entire database designs being entrusted to one sacred individual who was the only person authorized to make changes because someone, somewhere decided that they knew what was best. Tales of insane hacks being made to the application code to work around a schema that couldn't be changed, yet no longer represented the business. I'm guessing that this extreme is what has so many developers spooked.

Now I'm sure someone can point out the inverse scenario... You'll definitely find several if you browse through TheDailyWtf.com archives. The fact of the matter is that "DBA" is just a label. As is "Developer." Having a bad DBA controlling the database on a project may be worse than not having one at all. Having a good DBA who fits in with the team, enabling them to build the system to the specification of the clients with as little friction as possible is definitely an asset.

I still believe that most projects don't need someone to fill the DBA role. They need a group of developers who know what they're doing, from the database up to the presentation layer. I don't think that good database design is that hard for someone who's a little clueful, but it's always a good idea to have everyone involved in the conversation throughout the development process. The more eyes on the problem, the less chance there is of something being missed.

I hope this makes sense, as I'm not sure I've presented my ideas exactly the way I intended. Keep in mind that my frame of reference for this post is based on green-field development of a project. I do realize that database lock downs may be required in some situations. I'm just taking exception to a supposed rule.

Posted Oct 23 2006, 11:31 PM by Jeff Perrin with 3 comment(s)

Filed under: Development

Regarding an Agile Backlash

It's coming, as we all knew it would.

All in all, I think this is a bit of a shame. I'm not one to speak for others, but I'm sure the "originators" (for want of a better term) of agile processes like Scrum and XP are a little disconcerted to see their ideas turned into nothing more than fodder for technical books and recruitment checklists. (I could be horribly wrong about this. I know there are some people who think this was the entire point from the beginning, but I'm not that cynical yet).

The thing that turns so many people off is the steady evolution of the word "agile" into its sexier buzzword connotation of "Agile." These days, everything is fucking Agile this, Agile that. Let's not be distracted by the buzzword... Instead, try to remember the point of it all, and realize that these are just solutions to problems developers have had since the beginning of time.

One of the most stressful parts of being a developer has to be deployment. And especially re-deployment. We want our stuff to work, and we want the people who use our software to be happy with it. I used to absolutely dread uploading changes to an existing site because I was never confident I hadn't introduced new bugs into the code base. Having unit tests solved that for me, personally. I am now pretty sure my code hasn't regressed because of my adoption of this one practice. I happen to enjoy writing my tests first, before I write the code to make them pass, but that's a personal choice and it doesn't detract from the main purpose; being confident in my code. At the very least I'm less stressed out, which is a good thing.

I've worked places before where the developers didn't talk to one another. Stuff would get duplicated needlessly, and developers would go for days down paths that others had previously trodden. Having daily standup meetings where each developer goes over what they worked on yesterday, what they'll be working on today, and what's impeding there progress goes miles towards solving this. I'm not saying that this is the only solution, but it is a good, simple one.

Why does it suck so much when Uber-Developer A goes on holidays for a few weeks? Is it because they're the only one working on a project (or a sizable chunk thereof) and if anything goes wrong while they're gone everyone else is screwed? Why do some developers get so damned smart so fast, while others wallow in mediocrity alone in their offices for months? Is it because Mediocre-Developer B is useless? Try spreading the love around by pair-programming for a while. You don't have to be religious about it, but I've found that having at least some time together with another developer can go a long way towards alleviating the above problems.

How does our code get into a state whereby it becomes extremely hard to add new features? Why do we need 5 lines of comments to explain what a function does? It sure would be nice if we could just look at it for a few seconds to let the understanding sink in. By ruthlessly refactoring our code before it reaches this state we can fight the entropy. It also helps if our unit test suite can be run afterwards to make sure we didn't change the meaning of the code.

The bottom line, and the point I'm trying to make, is that the little bits and pieces that make up "Agile" processes are there to solve very real problems that we as developers have. In the end, it doesn't really matter how these problems are solved or what we call our processes. The purpose is to make our lives as developers easier. The whole point of being agile is to be able to react to change without fearing it.