Gabriel Rodriguez Plancarte

CodeBetter Logo

Karl Seguin, blogger de CodeBetter.com, acaba de actualizar su serie de articulos convertidos a Ebook, llamado Foundations Of Programming.

El libro trata temas como:

• Principios ideales de programación como YAGNI (You Aren’t Going to Need It), DRY (Don’t Repeat Yourself), Continuous Integration, Coupling, etc.
• Domain Drive Design (DDD)
• Dependency Injection
• Unit Testing
• Object Relational Mappers (ORMs)
• Exception Handling.
• Mocking

Y más. El libro es bueno, y definitivamente creo que cualquiera de nosotros conoce la mayoría de los temas del libro, pero definitivamente se puede sacar mucho provecho de esta publicación que Karl se tomó el tiempo de hacer.

Ya sea que domines varios de estos temas y quieras familiarizarte con uno que no conoces, o que no sepas sobre arquitectura en general y quieras aprender, este libro te puede ayudar.

Esta serie de aprendizaje también incluye una aplicación de muestra, llamada Canvas Learning Application, que implementa varios de los principios de programación que se enseñan en el libro. Esto para los que nos gusta aprender de manera más practica, analizando código.

Las ligas al ebook y a la aplicación:

Foundations Of Programming (PDF)

Foundations Of Programming (DocX)

Canvas Learning Application (Sample Application)

Espero les sirva.

En varias aplicaciones que proveen un dropdownlist para escoger el nombre de un Mes, he visto que los desarrolladores llenan los nombres de los meses a través de un archivo de recursos, o peor, hard-codeando los valores. Esto no es necesario, ya que los nombres de los meses del calendario de cada cultura pueden ser accesados a través de un objeto CultureInfo que represente la cultura del país/idioma para el cual queremos obtener los meses.

Lo primero es agregar un using de System.Globalization.

El siguiente metodo va a imprimir todos los meses del año del calendario del objeto CultureInfo que le pasemos.

Generalmente vamos a querer que los nombres empiecen con mayúsculas, así que también estoy usando el método ToTitleCase, que va a formatear correctamente los nombres de los meses a TitleCase según el formato correcto de la cultura tambien.

public static void ImprimirNombreMeses(CultureInfo cultura)
{

// Primera manera, LINQ
var qry = from m in cultura.DateTimeFormat.MonthNames
select cultura.TextInfo.ToTitleCase(m);

foreach (var mes in qry)
{
Console.WriteLine(mes);
}

// Segunda manera, tipico foreach
foreach(string mes in cultura.DateTimeFormat.MonthNames)
{
Console.WriteLine(cultura.TextInfo.ToTitleCase(mes));
}

Console.ReadLine();
}

La primera parte del método usa LINQ. Si estás usando una version anterior al framework 3.5, tendrías que ciclar usando un foreach.

El resultado se ve así:

Nombres de meses en objeto CultureInfo

Esta es una de las tantas razones por las cuales me gusta el .NET Framework. Si lo necesitas, probablemente ya esté integrado.

.NET Logo

Los que usen LINQ, especificamente LINQ to SQL, favor de leer el siguiente articulo:

IEnumerable.Count() is a Code Smell

El articulo explica que es muy comun para cualquier desarrollador utilizar este metodo para hacer validaciones del tipo:

if(products.Count() == 0) ... 

El problema es que el metodo Count() de IEnumerable es un extension method que no va a hacer short-circuit al encontrar más de un item al ser usado en el contexto del ejemplo anterior.

Peor aun, como la ejecución de LINQ To SQL es deferida, los resultados del metodo Count() no se quedan en cache y cualquier nueva llamada a Count() vuelve a iterar todos los elementos de la coleccion. Tomando en cuenta que LINQ To SQL esta accesando una base de datos…es muy mal performance.

El articulo sugiere usar como alternativa el metodo .Any(). que produce un SQL mas optimizado.

Y si se necesita hacer llamadas posteriores al Count() o Any(), se recomienda eliminar la deferred execution pasando los resultados del query de LINQ a una Lista, de la siguiente manera:

IList<Product> products = GetProducts().ToList();

Para detalles completos, favor de leer el articulo original, del blog de Lee Richardson, Rapid Application Development

System.Environment.SpecialFolder

He visto demasiados programas, utilerías y software en general que todavía intentan adivinar o equivocadamente predefinen el path o ruta a folders especiales de Windows, como Program Files, Documents and Settings, etc. Esto puede resultar en dos cosas, cualquiera de las dos muy molestas y muy mal vistas:

1. El programa no funciona.
2. El programa termina creando folders no deseados en el sistema.

El #2 es especialmente molesto…¿para que sirve que instale Windows en Ingles, si un programa mal hecho va a terminar creando H:\Archivos de Programa de todas maneras?

Es simplemente pésimo diseño de software el asumir y programar software contra la suposición de que el usuario que está corriendo nuestra aplicación instaló Windows en el mismo Disco Lógico que nosotros. Las empresas generalmente instalan Windows en cualquier directorio excepto C:\Windows, precisamente porque muchos virus, troyanos, etc. fabricados por amateurs solo intentan instalarse contra C:\Windows, así que instalar Windows en un directorio diferente al predeterminado es una simple protección extra. Es por esto que un desarrollador nunca debe intentar adivinar la ruta a un folder especial de Windows.

Microsoft, en el namespace System, provee un metodo y una enumeration en conjunto que permite obtener directamente de Windows el path/ruta a varios folders especiales de Windows:

El metodo es estático, y se llama Environment.GetFolderPath, que recibe como parámetro un enum de tipo Environment.SpecialFolder.

Los valores del enumeration Environment.SpecialFolder son:

1. ApplicationData
2. CommonApplicationData
3. Cookies
4. Desktop
5. Favorites
6. History
7. InternetCache
8. Programs
9. MyComputer
10. MyMusic
11. MyPictures
12. Recent
13. SendTo
14. StartMenu
15. Startup
16. System
17. Templates
18. DesktopDirectory
19. Personal
20. MyDocuments
21. ProgramFiles
22. CommonProgramFiles

Ver detalles en MSDN sobre System.Environment.SpecialFolders

Ver detalles en MSDN sobre System.Environment.GetFolderPath

La forma correcta de obtener el path al folder de Program Files, seria entonces:

string programFilesPath = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)

lo cual, en mi sistema, resultaría en “H:\Program Files”.