Submit Buttons: More Useful than You Think

We all are familiar with using a submit button to post a html form back to the server; however, people often overlook their name attribution which can provide the server with additional information to give better context to the request and the user's intent.

I like to name all my submit buttons Action as a matter of protocol. But obviously, you can pick your poison. When you name your different submit buttons all the same thing, they sort of act like a select box with each button representing a submission option.


Client Side:
    <label for="MyFavQuote" >Fav Quote: </label> 
    <input id="MyFavQuote" name="MyFavQuote" type="text" />

    <input id="SaveDraftButton" name="Action" type="submit" value="Save as Draft" />
    <input id="SaveFinalButton" type="submit" name="Action" value="Save as Final" />


Server Side:
String quote = Request["MyFavQuote"];
String action = Request["Action"];
if (action == null)
{
      //Nothing needed for get request
}
else if (action == "Save as Draft")
{
     data.SaveDraft(userId, quote);
}
else if (action == "Save as Final")
{
     data.Publish(userId, quote);
}

Delivering Software Value to your Business: Users per Line of Code

If you work inside a SAAS company objectively determining the value of your software and developer hours may not be easy, but it is certainly less difficult then determining the value of a internal business application. How important is this feature? Is it worth the level of effort in developer hours? Agile attempts to address these questions with story points effort points, but this metric is often hard to communicate to management and does not facilitate the justification of lowering technical debt.

The metric I am putting forward is Users per Line of code (Users/LOC). This is calculated by taking the users of an application and dividing it by all the lines of code that go into making a deployable binary, including files that do not compile such as configurations or stored procedures. This can give a team a rough estimate of their application's value to the business.

When multiple applications share code between them through a shared DLL or other means that do not involve manual copy and paste, the shared code's total lines can be divided by the number of applications sharing it. Conversely, if a team is trying to calculate their application suite's total value they can sum all of their applications' lines of code while only adding the shared code once.

The reason that lines of code factor in to this metric is because by only looking at an application's  total users no value is placed on a developer's time or productivity. Although, life seldom has absolutes, having less lines of code generally makes a modification of an existing feature easier. Additionally, if an application's architecture is conducive to code sharing adding a requested feature will not as negatively effect the lines of code. As far as bugs go, there is a direct relationship between an application's lines of code and the number of bugs that will occur.

I am not proposing Users/LOC as The One True Metric™, but rather an additional metric in the application developer's tool box. Focusing on any one metric can incentivize destructive behavior in any organization. Obviously, Users/LOC must be used in conjunction with other metrics; overemphasis may incentivize poorly readable code.  If your company's CEO is the primary user of Reporting Application X, obviously Users/LOC is not the most appropriate metric.

It is easy to imagine Users/LOC being used as a component of another metric; for example in an agile environment, (Story Points * Users) / LOC. Users/LOC can also be used on a feature basis as opposed to being used for an entire application for enhanced accuracy. There is high value in this metric because it can reduce both over-engineered code and under-engineered code. If Application A is used by one person to simply do basic data entry to one table with minimal validation rules is over-engineered with a 5-layered web service architecture an extremely poor Users/LOC score will result. If application B has the same complex business logic that must be repeated on five different pages but the developer under-engineers by not isolating the business logic in its own layer this metric's score will also be lower than expected.

In summary, Users/LOC can help lead developers and product managers increase their value to the business by both helping to direct resources appropriately and detecting poor architectural and allocation decisions after the fact. More users, more impact and visibility. Less lines of code, more impact potential per developer hour in the future. Maximize users per line of code and maximize your application suite's short-term and long-term value.

Asp.net Chart: Labels Not Showing Up

You might have noticed that when you are making your fancy little asp.net chart that quite a few of your x-axis labels are missing. This wasn't a major issue when you were making a line chart, but when you got to the column graph, missing those labels was kind of a big deal. Not to worry, the solution is fairly simple; although, hard to find if your googling skills are as bad as mine.

You merely have to set the Interval attribute to 1 in the LabelStyle tag. Markup sample below:

I also set the Interval to 1 in MajorGrid to make sure every column had its own tick mark. Additionally, I set the Angle to 45 to give each label more room (and it looks cool); but, in order for this to take effect you have to set IsLabelAutoFit to false  in the AxisX tag.

Happy coding!

Linq to Entities, not wrong or right

At this point in my career, I have had the pleasure of having Linq to Entities be made both mandatory and forbidden by management decree. All I can say is, whether you want to ban L2E or mandate it, you are wrong.

If you have a simply structured application Linq to Entities can save you an absurd amount of time that can be used to do things like make your application more usable. For applications whose databases can be described by simple one to many, or many to many relationships, Linq to Entities can be quick to code against, have reasonable performance, and present a shallow learning curve. For more complex reporting pages, Linq to Entities can easily leverage stored procedures to increase performance. Yes, there are risks such as an ignorant programmer unintentionally doing multiple full table scans; however, it is unlikely that a programmer who can not be trusted with L2E could be also be trusted to remember to use the count(*) aggregation in SQL.

However, if your database schema is not so simple, you might run into issues with Linq to Entities. If your database has self referencing tables, is denormalized, very complex, or just generally misshapen from consultant raiders, L2E may not be worth the hassle. There is nothing wrong with straight up SQL, it has always worked, and it still does. In the hands of an experienced developer, by-passing Linq to Entities in favor regular SQL and Ado.net can give you access to some very powerful optimizations without sacrificing a robust code base. Although, stored procedures can also be used with L2E to increase performance, this sometimes adds business logic into the database.

In software architecture and patterns, there is no always best solution. Patterns need to be applied on an as needed basis by someone who actually understands the benefits and drawbacks of a given pattern. Linq to Entities is the same way; it has many benefits and drawbacks and therefore needs to be used as needed.

Software Engineer Job Titles (as I see them)

Everyone knows titles are not a big deal, at least when you are a measly software developer. However, the following is what I personally expect from different levels of developers, engineers, programmers, or what ever you call coders at your place of employ:

Intern/Entry (0) - Is analytically minded, but is still struggling with the basics of syntax, ect.

Junior Developer (1) - Has mostly mastered language syntax and constructs, but still needs a lot of guidance to effectively leverage his tools to create a usable piece of software that can be reasonably maintained.

[Mid] Developer (2) - Can work on assigned tasks with minimal guidance only occasionally needing to seek help. May still struggle with translating high level requirements into code. He can be unable to see patterns in a high level in the application, or see them when they are not there. May not be able to deal with ambiguity.

Senior Developer (3) - Able to develop and deploy most applications from to start to finish with no guidance. She has the ability to translate requirements and user feedback into actionable plans. Must also possess the ability to help delegate work. Can deal with ambiguity and make plans to work around it. May have some trouble distinguishing between different design patterns and applying them appropriately.

Okay, some pedants may say the next one clashes with a senior developer, may not be generally used, or claim that software architecture is it's own distinguishable field; but if I don't list it a mid-level developer will not be in the middle of the list!

Architect (4) - Has mastered his area of technology and can immediately spot the causes of obscure errors. Is an expert at translating requirements in to software, and can often understand user feedback even if the verbal feedback contradicts their true intentions or goals. Can head off issues before they become problems. Has very good working knowledge of design patterns and when to they are appropriate. Able to understand how to make larges gains in application performance. Experience is broad enough to know if a language/framework is not appropriate for the problem at hand and seek the necessary expertise. Might be able to write a book in their area of expertise.

How to render a select box with Zend Framework forms.

I was using Zend Framework 2 to make a quick form when I needed to render a quick select box for my user to select a month. I never thought I would be writing a blog post about something PHP related or something as simple as creating a dropdown so that a user could select a month; however, I ran into so much trouble doing so I think it is necessary for me to post my solution for posterity.

I was seriously scouring Google for over a hour; find a proposed solution, test, fail, repeat. The Zend documentation was fairly useless as per usual, so I was left searching random blog entries. Every time I came across something that looked promising I'd see something in the comments resembling the bellow remarks:
READER: This codez doesn't work dude!
AUTHOR: It totes does, you just got to download my custom library add-on first!

Anyway, my luck changed when I stumbled across this blog, it was the first one that had a solution that worked out of the box. However, his method for creating the element differed from the one I had used in the rest of my form. In a sane world this would not have mattered, but, in the real world this happened to make the select box look very different from the rest of the elements in my form. This still gave me a good jumping off point for this solution:

$this->addElement('select', 'Month', array(
      'label' => 'Month',
      'required' => true,
      'multiOptions' => $this->getMonths() ));

Just add an option key called 'multiOptions' and assign it an array where the key is the html value and the value is the html displayed text. Happy coding!

MySqlDataReader reading tinyint (byte) as bool

Regrettably, work has forced me to work with MySql as I have been working in a LAMP enviorment instead of my beloved .net. However, if I make a utility I go right back to C#.

While making a little utillity that interface with MySql I used the MySQL Connector Net 6.1.6 library and the included MySqlDataReader. It has a very strange behavior where it thinks tinyints are bool. It took me about a day to track this down.

reader.ReadByte to the rescue.