Platicas de .NET del LinkedIn .NET Users Group

LinkedIn .NET Users Group

LinkedIn .NET Users Group

Hace poco me uni al grupo de LinkedIn .NET Users Group (mejor conocido como LIDNUG) en el site de LinkedIn.

El grupo tiene 29,427 miembros hasta el día de hoy, con origenes muy variados. Hay desarrolladores, managers y hasta recruiters para trabajos relacionados con .NET

La gente de LIDNUG ha tenido la suerte de poder tener sesiones de platicas (y grabadas en LiveMeeting) con gente muy importante de la comunidad de .NET, entre los principales:

  • Scott Guthrie – Corporate VicePresident de .NET Developer Platform y persona clave en la creación y desarrollo de .NET
  • Scott Hanselman – Senior Project Manager en la Developer Division, conocidísimo blogger. Tiene su propio podcast de .NET llamado Hanselminutes donde trata temas de todo tipo relacionados en su mayoria con desarrollo de software y .NET
  • Sara Ford – Software Design Engineer de Microsoft, antes del Visual Studio Core Team, ahora en el proyecto de CodePlex.

Lo mejor de estas platicas es que, como ya dije, el grupo de LIDNUG las graba y las pone disponibles para que cualquier persona interesada las baje.

La liga es esta: LinkedIn .NET Users Group Presentations

Si les interesa aprender .NET de la gente que lo creó y lo entiende mejor que nadie, bajen las sesiones.

Como medir tiempo de ejecucion de codigo en C# y .NET

Proximamente voy a hacer un comparativo de performance entre Entity Framework y Subsonic, así que se me ocurrió de una vez escribir este post sobre la manera correcta en que se debe medir el tiempo de ejecución de un cierto bloque de código utilizando C# y .NET.

La medición del tiempo se hace usando una instancia de la clase StopWatch, que se encuentra en el namespace de System.Diagnostics. La clase StopWatch provee un conjunto de métodos y propiedades que pueden ser usados para medir con alta precisión el tiempo transcurrido entre intervalos.

Los métodos disponibles sobre esta instancia serían:

  • Start() – inicia el contador a partir del último lapso. La cuenta es acumulativa, es decir, si se verifica la propiedad ElapsedMilliseconds después de 4 llamadas a los métodos de Start y Stop, el tiempo desplegado será el acumulado de los 4 intervalos.
  • Stop() – detiene momentaneamente el timer.
  • Reset() – reinicia los valores almacenados del timer

Las propiedades disponibles, que usaríamos para desplegar el tiempo que tomó alguna rutina, serían:

  • Elapsed – Regresa una instancia de tipo TimeSpan que determina el tiempo que ha transcurrido desde que se llamó al método Start() por primera vez.
  • ElapsedMilliseconds – Regresa un valor de tipo long que indica los milisegundos transcurridos desde la primera vez que se llamó al método Start().
  • ElapsedTicks – Regresa un valor de tipo long, que indica los Ticks que han pasado desde la primera vez que se llamó al método Start(). Nota importante respecto a esta propiedad: Los ticks de un StopWatch no son iguales a los ticks de un DateTime. En DateTime, cada tick representa un intervalo de 100 nanosegundos. En StopWatch, un tick representa un intervalo de tiempo equivalente a 1 segundo dividido entre la propiedad Frequency del StopWatch.
  • IsRunning – determina si el timer está activo y contando Ticks.

Las propiedades IsHighResolution y Frequency no son propias de una instancia StopWatch, sino de la clase StopWatch.

IsHighResolution indica si el timer utilizado está basado en un contador de performance de alta resolución. Esto depende del procesador/arquitectura de la computadora en la que está corriendo el código

Frequency representa el numero de StopWatch ticks por segundo.

Ahora, un poco de código de ejemplo:

Console.WriteLine(string.Format(“IsHighResolution: {0}”, Stopwatch.IsHighResolution ? “Yes” : “No”));
Console.WriteLine(string.Format(“Frequency: {0}”, Stopwatch.Frequency));
Console.WriteLine(“———————-“);

var dos = “2”;
var suma = 0;

//Medir int.Parse
var timer = Stopwatch.StartNew();

for (var i = 1; i <= 1000; i++) { suma += int.Parse(dos) * i; } timer.Stop(); Console.WriteLine(string.Format("Suma: {0}", suma)); Console.WriteLine(string.Format("Elapsed para int.Parse: {0}", timer.Elapsed)); Console.WriteLine(string.Format("ElapsedMilliseconds para int.Parse: {0}", timer.ElapsedMilliseconds)); Console.WriteLine(string.Format("ElapsedTicks para int.Parse: {0}", timer.ElapsedTicks)); Console.WriteLine("----------------------"); suma = 0; //Medir Convert.ToInt32() timer = Stopwatch.StartNew(); for (var i = 1; i <= 1000; i++) { suma += Convert.ToInt32(dos) * i; } timer.Stop(); Console.WriteLine(string.Format("Suma: {0}", suma)); Console.WriteLine(string.Format("Elapsed para Convert.ToInt32: {0}", timer.Elapsed)); Console.WriteLine(string.Format("ElapsedMilliseconds para Convert.ToInt32: {0}", timer.ElapsedMilliseconds)); Console.WriteLine(string.Format("ElapsedTicks para Convert.ToInt32: {0}", timer.ElapsedTicks)); [/code] da el siguiente resultado:

Midiendo intervalos de tiempo con la clase StopWatch

Midiendo intervalos de tiempo con la clase StopWatch

Como se puede apreciar, int.Parse es ligeramente más rapido que Convert.ToInt32().

De manera simplemente informativa…hay otra manera de medir intervalos de tiempo que mucha gente usa, y NO es correcto ni recomendable. Lo hacen asignando el valor de DateTime.Now a una variable de tipo DateTime y luego lo resta al valor de DateTime.Now en el momento que quieren dejar de medir.

Hay todavía otra manera similar al uso de DateTimes, que es usando la propiedad Environment.TickCount.Esto es incorrecto por tres razones:

1. Si existe una clase especializada para hacer esto en el framework, digase StopWatch, hay que usarla.
2. Environment.TickCount es signed (puede representar valores negativos también) lo cual implica que después de 25 dias, se va a entrar al rango negativo y se tendría que eliminar el bit del símbolo para poder hacer calculos correctos. Después de 50 dias, se llenarían todos los bits de la variable y la cuenta se reiniciaría. Ver discusión en StackOverflow.com donde se menciona esto.
3. En palabras del mismo Scott Hanselman, y mencionado en el mismo link de la razon #2: As an unrelated aside, if you DO use DateTime for Date-related math calculations, always use DateTime.UtcNow as DateTime.Now is susceptible to Daylight Savings Time…your calculations could be off by a hour, or worse, negative numbers.

Es decir, es muy facil que a la gente se le olvide que si va a cronometrar de esta manera, usar DateTimes para medir intervalos puede ser susceptible a los conocidos “horarios de verano”, que desfazan por temporadas el reloj por +- 1 hora. Cualquiera de las dos alternativas a StopWatch (DateTime o Environment.Ticks) es relativamente riesgosa para ser útil.

Links de Referencia:

Clase StopWatch @ MSDN

Principios de Diseño Orientado a Objetos (OOD)

Siguiendo con esas cosas que todos deberían saber…pero que muchos no comprenden totalmente:

Robert Martin, mejor conocido como Uncle Bob, explica de manera muy clara los principios básicos de diseño orientado a objetos. No solo es necesario poder recitar estos principios, sino que hay que entenderlos y poder explicar las razones de su importancia.

Precisamente de este articulo que voy a poner la liga, cito un párrafo que es muy cierto:

“All too often today’s programmers are unaware of the principles that are the foundation of the disciplines that their languages were derived around.”

Los primeros 5 principios son los famosos SOLID (que en muchas ocasiones les tocará leer el acrónimo en artículos) y son orientados a diseño de clases. Los 3 siguientes son orientados a Cohesión de librerías de código, y los últimos 3 son orientados a dependencias entre librerías de código.

Los principios SOLID:

  • Single Responsibility Principle (SRP)
  • Open-Closed Principle (OCP)
  • Liskov Substitution Principle (LSP)
  • Interface Segregation Principle (ISP)
  • Dependency Inversion Principle (DIP)

Incluso cada uno de los principios está claramente explicado y disponible para bajarse en PDF por separado. La siguiente es la liga:

The principles of Object Oriented Design, by UncleBob

Voy por la certificacion de Microsoft Certified Professional Developer

Microsoft Learning

Microsoft Learning

Tiene años, probablemente fue en el 2005 o 2006, que presente el examen de Web Applications en .NET y consegui ser MCP. Definitivamente el puro título ha abierto muchas puertas, asi que creo que iré por una certificación un poco más completa y extensa.

La certificación de Microsoft Certified Professional Developer (MCPD) es la que me llama la atención, especificamente la especializada Enterprise Application Developer 3.5 on Visual Studio 2008.

Tiene 5 examenes de MCTS (Microsoft Certified Technology Specialist) como pre-requisito, y el examen de MCPD es el PRO: Designing and Developing Enterprise Applications Using the Microsoft .NET Framework 3.5 (70-565).

La lista de examenes requisito para ser Entrerprise Application Developer:

MCPD Enterprise Application Developer Exam List

MCPD Enterprise Application Developer Exam List

Voy por el primero, el Application Development Foundation…voy a leer el material y presentar un examen de prueba en TestKing, espero para Octubre-Noviembre ya haber pasado ese.

1 15 16 17 18 19 31  Scroll to top