Monday, May 14, 2012

Philly Code Camp 2012.1–jQuery Presentation

Thank you to all who attended my jQuery presentation this weekend. I had a great time and hope you did too. As promised, I posted my presentation and code samples. It’s hosted on github and you can access it here.

If you have any questions about the content please ping me.

Wednesday, March 21, 2012

Harrisburg .Net User Group Presentation

Thank you to all who attended my presentation last night. I had a great time and hope you did too. As promised, I posted my presentation and coding samples. It’s hosted on github and you can access it here.

I also want to thank all of you who provided feedback. This is invaluable and I love reading them. Especially when they provide honest critiques. If you have any questions about the content, please ping me.

Saturday, March 3, 2012

Properly Handling Exceptions

In my last post I discussed how exceptions should be treated as exceptional and not used to control work flow. Now lets take a look at how we can manage exceptions to provide a positive user experience without sacrificing the intent of the code.

To start lets review the general guidelines to exception management:

  1. Only catch exceptions you expect to occur.
  2. Only catch exceptions if you are prepared to handle them
  3. Keep exception management simple. You don’t want exception handling throwing exceptions, or then you loose all information about what really happened in the first place.
  4. Properly clean up your components in the event of an exception

With these simple rules how could we clean up our existing code?

public class Service
{
    public IEnumerable<Entity> GetEntities()
    {
        try
        {
            var entities = repository.GetEntities("select * from table …");
            return entities;
        }
        catch (Exception e)
        {
            Logger.Log(e);
            return new Entity[0];
        }
    }
}

To start we can catch an explicit exception, for example SqlException. We could then wrap the exception with a custom type and provide the specific SQL statement that caused the error. finally we can throw the new exception allowing the exception to bubble up the call stack. it would look something like this

public class Service
{
    public IEnumerable<Entity> GetEntities()
    {
        string sql = "select * from table …";
        try
        {
            var entities = repository.GetEntities(sql);
            return entities;
        }
        catch (SqlException e)
        {
            var wrapped = new ExtendedException(sql, e);
            throw wrapped;
        }
    }
}

Do you see the changes?

  1. We are only handling SqlExceptions.
  2. We handle the exception by wrapping it in a custom exception we defined and adding the SQL statement to the message.
  3. We then throw the new exception allowing it to bubble up the call stack.

We now have better control of what will happened next. For example our UI code can now distinguish between existing items, no existing items and an exception occurring. A controller action might look like this

public ActionResult Index()
{
    var results = new Service().GetModels();
    if(results.Any())
    {
        return View(results);
    }
    return RedirectToAction("AddNew");
}

Exception handling can be placed in a global action filter that logs the error and redirects the user to an “error occurred” page.

Something we didn’t cover in this example was cleaning up components. This example does require it, but lets take a look at another example which cleans up after itself in the event of an exception.

public IEnumerable<Entity> GetEntities(string sql)
{
    IDbCommand command = null;
    IDataReader reader = null;
    try
    {
        command = connection.CreateCommand();
        command.CommandText = sql;
        reader = command.ExecuteReader();
        while(reader.Read())
        {
            yield return reader.ToEntity();
        }
    }
    finally
    {
        if (reader != null)
        {
            reader.Dispose();
        }
        if(command != null)
        {
            command.Dispose();
        }
    }
}

Here we are disposing of our command and reader components within the finally block. Notice that we don’t have a catch statement, it’s not needed. Granted we could move the ExtendedSqlException into this block, but I wanted to stick with our original code sample.

One last thing to note. The .Net framework contains the keywork using which allows us to write more expressive code when disposing of components. we can rewrite the above block as

public IEnumerable<Entity> GetEntities(string sql)
{
    using (var command = connection.CreateCommand())
    {
        command.CommandText = sql;
        using (var reader = command.ExecuteReader())
        {
            while (reader.Read())
            {
                yield return reader.ToEntity();
            }
        }
    }
}

Which is the exact same thing as our previous block, but the code is much more expressive and easier to read.

Exceptions are Truly Exceptional

Exceptions are meant to break way from the current workflow and inform the user that some unexpected happened. It is not meant to control the workflow the system. Too often I have seen code like this:

public class Service
{
    public IEnumerable<Entity> GetEntities()
    {
        try
        {
            var entities = repository.GetEntities("select * from table …");
            return entities;
        }
        catch (Exception e)
        {
            Logger.Log(e);
            return new Entity[0];
        }
    }
}

The problem is there is no difference between the repository simply not containing any entities and something going horribly wrong in the lower components. Handling the scenario were no entities are present in the repository is completely different than getting a SQL exception, or any exception for that matter.

In other words, if the database returns no entities, I may want to redirect the user to “add new” screen rather than display an a listing of not entities. However, if an exception was thrown I may want to inform the user something unexpected occurred, that the system administrators have been notified and they should log off of the system, until further notice.

However I cannot do that in this scenario because the calling code cannot distinguish between no entities and fatal operations.

This also means the developer must understand the result have potentially 2 meanings. 1. No data is present and 2. an exception may have occurred.

So how can we improve upon this code so we can return the expected results and still provide a positive user experience within the application itself? That will be the context for my next post.

Wednesday, February 8, 2012

Oddities of the Browser

There are many documented (and undocumented) nuances between browsers and how they process a request. Today I came across one that had me stumped for the better part of the day.

I have a bit of jquery that looks like this:

$.get(this.href, function (result) {
      $(result).dialog();
});

with the assumption that result returns a single DOM element, typically a form element. This was working well until the following result occurred

<form>
    <script type=”text/javascript”>/*code goes here*/</script>
</form>

in this scenario the result was in the correct format, but the browser interprets this as

<form></form>
<script type=”text/javascript”>/*code goes here*/</script>

This result will produce to dialog boxes. The one you expect and a second one where you only see a title bar. The second dialog has no content, but scripts don’t have a visual representation. I account for this anomaly I had to munge with the jquery script.

$.get(this.href, function (result) {
        $(result).first().dialog().append($(result).last());
});

Hopefully this will all become a mute point later on. I would like to implement client side templating and keep server calls to json response, but we are not there yet.

Monday, January 30, 2012

New Year, New Job!

Two weeks I parted ways with my previous employer. It wasn’t an easy decision as I had been there for 7 years and my department was tight. More family than co-workers. But it was time to move on.

After a 2 week hiatus I’m now part of the Solutions Practice at CEI America as an Associate Architect! Lots of changes with this move. To start I’m working for an IT company. Typically I have worked for non-technical entities within the IT department. Another big change is working with a team of developers! This is by far my favorite aspect of the new job. A majority of my career has been of a lone developer. Not any more. I have a team of talent to help and challenge me, and vice versa. And finally, the biggest change: ditching the commute in favor of a home office! Well it wasn’t really a choice, I wasn’t looking to relocate across the state, but it’s what made this possible.

My blog will continue to be my own with no direct ties to my new employer. I may also start blogging about other topics too, not just techie-geek-speak.

Tuesday, January 10, 2012

Duty Calls!

Today I came across the following comic strip and busted out laughing. Thought I would share it with you.

 Taken from xkcd: http://xkcd.com/386/


Wednesday, January 4, 2012

My thoughts on Boiler Plate code

During the same conversation about how I structure code the topic of “what boiler plate(s) do you recommend?”.
My answer: none!
You may be asking why. This comes back to the idea of vertical, context specific, slices. Any boiler plate code would be covered by the infrastructure MVC/P, data access, logging, etc. And these frameworks are really boiler plate as they are implementing compound design patterns.
And if there is some form of boiler plate code that emerges from the vertical slices encapsulate it into it’s own object and inject the component into the calling code. Favor composition over inheritance. It pays off every time.

Architectural Design

I was asked recently “how do you go about designing an application”? Let’s assume we know the problem domain and what the application needs to do. The next step is how we go about solving the problem.
Traditionally you have stacked “layers”
traditional ntier
The problem here is that you must assume one builds on top of the other and that all functionality must fall into a specific layer. You typically end up with Fa├žade classes ending up as God classes. Anything that could ever be done to a user goes in the UserFacade class. Orders => OrderFacade… you get the idea. I find this happens because it lines up nice with the picture of n-tier you are imagining in your head.
Instead I like to think in vertical slices where each feature is a slice. Think of a slice as a specific context in which the user accesses the system. Search is a very common feature, so is placing an order. These features will most likely consist of components touching all the “layers” of n-tier, but they are only used in one specific context. (sorry can’t find an image to demonstrate what I’m writing.)
How does this impact the code. When designing by the slice you end up with many small context specific objects all designed to do one specific task. So you have many objects, but each object is only responsible for a small, one, aspect of the system. reading code becomes so much easier and managing the code becomes easier as well because you can keep all the components next to each other.