August 2004 - Posts
As I'm sure everyone knows by now I've gotten to experience first hand how some of our interview candidates write code. The one thing that is most surprising to me is the reliance on all the designers within VS.NET. I'm more of a do-it-yourself kind of guy so I rarely use the designers for building the applications I work on. I code my web forms in HTML view, create connections manually, and very rarely use anything "drag-n-drop".
The main reason for my anti drag-n-drop spirit is that I want to know what's going on in the applications I write. I don't want to be reliant on some visual designer, if need be I want to be capable of dropping into Notepad and kicking off builds using csc.exe. At the same time I like to take advantage of all the goodness that VS.NET provides. I have a VS.NET shortcut list pinned next to my desk, and am all about finding ways to leverage tools to speed up my development. I don't however believe in designers that do things for you, create crappy code, and give credence to inefficient, un-scalable code.
Beware of those designers!
As I stated recently we started doing a hands on programming test as part of our interview process. We've going through a handful of candidates and haven't seen anyone do as well as we'd like nor anticipated. We're trying to come up with a practical exercise that someone can finish in 1-1.5 hours. Rather then present what we're currently doing I'd like to open it up to my loyal readers (you didn't know you were a loyal reader did you).
The Challenge
Construct a coding exercise for an interview candidate that can be completed in 1 to 1.5 hours. The basic things we're trying to make sure of during our test is that the candidate:
- Can use VS.NET comfortably
- Can access a database (SELECT data using a stored procedure)
- Can develop a web form for collecting data with simple validation
- Can insert data into a database (INSERT stored procedure)
- Can display data using a DataGrid, DataList, or Repeater
Are these fair expectations for .NET interview candidates? Are there other things you'd look for?
ASP.NET pages with large hidden viewstate at the top of the page is not good for search engine optimization purposes. One of my colleagues dug up the below code snippet to help with this problem. Is anyone attacking this problem in a more elegant manner?
/// <summary>
/// This method overrides the Render() method for the page and moves the viewstate
/// from its default location at the top of the page to the bottom of the page for SEO.
/// </summary>
protected override void Render(System.Web.UI.HtmlTextWriter writer) {
System.IO.StringWriter stringWriter = new System.IO.StringWriter();
HtmlTextWriter htmlWriter = new HtmlTextWriter(stringWriter);
base.Render(htmlWriter);
string html = stringWriter.ToString();
int startPoint = html.IndexOf("<input type=\"hidden\" name=\"__VIEWSTATE\"");
if (startPoint >= 0){
int endPoint = html.IndexOf("/>", startPoint) + 2;
string viewstateInput = html.Substring(startPoint, endPoint - startPoint);
html = html.Remove(etartPoint, endPoint - startPoint);
int formEndStart = html.IndexOf("</form>");
if (formEndStart >= 0){
html = html.Insert(formEndStart, "\n" + viewstateInput);
}
}
writer.Write(html);
}
steve$ cat hello.cs
using System;
public class HelloMonoWorld {
public static void Main() {
System.Console.WriteLine("Hello Mono World");
}
}
steve$ mcs hello.cs
Compilation succeeded
steve$ mono hello.exe
Hello Mono World
steve$
Today I interviewed our first candidate under our new process. We started with a quick 30 minute written test covering some basics and then dove into a hands on programming test. During the hands on test it was apparent that the candidate had a different development methodology then myself. He preferred using dataset/typed dataset, where my preference is with custom business objects. He seemed to have a decent grasp on many of the topics covered but the whole dataset thing made it difficult for me to get sold on him, after all he was not "like me". It seems appropriate to separate my personal development preferences from the interviewing process since every organization does things differently. When you interview candidates do you look for people "like you"?
I've always thought it would be cool to work for Microsoft. A big software behemouth that spends lots of cash on developing kick ass software, what could be better? On top of that, how can one not be intrigued when MS is gobbling up talent left and right all around the blogosphere? It must be "the place" to work if guys like James Newkirk, Ward Cunningham, Peter Provost and crew are taking the pill.
Maybe when they move the corporate office from Redmond to Philly I'll apply. 
What I heard Bill likes Philly. Unfortunetly I think the realization I had regarding my interviewing skills would keep me from getting very far. Oh well, maybe some day....
Recently I heard word from a colleague that a .NET application that we had written is leaking memory, or at least appears to be. Over the course of a month our asp.net application slowly increases its memory consumption until the server gets bogged down and is rebooted. The memory consumption reaches about 1GB when the month "mark" rolls around. The site will then run for another month, and again slowly increase its memory consumption to 1GB. I haven't done a review of the code as of yet but will be doing so shortly to ensure everything is in order.
Are you seeing memory leaks in any of your applications? If so do you have any tips, pointers, or advice on tracking down the problem?
In previous posts I've written about how I believe being lazy makes me a better programmer. Today I'm going to talk about how using lazy objects can have a counter affect. In many of the applications that I write I have properties that are lazy loaded. A lazy loaded property starts out as null, and upon the first access to the property the value is retrieved from the data store. This can help reduce the load on the database server and can help ensure we only access the data that is necessary.
If your not careful with lazy loaded properties you can quickly run into trouble. This past week I was investigating a performance problem in a section of an application that was utilizing objects with lazy loaded properties. To make a long story short the lazy loaded properties were causing an extra database hit for every row of data that was being displayed on the screen.
To tie this into a couple of my recent posts on Domain Driven Design let me state that although I'm not sure it would have prevented the problem, I think had I created repositories for the aggregates within my application I would have avoided the problem. Rather then allowing my objects to retrieve data from the database I should have had everything go through a repository. This prevents our objects from running a-muck. Our repositories can control exactly what is and isn't returned, and we reduce the risk of our objects going nuts with database calls.
Beware of the lazy loaded properties!
My post on WS-Addressing was quoted in Peter Cofee's recent "Addressing Web Services Interactions" Developer and Web Services eWeek column. And yes, "WS-Addressing is cool." (what a geek!)
Today while I was coding away on this Java project I'm working on I realized I needed a little .NET love so I decided to bring up .NET Rocks and listen to the Clemens Vasters interview. As you'd expect the focus of the interview was on services. One of the things that was just covered was that Web Services should only accept a single parameter (or message). What this means is that we don't do this:
[WebMethod]
public bool CustomerExists(int customerID) {
// implementation
}
By coding our web service to accept a single integer as a parameter and returning a boolean we have limited our web service, and made it very difficult to expand upon the implementation. Instead of using an integer and a boolean in our implementation we should be using messages that wrap the integer and boolean. Web Services are about messages so don't ignore them when developing your web services just becuase VS.NET makes it possible to ignore that fact. Instead take a message based approach to developing your services. Wrap your web service parameters in "messages" and return the results in a single message.
public class CustomerExistsRequest {
int customerID;
}
public class CustomerExistsResponse {
bool doTheyExist = false;
}
[WebMethod]
public CustomerExistsResponse CustomerExists(CustomerExistsRequest request) {
// implementation
return new CustomerExistsResponse(doTheyExist);
}
What is it about donuts that make them so irresistible? Every Friday we get donuts, and every Friday right after I finish my donut I think, "why did you just eat that?". But regardless when the next Friday rolls around I get sucked right back into the kitchen for another donut.
Recently we've had a number of interviewees come in who could answer some pretty detailed questions about .NET, but, couldn't code worth a sh*t. What's the deal? Do Microsoft developers just sit around reading MSDN all day and not actually code anything?
Today we sat down and re-vamped our interview process to include a coding exercise. I'm going to sit down with the candidates and make them code. When they get stuck I'll be there to lend a hand, and when they totally bomb I'll be there to give them the boot. It should be exciting :-)
How do you find people who not only talk a good game but can code like a pro as well?
Note: By “anyone” I mean the select few we've had come in recently on a contract basis. I do not mean the .NET community in general, since that would mean that I can't code worth a crap either, which obviously isn't the case ;-)
I'm sure all of you loyal followers of my blog have noticed I've been a little quite lately. I've been heads down working on the re-design of an e-Commerce site that is using the MarketLive eCommerce engine, which is J2EE based, which in case you didn't know means its not .NET based, which in case you didn't know means I've been stuck working in Java/JSP, which in case you didn't know makes me an un-happy camper, which in case you didn't know means I don't blog as much.
I see the light at the end of the tunnel, so hopefully I'll return to normal some time soon....
Repositories are used to re-create instances of objects from a data source. Rather then placing the burden of retrieving data for object creation within our domain objects we should separate out that concern into "Repositories". A repository is responsible for retrieving the data for our objects from our data store and re-creating instances of these objects using the data. By abstracting the data retrieval operations out of our domain objects we provide greater flexibility within our domain. We also ensure that our domain objects don't end up with knowledge of things they just shouldn't. Since our objects aren't junked up with all the logic for data retrieval and object creation they can stay focused on representing our domain and the domain logic that makes up our applications.
After a repository has retrieved the data for a domain object it needs to re-create the domain object using the data. There are times when the logic for performing the loading of the object from the data is appropriate within the repository, however, we'll often want to create a Factory object for this purpose. A factory is responsible for the creation of objects. The factory may be responsible for creating new object instances, as well as re-creating instances of objects from data. By separating responsibility of object creation out of the repository we allow the repository to stay focused on its tasks of retrieving domain data out of the data store.
Let's look at a quick example:
public class Customer {
private string _firstName;
private string _lastName;
public string FirstName {
get { return _firstName; }
set { _firstName = value; }
}
public string LastName {
get { return _lastName; }
set { _lastName = value; }
}
}
public class CustomerRepository {
public Customer FindByID(int customerID) {
IDataReader dataReader = ...;
return new CustomerFactory().Create(dataReader);
}
public bool Save(Customer customer) {
// save customer
}
}
public class CustomerFactory {
public Customer Create(IDataReader dataReader) {
Customer customer = new Customer();
if(dataReader.Read()) {
customer.FirstName = dataReader["FirstName"].ToString();
customer.LastName = dataReader["LastName"].ToString();
}
return customer;
}
}
// UI Code
CustomerRepository repository = new CustomerRepository();
Customer customer = repository.FindByID(99);
// update fields/properties
...
repository.Save(customer);
By separating the responsibilities of data retrieval into our Repositories, and object creation into our Factories we allow our domain objects to stay focused on representing the domain. We also allow our applications to become more de-coupled which allows us to more easily test our applications.
I'm trying to find a viable search component to use with a website we are pitching to a pretty good size client in the financial services sector. Can any of the Microsofties out in the blog world point me to any information about how we might be able to leverage Sharepoint Services to provide search functionality similar to what ColdFusion MX provides via it's bundled Verity search “component”? Please help