Google analytics script

Latest jQuery CDN with code tiggling.

Friday, 22 January 2016

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 editablediv 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

Friday, 9 October 2015

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.

Friday, 30 January 2015

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?

Wednesday, 27 August 2014

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: publicstring DoSomething(Model data)

2: {

3: if (data == null)

4: {

5: thrownew 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.

Wednesday, 23 April 2014

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.

Thursday, 3 April 2014

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.

Tuesday, 7 January 2014

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.

Friday, 18 October 2013

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.

Saturday, 30 March 2013

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:

support CSS3 gradients using background-image style property

support prefixed variations i.e. -webkit

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

provide mixin parameters in the same way as we provide them for actual CSS so without resorting to escaped ~"..." LESS notation

all fallbacks for flat colours have to be automatically calculated by the mixin instead of providing it manually

Actually it's about the extended CSS syntax that we get by writing SCSS stylesheets (similar to LESS, but more on it later on). SCSS used to be called SASS with its own syntax but now uses CSS syntax hence changed its name. I will be using SCSS acronym from now on because that's what my following code example uses. If you've ever used any of these two you'll know the benefits of simplified, easier to handle and more powerful style sheets. I have been flirting with this couple for some time now, but on this last project of mine, my flirting became a serious relationship. I started using SCSS. What I will share with you here are a few common mixins that are usable to any web developer.