Quick Tip: Enum Descriptions / Labels

If you ever had an enumerable list but wanted to include 'friendly names' with the list, this is how you can do it using Extension methods.

Create an extension Method
public static string Description(this Enum enumValue)

{
var enumType = enumValue.GetType();
var field = enumType.GetField(enumValue.ToString());
var attributes = field.GetCustomAttributes(typeof(DescriptionAttribute), false);
return attributes.Length == 0 ? enumValue.ToString() : ((DescriptionAttribute)attributes[0]).Description;
}
 
Define an Enum
public enum AnEnum
{
[Description("First")]Val1,
[Description("Second")]Val2
}
 
Use the enum
var displayName = AnEnum.Val1.Description();

Quick Tip: C# Strongly Typed Property Name

A quick and easy way to use a type safe (compiler-aware) lambda expresssion

public string GetPropertyName<TSource, TResult>(Expression<Func<TSource, TResult>> propertyExpression)

{

var memberExpression = propertyExpression.Body as MemberExpression;

return memberExpression != null ? memberExpression.Member.Name : null;

}



Then call

GetPropertyName<LocalGovernment, string>(x => x.LocalGovernmentName)





Originally found here:
http://stackoverflow.com/questions/1417383/how-to-get-properties-names-from-object-parameter

Developer Collaboration / Knowledge Sharing

As a consultant for a large company you are often segregated from your peers, often by physical location, for what can be extended periods of time.

For me this poses a very important problem, and that is the sharing of knowledge within the company. When a developer goes out to a client, they can build a vast range of knowledge that is never then shared back to the broader development team. Sometimes even knowledge within a team at a client site is not shared effectively, leading to a lack of growth within the team, and lack of understanding and standardisation within the delivered products.

Formal training can be used to bring everyone to a certain level of knowledge, but training rarely imparts the knowledge of best practice or the results of experience.
Developer-led workshops are often better at imparting specialised knowledge but they are dependent on attendence, prerequisite knowledge and can suffer from a lack of follow-up material. It can also require significant time investment on the team, where physical segregation and time management has significant issues.
Wiki's and blogs can provide as much information as developer-led workshops, but suffer from lack of accessibility and relevance, and the lack of immediacy of queries and responses, so while it is a useful way to store information, it is not always useful for sharing information.

For me, the above scenarios seem to be the most commonly used way to share information, and do help to at least some degree. However it is also lacking in so many ways to really bridge the gap of knowledge within a large group of developers.

I think the popularity of social media shows how easy it can be to share information between peers if it is easy to share, and easy to search. Stack Overflow is an outstanding example, where the community is answering the questions of other developers and in the process sharing their own knowledge and experience. I would like to see something that is almost the opposite of this as well, where developers can share snippets of code that they have used to solve a particular issue, or that can be extremely useful in a variety of situations. CodeProject is a bit like this, but the 'gamification' and 'accessiblity' of stack overflow makes it a significantly more relevant tool.

So for those of you working in the industry, how do you ensure everyone has access to the knowledge and experience of your most effective developers.

Incomplete HTML5 is Incomplete

Or why HTML5 is not close to being ready for LOB.

I have always given JavaScript a bit of a bad rap, and to be honest a lot of it comes down to not being as proficient with it as I am at my meat and potatoes c# development. That and the lack of toolset support to rival C# development in Visual Studio.

However I have been using it more recently, both in my at work projects and personal projects. This is largely due to my pushing the adoption of ASP.NET MVC at work, which is really helping leverage Javascript rather than the kludges and hacks of the old WebForms way.

While we are currently still targetting HTML4 for our LOB systems, I have been working on various HTML5 personal projects to get a feel for how we can leverage the new features of HTML5 going forward. And it is not as pretty as I had been led to believe.

By "HTML5" I mean the buzzword that it entails, so in reality HTML5, CSS3, JavaScript etc, it is just easier to go with HTML5. And in fact the Actual issue I want to raise here is with the HTML5 specification. While most of the buzz about HTML5 is about fancy CSS3 animations, gradients, or html canvas and media tags, when it comes to LOB data/forms is king.

HTML5 Forms
So HTML5 has a large number of new fieds (email, tel, number, etc) and utilities (autofocus, placeholder). These range from very useful (autofocus, placeholder, range) to simply handy (with validation being pretty standard now, fields for email, telephone, etc are fairly uninspiring).

However trying to get these working consistently across browser version is an excercise in futility for the conceivable future.

For example, I attempted to have a page with a Range element, which is unsupported in most browsers at this stage. OK, I'll use a JQuery Range control then, which worked fine. Except that I was using the same scripting (KnockoutJS) to bind to my form for a JQuery Mobile targeted page too, which requires the use of the HTML5 range element. There was no way I could provide a solution that would work without a fully separate page renderer and script, or a bunch of browser/compatibility checks. I actually needed 3 different browsers to do the testing, a Local IE, Firefox (with User Agent Switching to iOS) and my Android device (which led to further issues of having to host in IIS instead of the Visual Studio IIS Express to allow for external access).

Isn't HTML5 supposed to be the great consolidator?

HTML5 Data
Local Data has even been removed from the HTML5 specification, so while basic 'DOM Storage' is available (basic key-value store) in prettymuch all browsers, the much hyped "webdb" support is completely non-standard and generally browser specific, which in essence means you either write a library for each browser, or you don't use it.


The final word
In even just a basic usage scenario I came across a severe lack of cross-compatibility issues when attemtping to build an HTML5 application that can work across browsers and in the mobile space. Until HTML5 becomes standardised, or at least the features become supported in mainstream browsers at least to some level of consistency, HTML5 is not going to be the be-all and end-all for LOB solutions.

If you have to rewrite your UI and scripts for each browser / mobile platform, then HTML5 offers little compelling benefit over current methods where you implement rich web technologies via Silverlight using vastly superior (YMMV) tools and service the mobile space with custom/expensive native apps, or basic html interfaces.

This is a little bit exaggerated, but it is at least a small counter to the 'silverlight is dead' brigade. I am currently very happy developing well designed MVC4 applications over Silverlight at the moment however, I just think the 'HTML5 will save us all' attitude is a little premature in the LOB space when it is still so hard to get something simple done consistently in HTML5.