jehugaleahsa

private static T getValue<T>(object source, IFormatProvider provider)
{
    Type type = Nullable.GetUnderlyingType(typeof(T)) ?? typeof(T);
    if (source == null)
    {
        if (typeof(T).IsValueType && typeof(T) == type)
        {
            throw new InvalidCastException();
        }
        return default(T);

jehugaleahsa

  private def foldLeftBad[T, TResult](list: List[T], initial: TResult)(folder: (TResult, T) => TResult): TResult = list match {
    case Nil => initial
    case head :: tail => folder(foldLeftBad(tail, initial)(folder), head)
  }

  private def foldLeft[T, TResult](list: List[T], initial: TResult)(folder: (TResult, T) => TResult): TResult = {
    
    @tailrec
    def foldLeftSoFar(list: List[T], computer: () => TResult): TResult = list match {
      case Nil => computer()

jehugaleahsa

Unit Test Scenario Builder Pattern

Reusing test fixtures without hiding what’s being tested

Unit testing is hard…

Only in the most basic situations is unit testing actually “easy”. The only code that’s easy to test involve functions that simply take input and calculate a result. These types of test fall into the classic testing paradigm of calling a function and running some assertions. The problem is that most code interacts with other components, which makes it extremely difficult to test functionality in isolation. Remember, testing code in isolation is what makes it a unit test.

The only option available in type-safe languages is to replace dependencies with fakes (stubs, mocks, etc.) at runtime. This requires the dependency to be an interface or an abstract class in C#. On the flip side, in dynamic languages such as JavaScript, Python or Ruby, you can do monkey patching to replace an object’s members (including its methods) at runtime ([http://en.wikipedia.org/wiki/Monkey_patch]). This allows

jehugaleahsa

foreach (int i in items)
{
	Console.Out.WriteLine(i);
}

IEnumerator enumerator = ((IEnumerable)items).GetEnumerator();
try
{
	int i;
	while (enumerator.MoveNext())

jehugaleahsa

application.factory('navigator', ['$http', '$window', 'baseUrl', function ($http, $window, baseUrl) {

    function enrich(urlTemplate) {
        if (!urlTemplate) {
            return null;
        }

        var template = earl(urlTemplate);

        var resource = {

jehugaleahsa

using System;
using System.Collections.Generic;
using System.Linq;
using System.Linq.Expressions;
using System.Reflection;

namespace DataModeling
{
    public class QueryOrderer<TEntity>
        where TEntity : class

jehugaleahsa

var di = (function () {	

	if (!Array.isArray) {
	  Array.isArray = function(arg) {
		return Object.prototype.toString.call(arg) === '[object Array]';
	  };
	}

	function getContainer() {
		var container = function () { 

jehugaleahsa

            // page: the currently selected page (1 <= page <= pageCount)
            // pageCount: the total number of pages (1 <= pageCount)
            // pagesToDisplay: the number of pages displayed at a time (1 <= pagesToDisplay)
            function paginate(page, pageCount, pagesToDisplay) {
                var buffer = Math.floor(pagesToDisplay / 2);
                return { 
                    start: Math.max(1, Math.min(page - buffer, pageCount - pagesToDisplay)), 
                    stop: Math.min(pageCount, Math.max(page + buffer, pagesToDisplay))
                    };
            }

jehugaleahsa

    public abstract class ObservableModel<TModel> : INotifyPropertyChanged
        where TModel : ObservableModel<TModel>
    {
        private readonly Dictionary<PropertyInfo, object> lookup;

        protected ObservableModel()
        {
            this.lookup = new Dictionary<PropertyInfo, object>();
        }

jehugaleahsa

As familiar as I am with OOP and design patterns, I rarely see myself coding in an object-oriented fashion. I make heavy use of the strategy pattern to swap out implementations based on configuration settings, but that's about it. Like most OOP enthusiasts, at one time I used patterns pretty heavily. Some composite pattern here, decorator there -- sprinkle in a little bridge pattern for taste. With a gradual introduction to TDD and functional programming, that's slowly faded away over the years.

In 2012, it dawned on me how freaking awesome functional programming is. With a few tricks here and there, you can almost completely eliminate the need for stateful classes. Instead, classes just get passed their dependencies via dependency injection (DI). Any other information is passed via method parameters. Closures and other functional hacks handled those edge cases where there seemed to be a need for state. This style of programming is especially effective when you start working with RESTful APIs or heavily thre