Jay Kimble

You may have noticed that our main feed was recently populated with a bunch of of our new blogger Thomas S. Williams posts (the SubText BlogML importer’s fault... sorry about that... I have tried to correct the problem... sometimes I swear that no one who develops for SubText really tests on community-based sites).

Thomas has been blogging for almost as long as I have (4 years). He specializes in SQL and VB. Check out his stuff! Oh yeah, he’s our first non-US blogger (he’s from the land down under).

posted @ Sunday, June 29, 2008 3:00 PM | Feedback (0)

Share this post:  Email | Digg This! | Stumble This! | Save to del.icio.us | Share on Facebook | Add to Live Favorites |

My good buddy (actually my best friend from High School), "The Witt" complained that I wasn’t being helpful to programmers who are trying to learn the craft when I posted two weekends ago on "A Question you should ask when hiring a non-entry level developer." (OK, he wasn’t the only one... but, hey, we have a history, so he can get me to post a response, and you can’t... deal...)

I decided that our subsequent conversation in email would make a good followup post for those who want to know what they should be doing, and with his blessing I am posting an edited version.

[It started with this comment]

The Witt - OK I know that I am new to the ASP codeing info.
I understand the security issues ( or at least, what might happen with leaving every thing wide open). BUT, Having just completed two semesters of nothing but ASP I just don’t see what wrong... I AM NOT a seasoned programmer...and my classes taught us to connect inthis very manner you discribe...
can you eleborate for those of us that are trying to learn? show us what you would do instead?
thanks in advance

Jay (in Email now)- I know I probably made some harsh statements there (in my blog post). I meant it to be hard, but it was as much about seeing some consultant coming in and writing crappy code against my APIs and leaving HUGE security holes in my website.

The major point is for ASP.NET that you should always use Command objects with parameters... something like this (code may not compile cause its off the top of my head... there’s probably an error in there somewhere...)

   1: Dim query as string = "select field1, field2, field3 from someTable where ID = @TableID"

   2: Cmd.CommandText = query

   3: Cmd.Parameters.Add(new DbParameter("TableID", cbo.Value)

   4: ' Code continues....

The trick is in using the "@" variable in the query, and using the Parameters collection. When this gets shoveled down to the database it gets sent differently and if someone tries to change that "cbo.Value" within the http post by trying to add their own SQL it will fail.

I know that changing the variable in the http post statement sounds advanced... go here --> http://www.bayden.com/TamperIE/, download the TamperIE tool (for IE)  and try it out... You’ll see that you can in fact force whatever values you want into the post.

As far as other dev environments go (I know you deal with a couple others), you want to figure out how to send a prepared statement to whatever SQL Server you are dealing with (ms access has these as well, so does Oracle and everything else I can think of... even the free PostgreSQL has them).

Anyway, I see you as someone who’s growing as a developer... you’d not go into an interview and present yourself as more than you are... that too is the problem...

Do you mind if I post this (more or less?) as a new blog post?

The Witt- I don’t mind in the least…

          Like I said I am trying to learn. The “@” tucked in front… I always thought that was just to get the info from the current page. It’s nice to know what that really does. I do use that for most of my sites. I just never knew all the reasons.

I think that is the problem with a lot of the schools today. They are just pushing the students out and they really don’t know what they are doing. (Not that I always know what I’m doing).

---------------

Ok. it’s not all that edited. One more thing I forgot to mention. If you use an ORM or something that builds classes for you, then you probably are getting this type of functionality (just about every ORM I know of uses prepared SQL statements to push data). My favorite ORM is SubSonic (and I know others rave about NHibernate)... It the Java world I use Apache Cayenne (and people rave about Hibernate over there)

---------------

BTW, I take great pleasure in mentioning that The Witt turns $28 (that’s hex) in a little less than 2 months... unfortunately I turn $28 about 2 weeks before him.

posted @ Tuesday, June 24, 2008 9:15 PM | Feedback (1)

Share this post:  Email | Digg This! | Stumble This! | Save to del.icio.us | Share on Facebook | Add to Live Favorites |

And I mean every developer. If you are an entrepreneur and you are hiring a consultant to work on your hot idea you need to do this. It could cost you everything if you don’t.

I recently took on a side project. It’s a return to a project I did 2 years ago. Since I have worked on it there have been at least 2 other people on the project. I’m writing this for the Business Development guy (the guy I assume hired the other folks). I am not writing this to "cut" on the other developer (I am not perfect), but I did detect a flaw that for me is critical. So one of the other guys is not only not up to snuff IMNHO, but s/he shouldn’t be working anywhere as anything but entry level (I’m sorry to be so harsh, but when you understand what I’m talking about you’ll why I’m being so harsh).

One more thing because I’m writing this more for a non-technical person. You don’t need to pretend to be technical. Pretend like you’ve hired someone to help you assess a programmer, and this is your one and only question.

The Question

When should/would you ever right code like the following (pick the version that applies to you):

   1: // C# Code

   2: string query = "select * from SomeTable where SomeID = " + cboField.SelectedValue;

   3: SqlCommand cmd = new SqlCommand(query, connection);

   4: SqlDataAdapter da = new SqlDataAdapter(cmd);

   5: da.Fill(ds);

   1: ' VB.NET (actually most versions of VB look something like this)

   2: Dim query As String = " select * from SomeTable where SomeID = " + cboField.SelectedValue

   3: Dim cmd As New SqlCommand(query, connection)

   4: Dim da As New SqlDataAdapter(cmd)

   5: da.Fill(ds)

   6:  

   7: ' Thank you Telerik for the quick translation

The Answer

The simple answer is nowhere.

The biggest reason is security. That code enables something called SQL Injection. There are utilities that exist that will let a hacker (actually you as a non-technical person could use them) to steal your entire database via a single whole in your app like this. All kinds of bad things can happen as a result of this. I recently switched grocery stores because my old grocery store had an IT problem where my debit card number got stolen. That kills it for me. I won’t be going back. The same will be true of your customers (if you don’t get sued). So the proper answer to this question means a lot.

A second option is that the programmer might mention the DataSet. This is really less critical (and there are times to do this). The first line of the code is what should be singled out in your mind, because this will tell you if the programmer "gets" security. If s/he doesn’t understand it here... s/he probably won’t understand it elsewhere (you probably have a non-professional programmer pretending to be a professional programmer... take this from a guy who started as a non-professional and doesn’t have a programming degree).

If they suggest making any changes to the first line, then they know what the problem is. They pass. If they leave that first line alone. They fail. By the way, it doesn’t matter whether the programmer is building a web app, a windows app, or some kind of service, this is a universal mistake.

No matter how cheap they are they are creating problems that you don’t need. You can get a good programmer for a lower rate. For instance, I lowered my rate considerably to get a small piece of the pie on the app I’m working on.

posted @ Saturday, June 14, 2008 9:18 AM | Feedback (14)

Share this post:  Email | Digg This! | Stumble This! | Save to del.icio.us | Share on Facebook | Add to Live Favorites |

DonXML has an interesting article over here that got me thinking about a technique I have been using for years now, and I’m not sure I’ve seen much written about it.

The basic tenet begins like this: I avoid session like the plague (not sure why except I have visions of some abuses I have seen... like full DataTable’s stored in session). The only time and I mean the ONLY TIME I use Session is if I have a value that needs to be associated with a user across the WHOLE site. As a result I really try to design my model where there are minimal values that need to be associated with a user site-wide.

What I have seen is that values come in 3 basic variations as far as Web site variables go: Values associated with a user everywhere, values associated with a user necessary for a few pages, values that really are application level values.

My suspicion about "Values associated with a user everywhere" is that they are not as prevalent and are often the result of programmers either not fully understanding web apps, they just aren’t thinking things through, or they are pushing a value into session site-wide when they only need it in a couple places. Treat Session like you do ViewState: it is a snake (maybe a poisonous one) that while necessary to kill the rats in your back yard due to the citrus trees, you don’t want a dozen snakes in the backyard either... Only use the number of snakes that you need (if you have no rats then 0 is the perfect number of snakes). So the lesson here is to really look at your user-related values: determine if they really are used everywhere, and determine if they need to be available in memory the whole the user is on the site.

For values associated with a user necessary for the a few pages, I tend to use cache, or I do use Session (but I clean up immediately after I’m done). When I use Cache I factor in the user’s Session ID. The thing I like about Cache is that I have a much richer set of expiration options. Session sticks while a user is clicking around the site... Cache let’s me absolutely set an expiration time. I also am aware of the fact that Cache can be unloaded early (so I use Cache as a temporary place for a value knowing that I may need to retrieve it again). If it’s something that isn’t stored elsewhere then into Session it goes (even if I have to delete that Session var later). It’s really about managing the data in memory.

For the application type values, I usually forget about the whole Application mechanisms (you might use them, but I do something else), I like to use static/shared values on individual classes. This has the effect of better organizing your code (and if you do any else with the class it simplifies things... I suspect some automated test guys would agree with me on this point). Why mention these here? Well I have seen my share of things that were really application related or indexed application related (such as storing this customer’s company info in session... that really should be either a cache or a static, and it should be retrievable by some company id).

Don’s post was originally spawned by the new Velocity cache from MS. Honestly the only comment I have on it is that I wish they had chosen a different name. I hear Velocity and I think about the text template engine (the one for Java... but the one for .NET is nvelocity)

posted @ Tuesday, June 10, 2008 11:15 AM | Feedback (2)

Share this post:  Email | Digg This! | Stumble This! | Save to del.icio.us | Share on Facebook | Add to Live Favorites |

So the last week or so I have been doing some heavy handed UpdatePanel development (stuff where I needed to fix an existing form that needs help to support an UpdatePanel or stuff where I needed to do something special while the page was posting back asyncronously).

In the midst I discovered some cool mechanisms that I missed!

For instance you can determine whether the current request is an async request by doing something like this:

   1: ScriptManager sm = ScriptManager.GetCurrent(Page); 

   2: if (sm != null && sm.IsInAsyncPostBack)

   3: {

   4:     // do something special here

   5: }

The other problem I had was that I needed to emit a startup script that should execute after the async request finished rendering. It turns out that the ScriptManager control has some really nifty static methods. Here’s the example of what I was trying to do:

   1: //                                  (control, type,   ScriptID,ScriptToRun, AddScriptTags)  

   2: ScriptManager.RegisterStartupScript(this, GetType(), "someID", "SomeScript", true);

Investigate it for yourself... there’s a lot of handy stuff here that corresponds to the same stuff you can do with the Page’s ClientScript object (with the difference being that ScriptManager’s stuff works during a Async Postback)

posted @ Thursday, May 29, 2008 5:20 PM | Feedback (0)

Share this post:  Email | Digg This! | Stumble This! | Save to del.icio.us | Share on Facebook | Add to Live Favorites |

First of all if you don’t know what Script# is, it is a C# language variant available in VS2005/2008. The difference is that it can be used to create JavaScript. The compiler produces an assembly (usable in other Script# projects) and a set of JS files (a release and a debug version). Nikhil Kothari (the author) also has 2 script frameworks you can target: Nikhil’s framework, and the "Atlas"/MS Ajax (aka MS ASP.NET Ajax) framework. There are difference in what you can do when using the "Atlas" framework.

Event Limitations

Let me start with a quote from the Script# Dox (regarding limitations in "Atlas" targeted scripts):

"No support for auto-generated event accessors. Auto-generated event accessors require the existence of a Delegate class with Delegate.Combine/Remove semantics, which are not provided
by ASP.NET AJAX. The workaround is to explicitly implement the 2add/remove accessors for events in your code, rather than have the compiler generate it. "

Basically this is saying there are issues with building events in your classes with Script#. It’s not impossible, but it’s not automatic like it is in Nikhil’s Script# (client-side) framework.

Since I recently had to do this and had to search the Internet for a solution (which there is no answer for), I thought it would be good to document how to do it (for both my reference and for others).

How To Add/Remove Events

That comment about needing to create your own add/remove logic is really simple to handle, but your class needs to derive from Sys.Component (or a class like behavior and control which derive from Sys.Component). The code looks like this (In Script#):

   1: // add a handler to an event

   2: public void add_MyEvent(EventHandler fn)

   3: {

   4:     this.Events.AddHandler("MyEvent", fn);

   5: }

   6: // remove a handler from an event

   7: public void remove_MyEvent(EventHandler fn)

   8: {

   9:     this.Events.AddHandler("MyEvent", fn);

  10: }

The reason we need to derive from Sys.Component is that Sys.Component gives us the Events property. Events is the container for all our events. New ones will be dynamically generated within that container. Let’s see a simple property we can build to easily get the event back when we want to invoke it.

   1: private EventHandler MyEvent

   2: {

   3:     get

   4:     {

   5:          return (EventHandler)this.Events.GetHandler("MyEvent");

   6:     }

   7: }

All of this is well documented. The hard part is. Now I have the event how do I call it with Script#? You might start looking for invoke or apply syntax (which I did. But the answer is quite simple. The EventHandler is a function/method that you can call directly like this:

   1: EventHandler evnt = this.MyEvent;

   2: evnt(sender, new EventArgs());

BTW, you can do the same type of thing with delegates... they’re just simp0le functions.

I hope that helps someone...

[I really need to write a fuller post on building Behaviors with Script# (in case you don’t realize Behaviors are the foundation of ASP.NET Ajax Extender Controls).]

posted @ Thursday, May 22, 2008 9:30 AM | Feedback (0)

Share this post:  Email | Digg This! | Stumble This! | Save to del.icio.us | Share on Facebook | Add to Live Favorites |

I hadn’t seen this mentioned anywhere else. ReSharper 4.0’s Beta has now been released.

This is by far my favorite tool in my arsenal. I find how good of a C# programmer I really am when I have to develop without it.

The latest version has been updated for C# 3.0 (VS 2008 version). I could copy the rest of the feature list, but you can go read yourself. I have been using the EAP bits since right before the Beta Release Candidate and it appears to be really solid with the last couple of drops.

posted @ Thursday, May 22, 2008 8:54 AM | Feedback (0)

Share this post:  Email | Digg This! | Stumble This! | Save to del.icio.us | Share on Facebook | Add to Live Favorites |

My buddy JP (John Papa) is writing a Silverlight2 book. See his blog here and here for more info. JP is known for his DataPoints column in MSDN magazine (and he is an MV, a former co-worker, and former co-blogger... SO, I read his blog).

I found this out a day after I visited the Manning site and purchased to EAP Silverlight2 books. I wish I had known I would have seen what I could do to purchase an early release of JP’s book.

Needless to say I expect John’s book to be really good. I know that he’s an awesome communicator, and has been heavily in this whole XAML space for a while.

I won’t write about my newly-purchased Manning books yet (especially since this is a post where I push John’s book).

posted @ Friday, May 16, 2008 1:38 PM | Feedback (0)

Share this post:  Email | Digg This! | Stumble This! | Save to del.icio.us | Share on Facebook | Add to Live Favorites |

I’m starting a new series on Silverlight2. I am currently building a little SL2 prototype, and as I am learning things I thought I would write them down here.

The first rule deals with working with Designers. It is stated as such.

"Prefer XAML code to CLR/DLR code when it comes building interfaces"

Note the word "prefer" here. That word means "usually", "normally", or "unless there is an exception."

This is best explained by some C# code I saw the other day. It looked something like this:

   1: string ElementX = @"<div class='twocolumndiv'><span class='singlecolumn'>{0}</span><span class='singlecolumn'>{1}</span>";

The problem with the above code is that you’ve embedded it into your code. It’s effectively buried. If someone else needs to change this template to say add a field or to make changes in any manner, they are scanning the code looking for this (provided they know where to look); this will be the cause of much swearing and maligning of your name.

To make matters worse, if you have a web designer you have effectively removed their visibility to this code (maybe this point is made a little sharply; I know some web designers who would be scanning the code as well, but they wouldn’t be happy).

So how does this relate to SilverLight 2? Simple, you should try to avoid instantiate controls on your Silverlight views (pages??) that a designer has no visibility to (in other words, using a UserControl that has an associated XAML is fine, but instantiating a new UserControl and throwing a new layout and a bunch of text boxes should be done with great care... you should know why you did it that way).

posted @ Tuesday, May 13, 2008 12:04 PM | Feedback (1)

Share this post:  Email | Digg This! | Stumble This! | Save to del.icio.us | Share on Facebook | Add to Live Favorites |