Shortcuts en Visualstudio para TestDriven.NET

Un simple recordatorio:

Ngrok en Windows

Ngrok es una magnífica herramienta que nos permite publicar servicios que están alojados en nuestra máquina detrás de un firewall. Muy útil, para depurar servicios o aplicaciones web, que interactúen con otros servicios.

En mi caso lo uso para publicar aplicaciones web en IISExpress mientras desarrollo. Para ellos tenenmos que hacer los siguientes pasos.
1) Lo primero averiguar el puerto que está usando nuestra aplicación. Lo podemos ver desde IISExpress. Por ejemplo: 51234. Y decidir un dominio para ngrok, en nuestro caso example.ngrok.com
2) Permitimos conexiones externas en nuestro firewall a ese puerto:

netsh http add urlacl url=http://example.ngrok.com:51234/ user=todos

3) En el archivo: \Users\Usuario\Documents\IISExpress\config\applicationhost.config Añadir un nuevo binding para permitir conexiones externas, a nuestra aplicación buscando por su nombre.

<binding protocol="http" bindingInformation="*:51234:example.ngrok.com" />

4) Una vez hecho esto sólo tenemos que ejecutar ngrok

ngrok -authtoken TU_TOKEN -subdomain=example 51234

Y en consola veremos:
Fowarding http://example.ngrok.com -> 127.0.0.1:51234

Para acabar indicaremos como abrir varios puertos. Para esto hay que modificar el fichero:
\Users\Usuario\.ngrok Con una configuración parecida a esta:

auth_token: TU_TOKEN
tunnels:
  example:
   proto:
    http: 51234
  exmaple2:
   proto:
    http: 51235

Muy importante poner espacios, en lugar de tabuladores. Así en consola veremos:
Fowarding http://example.ngrok.com -> 127.0.0.1:51234
Fowarding http://example2.ngrok.com -> 127.0.0.1:51235

ASP.NET WebPages Optimizar el uso de strings

Interesante optimización del equipo de WebPages para mejorar como se renderizan las páginas.

Instead of creating a string from the StringWriter (_tempWriter) we will copy the underlying buffer in chunks to the output text buffer. For large pages this both reduces the total allocations to 1KB as well as avoid getting into the large object heap.

Este es un problema común en código manejado cuando se usan cadenas.

F# para desarrolladores de C#

He estado viendo esta presentación: F# for C# developers de Øredev, que podría llamarse como agilizar las pruebas con F#. Ya que propone usar F# para facilitar las pruebas en aplicaciones que podrían estar desarrolladas en c#.

Aquí se puede ver como se define una clase:

Aquí como usar Nunit para hacer una prueba unitaria:

Sobre el min 30:39, podemos ver como hacer pruebas primero usando Fsunit y después unquote:

Así mismo mostró como hacer BDD.

Y por último como realizar Mocks:

Nuevo lenguaje desde Microsoft

Aunque todavía no tiene nombre estoy totalmente entusiasmado con lo que se está rumoreando del nuevo lenguaje: M#. Intentaré recopilar enlaces sobreo lo que vaya apareciendo.

• C# for Systems Programming. Su presentación en sociedad. Me quedo con que no es interpretado y podría ser compatible con c#.
• Error model.

Programación funcional

Cierto que los lenguajes imperativos como C# están incluyendo aspectos de los funcionales, en este caso mediante lambdas y Linq. Y muchas son las opiniones a favor de este cambio de mentalidad, como por ejemplo, esta proclamando la muerte del IF.

También es muy recomendable esta serie: Refactoring to functional:

I’ve been thinking. They teach us that we need to think in terms of objects and identify these with nouns among other techniques. We then need to make sure that we name them correctly, that they’re small, that they only have a single responsibility and that they can’t have too many dependencies injected into them. And now they’re telling us that we should try and not maintain state because it’s bad for concurrency. I’m beginning to wonder, why the hell have classes at all?

Por último también incluir este punto de vista muy acertado, de la complejidad de tratar la concurrencia con lenguajes imperativos.

Pruebas unitarias y Dependency injection

No soy un “abusón” de las pruebas unitarias pero no puedo estar más de acuerdo con lo que dice:

Unit tests don’t uncover all design problems, but they are effective with respect to cohesion and coupling issues and the rather significant principals that relate to these.

…

I’m no fan of the ceremony surrounding Inversion of Control and the impact some of the most popular types, like Dependency Injection, has on production code. But, having never learned the cost of low cohesion and tight coupling from unit testing, dynamic programmers often violate sound design.

via.

Recomendación para nueva app web

One of my favorite business model suggestions for [web] entrepreneurs is to find an old UNIX command that hasn’t yet been implemented on the web, and fix that.

via.

QueryString Helper

Muy a menudo tengo que consultar los valores de las QueryStrings, y la verdad es que es horrible el montón de comprobaciones que hay que hacer. Además muchas veces, wap proxies o adsevers incluyen caracteres en la querystring, haciendo que los parsers lancen excepciones.

public static class Extensions
{
private static readonly Regex LeadingInteger = new Regex(@"^(-?\d+)");

public static T Get<T>(this System.Collections.Specialized.NameValueCollection nvc, string key)
where T : IConvertible
{
T obj = default(T);

if (nvc == null || string.IsNullOrEmpty(nvc[key]))
return default(T);

string v = nvc[key];

if (typeof(T) == typeof(Guid))
v = v.Substring(0, 36);

if (typeof(T) == typeof(int))
{   //http://stackoverflow.com/a/975512/22055
Match match = LeadingInteger.Match(v);
if (!match.Success)
v = match.Value;
else
return default(T);
}

try
{
obj = (T)Convert.ChangeType(v, typeof(T));
}
catch { }
return obj;
}
}

A veces, echo de menos las facilidades de lenguajes dinámicos como JS, por ejemplo, en el parseInt

Sólo hay dos cosas complejas en computación

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton

37signals. fowler.

Update: Desde luego que esta es la semana de esta cita, está por todos lados. En realación a esto, encontramos este artículo de Haidi Hariri, que aunque no la menciona podría aparecer. En él recomienda no usar las siguientes palabras: Util, Service, Helper, Manager; algo muy fácil de decir pero bastante dificil de alcanzar.

Al hilo, también encontramos este artículo en reddit, interesante ya que es difícil encontrar sobre esta temática. Aunque yo diría que siempre los nombres son importantes, sobre todo si tienes una memoria como la mía. Así que:

Always code as if the person who will maintain your code is a maniac serial killer that knows where you live

Por último, creo que tener en mente el concepto de Business Primitives, es algo que ayuda en el naming.