Any CSS class selector can have ID specificity

This will be a very short blog post. It's actually a life-saving hack that allows you to define a CSS class selector that has an ID specificity. You will know where it comes handy when you'll face such problem.

We were having a situation of our Angular app running inside a container and outer styles were interfering with our app styles. We already prefix all of our selectors by the container's CSS class name, but sometimes that's just not enough. And since scoped CSS isn't a thing any more, and we didn't want to refactor our app to have an ID container as there may be multiple instances of the same app in different containers (ID must be unique even though browsers are very loose when it comes to this), we wanted to raise our selectors' specificity anyway.

Autogrow textarea Angular directive with vertically centered text

This post is about emulating input[text] with a textarea element to create a text wrapping input that adjusts its height to the amount of content it holds. A working example can be found on Plunker.

When was the last time you asked yourself about input[text] element's user experience and usability? Well in normal situation (that is likely 90% of the time) this element works great but in the remaining cases it may not be ideal. Whenever you need your users to enter long(er) one-liners input[text] may not be your best option as it can't wrap text so part of it outside element's boundaries is being hidden. If nothing else, it's distracting to users.

You mainly have two options here each with its ups and downs:

• textarea element - very similar to input[text] as it allows entering unformatted text that can wrap as many lines as its length requires; it has some styling problems though (I'll explain that in a bit) and also allows entering multiple lines of text which may be undesirable but easy to handle/prevent
• content editable div element - it can easily be styled to look exactly like input[text] and it also wraps long lines of text (normally) just like textarea; the main problem is controlling its behaviour to prevent text formatting in a cross browser way

Of the two options the first one seems simpler so let's implement it.

Angular ngRoute routing authorization with asychronous promises

AngularJS routing doesn't support route authorization out of the box and nor does its popular cousin ui-router even though the latter supports state change cancellation with later continuation (using $urlRouter.sync(); check documentation). But in non-trivial Angular SPAs this feature is regularly needed. So I went off implementing it.

Data binding a single shared view to different controllers using "ControllerType as instanceName" syntax

If you haven't already I strongly suggest you first read John Papa's AngularJS styleguide. It's a magnificent document of an evolving set of AngularJS development best practices. Among them there's also one that says to abolish $scope use and rather provide view model data as part of controller instance because view bindings become more contextual amid other reasons. To accomplish this you need to use the ControllerType as instanceName syntax. This is usually a blessing but sometimes it may seem to be a curse especially when you give controllers contextual instance names (i.e. UserController as user) instead of some common name (i.e. UserController as vm). This is especially useful if you're nesting controllers and don't want to access parent controllers using scope's $parent property.

Contextual instance naming plays along nicely until you introduce shared views. Now when you want to bind your shared view to a controller instance you don't really know its name. It can be any controller instance name that will be using this shared view. Now what?

Simplifying method parameter checking

Next version of C# that will be coming with Visual Studio (supposedly version 2014) will have a new operator called the null-propagating operator (?.) allowing us to write null conditional statement expressions. This will help us simplify our code tremendously by collapsing several lines of conditional blocks to a single statement. Combining it with null-coalescing operator makes it even more powerful as seen in this example: string username = GetUser()?.name ?? "anonymous"; Object will be null checked before trying to access its members so we'll avoid the infamous null reference exception. It will therefore automatically continue to null coalescing part of the statement. You can read more about it on this link.

Parameter null value checking code is something we frequently write at the beginning of method body to avoid null reference runtime exceptions. You know these if statements right at the beginning of your methods:

   1:  public string DoSomething(Model data)

   2:  {

   3:      if (data == null)

   4:      {

   5:          throw new ArgumentNullException("data");

   6:      }

   7:      

   8:      // actual processing

   9:  }

Even static code analysis tools complain if you don't do these checks and to be honest this is a very good practice to avoid many future bugs in your code. The problem isn't this code per se, but rather that we're writing these seemingly same lines over and over again. Many developers tried simplifying this process using different techniques but the one I'm going to show here is a bit different.

Mapping SQL stored procedures to C# class methods with matching strong type parameters using T4 template

Blog post provides T4 template that generated strong typed C# code which maps to SQL stored procedures. It doesn't actually call those SPs, but rather prepares SQL queries to call stored procedures with various parameters. These provided T4 template queries are NPoco/PetaPoco compatible, so if you use a different DAL lib (maybe even simple .net Sql client), you'll have to adjust methods to generate and return different results (with .net Sql client it will likely be SqlCommand instance).

NPoco/PetaPoco DAL libraries use strings to provide database optimised queries and these are prone to typing errors which we aren't able to catch during compile time but rather during runtime, when effects can be much more devastating. That's why it would be great if we could somehow avoid these magic string values and just used C# code with string types and not make a mistake. We can't really avoid magic strings when writing direct TSQL but if we write stored procedures, we can do something about it.

We could self-write those C# calls that use stored procedures internally but that would just mean we moved typing errors to those methods, so this is not really a solution. Enter code generation with T4 Visual Studio templates. A t4 template will help us automate the process of writing C# methods while also making sure we get compile time errors when we change particular stored procedure's signature (sp name, parameter count or their types). So let's do just that.

How I mitigated the impossible SELECT INTO on Windows Azure

I'm the kind of developer that likes things under control by writing some stuff myself and keeping it as optimized as possible. This is especially true for database scripts. Sure we have these ORM tools these days (Entity Framework, NHibernate and such) but the calls that end up on the database side are many times unoptimized. Why? They have to work for all cases so sacrifices are made and performance usually suffers. That's why I like micro ORMs that make it super simple to translate database data to code (via object mapers) but still let you write optimized queries suited completely to your database.

The way that I upgrade my database requires me to backup existing data, drop the whole model, recreate it and restore data back to appropriate tables. Especially the backup strategy is problematic as it uses select into statements. Windows Azure requires all tables to have clustered indices prior to inserting data which makes it impossible to use select into statement as it has no control over clustered indices. How can we then automate backup scripts without creating those backup tables manually? With a bit of work, everything can be done.

Web Essentials markdown preview default style for Visual Studio

The other day I wanted to write a markdown file that's part of my Visual Studio 2013 project. As majority of you have done I've also installed Web Essentials addon for Visual Studio 2013. Beside the several syntaxes it supports one of them is also markdown. The problem I was facing was that its preview window had a really basic browser style. I wanted to change that.

Parametrized code testing and code exploration

Few days ago I had the pleasure of presenting parametrized unit testing among other things to a group of developers as part of my consulting side of work. I'm sure everyone got something useful out of those few hours we spent together.

So I thought of writing an introduction blog post to parametrized unit tests using NUnit library. But to give it some edge let me do this along with code exploration that makes our tests (and consequently our production code) better. I'll be using Code Digger Visual Studio 2012 extension. Hopefully you'll learn something new as well.

LESS gradient mixin with fallback for IE

As you could read in my last post (long time ago) I've rather used SCSS over LESS but when I upgraded my Visual Studio to version 2012 I decided not to install Mindscape's addin as VS already comes with support for LESS, CoffeeScript and TypeScript via Web Essentials addin. So I started writing my usual set of mixins in LESS. It seemed simple and straight forward at first until I started writing .gradient mixin that should somewhat also support older non-CSS3 browsers like outdated IE8.

Gradient mixin requirements

CSS3 gradient support is great but when creating a public facing webapp I usually want to support old(er) browsers so they'd display something in place of those nifty looking gradients. I opt for a flat background colour that is a mix between first and last gradient colour. But that's not all. Here are my gradient mixin requirements:

1. support CSS3 gradients using background-image style property
2. support prefixed variations i.e. -webkit
3. graceful degradation for older non-CSS3 browsers by providing a flat colour calculated from first and last gradient definition colour as vast majority of gradients are two coloured
4. provide mixin parameters in the same way as we provide them for actual CSS so without resorting to escaped ~"..." LESS notation
5. all fallbacks for flat colours have to be automatically calculated by the mixin instead of providing it manually