Selfelected

Compile aspnet mvc views (*.cshtml)

To make a long story short one can compile the views in asp net mvc.

It takes considerable time though so I only activate it for release compilations.

Update the build file with

1
<MvcBuildViews Condition=" '$(Configuration)' == 'Release' ">true</MvcBuildViews>

Like so:

1
2
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>

<MvcBuildViews Condition=" '$(Configuration)' == 'Release' ">true</MvcBuildViews>

I am sorry about all &gt; and &lt; but I don’t have the time right now to make everything look pretty. Just replace &gt; with < and &lt; with > and your good to go.
Or follow the links below with the awesome formatting Stack overflow provides.

Honour those who should. Especially this answer that does the only-release trick.

Catch property, field and method name changes compile time in dotnet (RTTI)

When you want to populate a dropdown listbox with customers

class Customer{ int Id; string Name; ...}

and have to write

myDropdownListbox.DisplayMember = "Name";myDropdownListbox.DataMember = "Id";

or

myGridColumnCustomerName.DatatMeber = "Name";

you really get a sour taste in your mouth.

Having magic strings like above spread in your code is really bad since it always compiles but might fail runtime. This means more manual tests. Which in turns means a certain friction against renaming properties while refactoring.
I have been in way too many projects where one table has a field ItemNumber when it should have been ItemCount and where some fields are called Nr while another Number and these names are spread up in the layers to reach the presentation layer where they surface as magic strings like the examples above.

Luckily there is a solution in Dotnet 3 with LINQ. It isn’t the prettiest but it fails compile time when it should and that is considered a good thing.

( I won’t bother with explanation – just read the code. )

When you want to populate a dropdown listbox with customers

class Customer{ int Id; string Name; ...}

and have to write

myDropdownListbox.DisplayMember = "Name";myDropdownListbox.DataMember = "Id";

or

myGridColumnCustomerName.DatatMeber = "Name";

you really get a sour taste in your mouth.

Having magic strings like above spread in your code is really bad since it always compiles but might fail runtime. This means more manual tests. Which in turns means a certain friction against renaming properties while refactoring.
I have been in way too many projects where one table has a field ItemNumber when it should have been ItemCount and where some fields are called Nr while another Number and these names are spread up in the layers to reach the presentation layer where they surface as magic strings like the examples above.

Luckily there is a solution in Dotnet 3 with LINQ. It isn’t the prettiest but it fails compile time when it should and that is considered a good thing.

( I won’t bother with explanation – just read the code. )

// The Code.

< 

    class ReflectionUtility
    {

        public static string GetPropertyName<T, TReturn>(Expression<Func<T, TReturn>> expression)
        {
            MemberExpression body = (MemberExpression)expression.Body;
            return body.Member.Name;
        }

        public static string GetMethodName<T, TReturn>(Expression<Func<T, TReturn>> expression)
        {
            var body = expression.Body as UnaryExpression;
            var operand = body.Operand as MethodCallExpression;
            var argument = operand.Arguments[2] as ConstantExpression;
            var methodInfo = argument.Value as System.Reflection.MethodInfo;

            return methodInfo.Name;
        }

    }


    class MyClass
    {
        public int MyField;
        public int MyPublicProperty { get; set; }
        public  string MyReadonlyProperty { get { return string.Empty; } }
        public int MyMethod() { return 0; }

        private MyClass() { }   // To make sure the class doesn't need a default constructor.
    }


    class Program
    {
        static void Main(string[] args)
        {
            string fieldName = ReflectionUtility.GetPropertyName((MyClass x) => x.MyField);
            Console.WriteLine(string.Format("MyClass.MyField:{0}", fieldName));
            Debug.Assert("MyField" == fieldName);

            string propertyName = ReflectionUtility.GetPropertyName((MyClass x) => x.MyPublicProperty);
            Console.WriteLine(string.Format("MyClass.MyPublicProperty:{0}", propertyName));
            Debug.Assert("MyPublicProperty" == propertyName);

            propertyName = ReflectionUtility.GetPropertyName((MyClass x) => x.MyReadonlyProperty);
            Console.WriteLine(string.Format("MyClass.MyReadonlyProperty :{0}", propertyName));
            Debug.Assert("MyReadonlyProperty" == propertyName);

            string methodName = ReflectionUtility.GetMethodName<MyClass, Func<int>>((MyClass x) => x.MyMethod);
            Console.Write(string.Format("MyClass.MyMethod:{0}", methodName));
            Debug.Assert("MyMethod" == methodName);

            Console.Write(Environment.NewLine + "Press any key.");
            Console.ReadKey();
        }

< }

Honor those who should.  (This link contains a comment regarding generic methods that I’d like to impolement in CompulsoryCat.)

Update: When copy-pasting through manoli.net some angle brackets got dropped. This is, hopefully, fixed now.  Otherwise – get the source here: http://selfelected.pastebin.com/f77563a02

Update:

Check out Compulsorycat.  It is my F/OSS library with some of these functions.

Honor those who should.  (This link contains a comment regarding generic methods that I’d like to impolement in CompulsoryCat.)

Update: When copy-pasting through manoli.net some angle brackets got dropped. This is, hopefully, fixed now.  Otherwise – get the source here: http://selfelected.pastebin.com/f77563a02

Update:

Check out Compulsorycat.  It is my F/OSS library with some of these functions.

Defensive programming and Fail at once

There is something called defensive programming http://en.wikipedia.org/wiki/Defensive_programming that is supposedly something good. I believe so too but it might have a way of hiding bugs.

In defensive programming you recieve data and inspect it for flaws. When it is possible you manipulate the data so it is correct and usable again. This is good so as much your code works.

But when you are in a project where your code is just a cog in a bigger machinery this approach is not necessarily the best; by recieving and hiding flawed data a bug somewhere else is hidden.

In the example in Wikipedia a string limited to 1000 characters is manipulated. The suggested solution is to truncate the string and keep rowing as if there wasn’t a leak in the first place. Depending on the circumstances the bug might be at the caller and by removing the very bug instead of the symptoms the very problem disappears.

According to Fail at once an error should surface as soon and close to the source as possible. The chances for data resulting of the bug to propagate, is then smaller and the bug tracking is probably faster.

In the example it would have been better to throw an exception than to just keep on with data, now faulty in another way than to start with.

Or like this: if a user writes an essay of 2000 characters he probably wants to know that it cannot be saved the very moment ctrl-S is pressed instead of 2 days later when proof reading, when the last 1000 characters are gone both from mind and binary space. Or an operator of a tube bending machine prefers to know if his machine is faulty when he is working at it instead of two weeks later when the tubes are buried inside a wall somewhere.

About 4 years after I wrote the above I found that at least one more has the same opinion (pdf); someone way more known than I.

Fail at once – an explanation

I have written 2 articles tagged as Fail at once without explaining what the filosophy behind the name is. Shame on me.

It is an old truth that the earlier a bug is found the cheaper it is to fix.
Automated tests tests things that can go wrong; but what if those things couldn’t even go wrong in the first place?

Code that won’t compile won’t make it into production. Ever.
It is cheapest to not write any errors at all.

Today Fail at once does two things: It stops compiling when it notices something is wrong and at all other times it tries to help the programmer do the right thing.
Typical example of the first is to always use type safe variables and the latter to name things in such a way that there is one very natural way to write the code. By using this explicitly and intelligently you get a leverage for writing better code faster.

Make sure your objects are fully populated – Fail At Once

The default constructor
public Customer()
{
}
is seldom needed while working with business objects. Honestly – how do you need an object that is not fully populated? Do you have a Customer or do you not? A few situations comes to mind where an almost-Customer is needed but they all smell of refactoring, i.e. base class, sub class and two constructors.

To make sure I don’t have an object that is not fully populated I make sure the default constructor is not reachable. Either through creating other constructors or by making it private the times it is needed internally. Instead I create a constructor that takes all necessary parameters to fully populate itself. If there are variants I create more constructors. I am not afraid of writing code but I strongly dislike putting bugs into production. Hence Fail At Once.

Sometimes it is handy to have a “Set” method taking all parameters and calling it from the constructor but this is just a variant of the pattern above that objects that are not correctly populated are very seldom useful.

If you don’t like writing “normal” constructors them make them static and call them Create or something obvious.

Another advantage with this routine is when adding (or removing)  mandatory fields. Then there is one and only one place to update to make the compiler show you all places to update.

I have noticed that it is hard to make lists in the GUI without having a default constructor but this, I presume, is just the exception that confirms the rule.

Bugs that can’t compile will not go into production.

Do not type cast – Fail At Once

Avoid casting types.

Why do I write about this? What has it do do with quality and projects and architecture? Well… each thing that cannot break doesn’t have to be tested and… cannot break. Less testing, less coding, less bugs.

When working with class libraries that are dependant on the generic type one cannot avoid type casting fully. The solution then is to encapsulate and wrap the cast through inheritance or composition.

If you wrap your type cast you have 1 test case instead of a test case per call.

What about datagrids and combo boxes that have an internal Rows or Items collection or Tag attribute? How can they become type safe without having to rewrite the whole control? Unfortunately I don’t have a perfect solution but as I have seen the evil in type casts I avoid them and instead of writing test cases and tests I spend some time looking for a type safe alternative. These are typically called row.OrderTag or combobox.CustomerItems. Overriding the method or attribute is not possible since one cannot change type; but one can override and set the [Obsolete] attribute to at least get a warning. Pepper this with a Debug.Fail( ”Please use the OrderTag property instead.” ) and things will stop in any test case that runs it. Many times one can even set the compiler to fail with [Obsolete(true)] to be totally sure the call is never made.

Another problem then is when two different types really are returned. Well… write two methods then. Even overload them; as long as the compiler understands your goal.

Final thought: How should one get this type of thinking into the spine of a project? It is not something that can be ordered but has to be understood and taken to heart by the involved. If someone has an idea please drop me a line; but until then being a good example is a good beginning.

Fail At Once

What if you didn’t have to test your application?

What if you worked together with tools to make sure some bugs never even left the compiler? That would be less to test; faster development cycle and more stable code.

In search of better name I call this Fail At Once.

I will get back on the subject.

Update: I have not gotten back as much as I wanted.

Unit testing – can be too much

I like unit tests, I really do. But I have also come to realize that many tests don’t have to be done.

One can for instance code according to Fail At Once to make the compiler do the tests.
Or one can autogenerate code and hence only have to unit test a fraction of the resulting code.
Or one can do integration tests and take for granted that if the integration works the unit tests work too.

I have tried all three and believe in laziness – to get more done while working less. So I say that a thought out mix of all three above supposedly is the right way.

Patrik Löwendahl thinks approximately the same.

Fail At Once

This message will be repeated in english further down.

Hur får man rättningar och funktionalitet så fort som möjligt genom dörren?
Hur får man så få buggar som möjligt i produktion?

Jag fick en gång kommentaren från en vän “Men du levererar väl aldrig otestad kod?”. Det var en komplimang och en kommentar till att jag just då satt i ett projekt som skulle leverera den högsta kvaliteten jag levererat hittills, dessutom rakt ut i fabrik
Mitt svar förvånade honom “Jag testar inte.” Jag lät honom hämta andan. “Rättning: jag testar så lite som möjligt och mycket kod går rakt ut i produktion otestad.”

Sedan följde en förklaring. En förklaring jag har dragit för alla i projektet:

“Använd kompilatorn för att fånga fel.”

Vanligtvis när man talar om system med hög kvalitet pratar man om testning. Massor med manuella tester med speciella konsulter man hyr in som är specialiserade på test. Dyrt. Men det blir dyrt med hög kvalitet.
Bullshit.

Manuella tester är dyrt och tar lång tid.

Modernare utveckling innehåller enhetstester.

Jag förespråkar Fail At Once för att slippa många enhetstester och manuella dito.

Det är viktigt att fånga fel så fort som möjligt. De allra bästa är att inte skriva dem alls.
Där är jag inte ännu.

How do you ship patches and functionality as fast as possible?
How do you get as few bugs as possible in production?

I once got a comment from a friend “But you never deliver untested code?” It was meant as a compliment and comment to my job then; I was working in a project that was delivering the highest quality I have ever delivered; right onto factory floor.
My answer surprised him “I don’t test.” I let him catch his breath. “Correction: I test as little as possible and as much code as possible goes into production untested.”

I had to explain, the same explanation everyone in the project had heard.

“Use the compiler to catch errors.”

Normally when one talks about high quality system one also mentions testing. Lots of manual tests with consultants specialised on testing. Expensive. But high quality is expensive.
Bullshit.

Manual tests are expensive and take lots of time.

The more modern unit testing is cheaper.

I recommend Fail At Once to get rid of many unit tests and manual ditto.

It is important to catch errors as fast as possible. The best is to not write them at all.
I am not there yet.