[System.Security.SecureString]$secureStringValue = Read-Host "Enter the service account password: " -AsSecureString;
[String]$stringValue = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($secureStringValue));
Thanks to this blog!
using System.Collections.Generic;
namespace LeftJoin
{
using System;
using System.Linq;
class Program
{
static void Main(string[] args)
{
var johnny = new Person("Johnny");
var david = new Person("David");
var michael = new Person("Michael");
var owners = new List<Person> { johnny, david, michael };
var pets = new List<Pet> { new Pet("Flocky", johnny), new Pet("Choo choo", david)};
var noPets = (from owner in owners
join p in pets on owner equals p.Owner into joinedGroup
from joined in joinedGroup.DefaultIfEmpty()
select new { owner, joined }).Where(match => match.joined == null).Select(arg => arg.owner);
foreach (var person in noPets)
{
Console.WriteLine(person);
}
}
}
internal class Person
{
public Person(string name)
{
this.Name = name;
}
public string Name { get; set; }
public override string ToString()
{
return Name;
}
}
internal class Pet
{
private readonly string name;
private readonly Person owner;
public Pet(string name, Person owner)
{
this.name = name;
this.owner = owner;
}
public string Name
{
get
{
return this.name;
}
}
public Person Owner
{
get
{
return this.owner;
}
}
public override string ToString()
{
return Name;
}
}
}
A ver qué tal chuta.
También quiero felicitar a Jesús Rodríguez Valencia ¡que ya tiene blog! La Cornucopia de .NET
Y último, aquí va la prueba de que estoy empezando con Clojure.
David Heinemeier Hansson (https://twitter.com/dhh):
Mixed feelings about him. Smart guy, wrong lane. Always in my opinion, of course.
He is a very representative developer that exposes the Anti-Microsoft syndrome. Let’s watch him talk in what I think it’s a flaunting of pride and empty self-satisfaction.
I’m not saying he’s a bad guy, but this gratuitous bash is completely unnecessary, unless he is just another hater. I’m feed up with presumptuous arguments like those.
¿Por qué nos empeñamos controlar archivos binarios con un repositorio orientado específicamente para fuentes?
Hasta un tonto como yo sabe que hacer esto es una salvajada que puede causar todo tipo de problemas. Los más graves:
En resumen: FRAGILIDAD
En mi experiencia personal trabajando con Visual Studio la solución es clara:
¡¡usa NuGet, COPÓN BENDITO!! Que hasta viene integrado en el propio IDE con ventanicas, consola, iconos negrillos y toda clase de comodidades.
«NU GET». Desde luego su nombre no es muy bonito y nos recuerda a cierto producto habitualmente de pollo rebozado.
¿Por qué cuesta tanto trabajo poner a punto un repositorio de binarios? Pero si es que hasta yo sé ponerlo, ¡incluso he creado paquetes de NuGet sin tener ni zorra!
A día de hoy todavía me encuentro gente que mira NuGet como si fuera una un invento de la abuela Tomasa que viene con Visual Studio de chiripa y que solamente utilizan esos punks que publican código en GitHub. Pues no, leches, es ni más ni menos que el gestor de paquetes OFICIAL de Microsoft para Visual Studio. Y si estás desarrollando en Visual Studio, cuya ventana principal ser un entorno de desarrollo integrado (de ahí que sea un IDE) sé por lo menos coherente y ¡úsalo! No esperes que te salgan cartelitos de neón o voces eróticas estilo Avast cuando añades una referencia a mano diciéndote que lo uses. Uno de los deberes de un desarrollador es conocer lo mejor posible sus herramientas.
Solamente se me ocurren 2 razones para no usar un repositorio de binarios:
a) por desconocimiento de las herramientas.
b) o por pasotismo, que es casi peor.
Así es que, ¿a qué estáis esperando? ¿a que os lo cuente un javero y os adelante por la derecha con Maven?
Ese listón bien alto, me kagunnn, ¡arriba .NET!
Los que me conocéis sabéis que soy un rabioso defensor de mis principios, lo cual no quiere decir que mis ideas estén escritas a fuego, dicho sea de paso.
Lo que me trae por aquí hoy es algo que me toca especialmente las narices: Los comentarios en el código.
Lo reconozco, al principio era un ávido comentador de código. Ponía todo bonito para que un posible lector lo tuviera todo desmenuzado «al detal» y no sufriera un derrame al ver mis (horribles) algoritmos de decodificación de bitmaps por la época en la que programaba en C++ con un compilador de Watcom y me lo pasaba teta haciendo scroll parallax en modo 13h y editores de mapas a base de tiles.
Vale, todo eso estuvo gracioso… para empezar. Uno se vuelve pragmático con los años, o por lo menos en algunos aspectos, y deja paulatinamente de chorrear comentarios por todos sitos. Finalmente, después de varios años te encuentras con un librete escrito por un tío canoso y que hace bastante que hizo la comunión: El Tío Bob, ¡el tío Bob Martin!
Lo que me llamó la atención fue que muchas de las cosas que decían era puras corroboraciones de mis sospechas. Una de las sospechas que ya intuía y que resulta más «revolucionaria» era la relacionada con los comentarios de código.
Decidí hacerle caso: ni un comentario de código. La máxima era que el código se «leyese», que tuviera una capacidad expresiva tal que hiciese innecesario añadir nada más.
¿Y adivináis qué? A día de hoy los comentarios en el código me echan para atrás casi tanto como un método de 5 parámetros. Me repugnan, me hacen daño, me queman las córneas, me producen una profunda repulsa, asco, depresión. Me dan ganas de coger una heavy machine gun del Metal Slug y reventar el código a balazos.
// This is a useful comment, I promise!
Mi reacción puede ser exagerada, sí, pero no sabéis lo que toca las pelotas el pu** StyleCop de los co**nes con la documentación. StyleCop puede ser una herramienta excelente o una pesadilla. En mi caso estoy al borde de pegarle fuego.
Y ahora bien, ¿cuál es el porqué mi posición? Aparte de lo expuesto en el párrafo anterior y de modo más general, estas son mis razones para eliminar todo vestigio de comentario en el código.
Son un lastre.
Por todo esto y mucho más, ardan los comentarios en el infierno.
Chavalada, en mi poco tiempo en esto del desarrollo os digo que pocas cosas tengo tan seguras como lo que voy a decir a continuación: el modelo no es una jodida base de datos. Una base de datos NUNCA puede ser el modelo. De hecho, decir que el modelo es una base de datos es la misma aberración que decir que un modelo es un XML, un CSV o un archivo de texto.
El modelo es pura abstracción: no hay sistema operativo, ni frameworks, ni tablas. Insisto, ¡NO HAY TABLAS!
El modelo no son los trazos que representan el número 8, sino el número como abstracción. Es algo conceptual, puro, casi etéreo y sagrado. Decir que el modelo es la BBDD es casi un insulto. ¿Tan poco valoras tu dominio para casarlo con una representación determinada, que para colmo siempre se acaba traduciendo en palabras como «tabla», «fila», «columna? La entidad, el concepto… lo es todo.
Ensuciarlo con terminología de bases de datos solamente denota una falta de visión del dominio. Hay gente se empeña en ver claves ajenas, inner joins, consultas de consultas, procedimientos almacenados… Todo eso está muy bien, pero no dejan de ser trazos, un bitmap, un dibujo del número 8, no el número en sí mismo.
Habrá gente que me diga que me pongo filosófico respecto al tema (como es costumbre en mí), que no hace falta ser tan extremista con el tema y que en el fondo nos basta con pensar que la base de datos es un modelo válido. Es cierto que normalmente una base de datos puede representar con cierta fidelidad un dominio, pero no deja de ser eso: una representación.
La programación como arte que evoluciona tiende a ser cada vez más cercana al dominio. Hay muchos patrones arquitecturales que hablan directamente de «Modelo». MVC, MVP, MVVM… es un hecho que trabajar cerca del modelo tiene unas ventajas (obvias). De ahí mi gusto por DDD. Por el contrario, trabajar sin un modelo suficientemente refinado y lejos del ruido de las tecnologías subyacentes tiene innumerables inconvenientes.
Conozco casos en los que se ha usado un XML como modelo. ¿Os podéis imaginar lo que pasó? Mierda, mierda y más mierda. Aplicaciones imposibles de modificar, acoplamiento infinito.
Tenemos que alejarnos de eso. Una BBDD tanto si es relacional como si no, es tan solo una manera de almacenar datos con cierta estructura. Otra cosa es que haya aún demasiada gente que ha estado tan apegada a SQL que no sepa ver más allá de filas, columnas y selects.
Goooooooooooooooooogle!
It’s enounced by someone called «Suppa JMN» and states the following:
The code quality in a project is proportional to the number of total lines and inversely proportional to the product of the squared average of net lines of code by the number of classes named with the «Manager» suffix.
Where:
- N is the net lines of the project.
- M is the number of Managers.
- c is the net lines of code of a class (measured as average).
The following list illustrates the measurement:
You definitely have to take a look to these recipes! 🙂
Aventuras en .NET 