Finding our collective development identity…

August 8, 2008 02:18 by jclark

The last few weeks, with my return to focus on development, have been somewhat revolutionary for us as a development team.  We’ve really started working on what we want to be as a development team, and where we want to go.  As a team, we read the excellent e-book Foundations of Programming by Karl Seguin, which is kind of a peek into the ALT.NET world. 

That caused some developer soul searching, as we realized that we wanted to focus on Domain Driven Design, but we’re not 100% convinced that NHibernate is the way we want to go for O/R Mapping.  Maybe I’m misunderstanding it (and that’s certainly a reasonable expectation), but in our case, where we are using MS SQL, period, it seems like a lot of decoupling for no real return.

In the context of YAGNI, it seems like a lot of extra mapping that doesn’t really need to be done, if one uses LINQ to SQL, as we do.  Now, granted, I recognize that does inherently somewhat limit all of the testing that can be done.  But if the focus is on the domain objects, my thought is that if they are tested thoroughly, and pass, then we’ve certainly done due diligence and should be good to go.

As much as I recognize that becoming a better developer by understanding and applying more OOP principles to our development is essential for career progression, longevity, and personal satisfaction, at the same time, I recognize that it can go too far.  I DON’T have a C background.  I DON’T have a Java background.  Shoot, I don’t have a programming background, outside of the .NET world, so I have grown up eating the Microsoft cereal, and drinking the Microsoft Kool-Aid, and I haven’t found myself to be malnourished or parched, so it must not be THAT bad, right?  Granted, I’d like to make that cereal into more of a 3-egg omelet, and I’d love for that Kool-Aid to become more like sparkling grape juice, which is why we’re working on becoming better OOP developers, but I certainly think that baby steps in that direction are the right move.

On another front, that of overall project management methodology, we had proven to us this week the necessity for moving towards Agile/Scrum.  We had a project which was not properly scoped out, with little communication and guess what?  It ended up not being what our “customers” wanted and required additional work out of scope to get it up to where it needed to be.  It was absolute solid and real proof that we HAVE to move to iterative development.   We have to include the project sponsors in weekly meetings to review progress and make small changes, rather than sweeping ones.

Now I’ve just got to find some good training for the team…


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Why Agile? Why TDD? ALT.NET? Do we want to be “ALT”? Yes, I think we do…

July 11, 2008 01:33 by jclark

Over the past few weeks, I’ve woken up.  Stepping back out of an IT Director role to being the Development Team Lead has helped me really get focused on where this team needs to go, thinking wise.  We have, to this point, developed some really great apps that help make this agency work.  But there’s so much more we need to do, and we have to get some thinking in place regarding how we do things.

Luckily, in our new IT Director, we have a man with MUCH experience and wisdom who is getting Project Management principles established, and that allows me to focus on how we can code going forward to ensure we are as effective as possible.  Of course, I’ve decided to look into Agile, and the best way to apply principles of iterative development to this ASP.NET team.  Luckily, I ran across a GREAT e-Book about ALT.NET and changing the way of thinking as an ASP.NET developer.  That e-Book is called Foundations of Programming, written by Karl Seguin (at http://www.codebetter.com).  I’ve read the first 20 pages so far, and I’ve assigned it to the team to read in order to create some thinking.  It definitely did that for me.

Having started my true development career in ASP.NET at Dell, I essentially ended up doing everything the MSDN way (as Karl puts it).  As a result, I broke nearly all the rules of classic development.  I’m having to rethink the way I’m doing things now, in order to make them what they should be.

So why Agile?  Why use Test Driven Development?  To paraphrase Sir Winston Churchill, “Agile and TDD are the worst forms of development except for all those others that have been tried.”  It’s funny how reading and working on the code in a different way has been really challenging to the status quo.  Along those lines, John Maxwell quoted Ronald Reagan in Developing The Leaders Around You, as saying, “Status quo, you know, that is Latin for the mess we’re in.” [emphasis added].  Well, we’ve not been in a real mess, but it could certainly be better.  So, we begin thinking in terms of iterations, not huge builds.  We begin thinking in terms of YAGNI (You Ain’t (hey, I’m in the S’th <—Mitch Hedberg reference, btw) Gonna Need It).  We begin thinking in terms of decoupling the code from the UI.  For real.  We start looking at ASP.NET MVC, and we start to really get it all of a sudden.

To my friend Jayme Davis, huge thanks for providing a little bit of information to help reassure me that I’m not losing my mind here.  He was a mentor at Dell, and has continued to be a great mentor ever since.

It feels good to be awake…


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Telerik Calendar: Hide the bloody week numbers…

June 26, 2008 04:22 by jclark

Sorry for the bloody, our new IT director is Australian.  Blame him…

Anyway, I love the Telerik RAD Controls, but I had a devil of a time trying to figure out how to hide the stupid week numbers on the calendar.  I don’t really think they serve much of a purpose, and one of our users asked that they just be removed.  Unfortunately, they’re not called “Week Numbers” in the properties.  To hide them, you have to change “Show Row Headers” to false.  Come on Telerik, why can’t that be at the top of the documentation online.  It seems to me that the default should be off anyway, as I would argue most people don’t need to see week numbers, or select weeks at a time from a DatePicker.

So, this is my reminder… :)


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

UpdatePanelAnimationExtender, it really works!

June 13, 2008 02:22 by jclark

 Thumbnail via WebSnapr: http://asp.net/AJAX/AjaxControlToolkit/Samples/UpdatePanelAnimation/UpdatePanelAnimation.aspx

Well, it really works ONCE you figure out how to do it…

On the app I’m currently developing, I was looking for some way to give visual feedback that a postback had occurred in an UpdatePanel.  We use ASP.NET AJAX for most of the AJAX stuff we do, as to be honest, it’s easy and works well for what we need.  Since I use small UpdatePanels to take care of most of the heavy lifting of AJAX, I wanted to just give a visual confirmation when a panel had been updated.  In this case, the control was a CheckBoxList that is updated either via adding a new item to the list or by changing what’s checked on it. 

The nice part was that once I actually figured out how to get the code working correctly, it was really easy to implement.  A few things I found that may be obvious, but aren’t specifically stated:

  1. The target control HAS to be an UpdatePanel.  I know it should seem obvious, but for some reason, it didn’t click in my head. 
  2. As the Animation controls are actually XML markup, the tags must be CAPITALIZED.  Specifically, I found that the <OnUpdating> and <OnUpdated> tags have to be capitalized, or the code returns a bit of a strange error.
  3. If you put an <OnUpdating> tag in your code, you HAVE to add an actual Animation to it.  It can’t just be empty.

It must be said, the XML syntax for doing animation isn’t NEARLY as friendly to use as, say, jQuery UI, but once you get used to it, it works quite well.

I’d recommend you try it in order to make your applications that much more responsive.


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

I think we’re getting this whole Subversion thing…

June 12, 2008 10:24 by jclark

As a development team, we have decided (well, I guess officially, I have decided) to go with Subversion as our version control system, as opposed to using Visual Studio Team System.  We had previously used VSTS, and the locking method of source control just did not work for us.  We much prefer the methodology that Subversion uses, namely modify-merge, rather than lock.  It just makes more sense!

We’re using TortoiseSVN as our client and so far, I’m very impressed with it’s ease of use and the ability to have it do the things we want to do.

We had to come to grips with the terminology (Commit, Merge, Update, Diff, Import, etc.) and thanks to the free e-Book Version Control with Subversion we have been well educated.  I have to say though, why can’t Microsoft get this?  Why does VSTS have to be:

  1. so difficult to administer?
  2. so cumbersome to use on a daily basis in a team setup?
  3. based on the lock methodology, which seems counterproductive to the idea of collaborative development?

It seems they could learn a ton from this open source project.  Oh well, either way, we’ll use Subversion, enjoy it, and get more done.

BTW, we’re looking at VisualSVN for integration with Visual Studio 2008.  I’ve played with the demo, but part of me just doesn’t see paying for what we can do in the filesystem for free.  Ideas/thoughts?


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Update a LinqDataSource in code

May 23, 2008 08:16 by jclark

For nearly every table in the current app I'm working on (cjTrack National - a media tracking application for national advertising on cable networks), there are modifiedby and modifieddate fields.  Those fields, rather obviously, reflect the last user to modify the record, and most recent modification date.  I'd like to dump them, as I personally find them useless, but the business lead for the project likes being able to use them to yell at people for screwing stuff up. :)

Anyway, when editing the LinqDataSource via a GridView, these fields are set as ReadOnly, as I don't want the modifier changing the fields.  As such, I had to find a way to update them outside the parameters of the GridView.

In the past, with either a SqlDataSource or an ObjectDataSource, I would simply use the GridView Updating event, and throw the UpdateParameters the values I wanted.  Easy enough.  But, as far as I can tell, you can't really do that with the LinqDataSource, because it's parameter-less.

So, I used the Updating event for the LinqDataSource instead, and inherited the updating object with e.NewObject and then set the fields.  A note here, watch for optimistic concurrency issues, especially with a datetime field.

Code follows:

   1: NetworkOwner uOwner = (NetworkOwner)e.NewObject;
   2: uOwner.modifieddate = System.DateTime.Now;
   3: uOwner.modifiedby = HttpContext.Current.User.Identity.Name.ToString();

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Welcome to the cj Development Blog, ahem, version 2...

May 20, 2008 06:27 by jclark

Important thing to learn about virtual servers: you have to have both the vhd files AND the snap shot files to rebuild...  Yeah, oops. 

Anyway, the blog is now back, unfortunately sans our previous posts, but we'll see what we can do about that going forward.


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5