Better Programmer

Spec#

2008-08-17T12:38:00.000-07:00

Hace unos días ya del último post, y después de los comentarios de Humberto me animo a lanzar este otro post, también enlazado al tema del diseño por contrato (DbC).

Probablemente este sea un tema que aunque sabemos es muy interesante, haya quedado como “engavetado” por muchos de nosotros, tal vez por la incapacidad de los lenguajes o tal vez por la motivación de aprender otras prácticas.

Dejándome llevar por la motivación de aprender (en aquel momento TDD) leí el artículo del post pasado y al llegar al final vi que se enumeraban otras alternativas al framework que ahí se utilizó. Las alternativas se muestran siguiendo un orden, que desconozco los elementos que se tuvieron en cuenta para realizarlo, pero se presentan de la alternativa más cruda a la mejor.

Como programador al fin me fui a analizar los casos extremos, así que le di un vistazo a la más cruda, pero estaba tan cruda que no la pude digerir, se trataba de lanzar excepciones con validaciones en el código, esto no creo que valga la pena ni analizarlo, así que pase directamente a la mejor de las opciones enumeradas, Spec#.

En el artículo dice textualmente: Option 7. Microsoft's Spec# project is researching adding DbC to C#. It looks comparable in sophistication to Eiffel, but Spec# is unfinished: it's not licensed for commercial development. Microsoft's recent announcements about C# 3.0 didn't mention it, but hopefully DbC will make it into C# 4.0 ... whenever that may be.
Interesante verdad??

Aunque se menciona como la mejor de las alternativas, se dice que no estaba terminado. El artículo estaba fechado 2 Feb 2008, dos años atrás.. Y fue que me dije, deja ver que han pasado en estos dos años y fui a visitar el sitio. Uds pueden visitarlo en esta dirección: http://research.microsoft.com/SpecSharp/

Según tengo entendido aun el proyecto está en desarrollo, pero ya lo podemos utilizar (creo que la limitante de que no existe licencia para uso comercial continúa), yo he bajado la instalación que ahí tienen y funciona perfecto. Creo que donde está un poco flojo es en las ultimas adiciones a C# con el framework 3.5, lambda expression, LINQ, etc. Yo al menos estoy trabajando en 2.0 y lo poquito que he visto, esta genial, no me esperé que estuviera tan avanzado.

Como se han percatado no es un lenguaje nuevo, es simplemente una extensión a C#, por lo tanto uno programa sencillamente en C# pero puede utilizar algunas nuevas sintaxis soportadas por Spec#. Se habla de incluir todo esto en futuros releases de .NET, interesante.

Spec# adiciona a C# la posibilidad de distinguir en la declaración de una variable si la variable no podrá ser referenciada a NULL, esto se conoce como: non-null object references (adios a las condiciones que preguntan por null en nuestro código), ofrece especificaciones para los métodos como pre y post condiciones, una disciplina para el manejo de excepciones y brinda soporte para expresar invariantes a nuestras clases.

Me parece un tema bonito, algo que he sacado de la “gaveta” y que quisiera compartir con uds. Me alegra muchísimo que Humberto haya estado hurgando en el tema pues con su experiencia podremos ver si esto tiene futuro y quién sabe si esto es lo que nos tiene preparado Microsoft para después de LINQ…

Si les interesa el tema instalen la extensión a C# y en próximos post entramos en la materia, discutiendo ventajas y desventajas…

Espero sus comentarios.
Erlis

Introduciendo Diseño por Contrato al Test Driven Development!

2008-08-05T05:33:00.000-07:00

Hola a todos!

Me animo a escribir pues hace poco estaba leyendo unos artículos de Test Driven Development (TDD) y por casualidad encontré uno que me ha motivado a investigar más sobre algo que ya todos conocemos, Diseño por Contrato (DbC).

La verdad es que no se cuantos de uds. están usando TDD o no; y se que solamente este tema abarcaría un muy interesante intercambio en el blog; pero el objetivo principal de este post (y los posteriores que pretendo publicar) es enfocarnos en conocer lo que ya se ha logrado con DbC utilizando C#.

En este artículo no se explica en profundidad ninguna de las dos técnicas. Y la idea es hacer notar como podemos mejorar una usando la otra.

Espero que les guste y les motive tanto como a mi. Aquí va el artículo: http://www.codeproject.com/KB/architecture/DbCwithXCSharp.aspx

A mi entender, XC# no es la mejor herramienta para utilizar DbC, pero lo que creo importante en este artículo no es la herramienta, sino los conceptos.

Sobre un mejor acercamiento a DbC en C# tratará el próximo post.

Noten en las alternativas a XC# como se hace referencia a nuestro querido Miguel Katrib.

Happy programming, not debugging!
Erlis

Las 9 reglas para un mejor diseño de software

2008-06-30T17:39:00.000-07:00

Hace algunos días, por recomendación de un amigo (Karel para los que lo conocen), lei algunos artículos de un libro llamado The ThoughtWorks Anthology (tengo el libro en pdf para el que le interese), y me llamo la atención un articulo llamado “Object Calisthenics”, acerca de un conjunto de reglas, por cierto bien restrictivas, para lograr según el autor Jeff Bay, (un ThoughtWorker, es decir trabaja en ThoughtWorks) un mejor diseño del software. Aquí abajo enunciare en español, las 9 reglas, que muchas de ellas a primera vista les parecerán un disparate, y difícil de seguir al pie de la letra. El autor para probar que puede usarse en cualquier proyecto de software, acaba de terminar uno con más de 100 000 líneas de código, usando las 9 reglas.

Pues sin mas, aqui van:

1- Usa solo un nivel de indentación por método (Use only one level of indentation per method).

2- No uses el “else” dentro de una condicional (Don’t use the else keyword).

3- Usa Wrappers para los tipos primitivos y las cadenas (Wrap all primitives and strings)

4- Solo usa un punto por línea (Use only one dot per line).

5- No abrevies (Don’t abbreviate).

6- Mantén las clases pequeñas (Keep all entities small)

7- No utilices una clase que tenga mas de 2 variables de instancia.(Don’t use any classes with more than two instance variables)

8- Una clase que contenga una colección no debe contener otras variables de instancia (Use first-class collections).

9- No use setters y getters (Don’t use any getters/setters/properties).

La explicacion de cada una de las reglas, y las razones del autor estan en el ensayo que forma parte del libro The ThoughtWorks Anthology ,y los interesados que me escriban y pondre el libro en alguna parte. No se han hecho esperar las reacciones (el libro salio Marzo 2008), pongan Object Calisthenics en google y veran pros y contra.

Se embullan a hacer la prueba? Ya yo lo estoy intentando y en un proximo post, les dire.

AUMENTA LA PRODUCTIVIDAD CON RUBY ON RAILS

2008-06-20T15:58:00.000-07:00

Quizas hayan escuchado de Ruby on Rails (RoR). Para los que no, este es un framework que desde hacer unos 3 años a causado una explosión en lo referente a programación web. Tanto así que hay toda una subcultura y culto en la red alrededor de este framework.

¿ Pero que es Ruby on Rails ?

Según su sitio web Ruby on Rails es: "Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustaintable productivity. It lets you write beautiful code by favoring convention over configuration." En pocas palabras y en mi experiencia, es un framework que te ayuda a organizarte mejor para llevar a cabo proyectos relativamente grandes, permitiendo aumentar la productividad hasta un 70% en comparación con otros proyectos con Spring, Tapestry y Struts. Creado por David Heinemeier Hansson (DHH) cuando estaba desarrollando la aplicación BaseCamp en 37signals. DHH un tiempo después de publicarse BaseCamp regalo su framework llamandolo Ruby on Rails.

Sus puntos fuertes son:

Uso de lenguaje Ruby
Convention over Configuration (CoC)
Don´t Repeat Your Self (DRY)

¿ Por qué es tan productivo RoR ?

Bueno, como dice el dicho, ver para creer, aquí les va un link de los muchos que hay en youtube y si quieren pueden ver ese mismo video con mejor calidad aquí.

Impacto de RoR

RoR ha llamado la atención de mucha gente, tanto grandes como pequeños, de hecho Microsoft creo que tiene un demo para agregar Ruby y RoR en su framework Visual Studio.
Algunos otros lenguajes de programación más convensionales han desarrollado frameworks tratado de adoptar la filosofia que ha logrado el exito de RoR como son:

PHP: CAKEPHP
JAVA: GROOVY

Grandes aplicaciones han migrado a RoR y apostado por este relativamente nuevo framework:

Como empezar

Para los que deseen empezar a usar RoR y no maltratarse con el notepad y la línea de comandos, pueden usar estos editores: Windows, Linux Aptana, para los que usen MAC TextMate. Si les parece intersante RoR, aquí les van los libros indispensables:

Otros sitios:

Bueno, espero que les haya sido interesante.

La 2da piedra!!! "Code Smells"

2008-06-20T11:39:00.000-07:00

Al parecer por falta de tiempo en estos días, nadie ha querido romper el hielo en este blog (me refiero a los 3 contribuyentes que ya se han apuntado en este blog), yo rompí el hielo (gastando algún tiempo buscando donde poner el blog) y lance la primera piedra, al parecer me tocara lanzar la segunda.

Empezare por algo que he visto últimamente reflejado en varias publicaciones. El que halla programado por algún tiempo habrá notado y se ha dicho, "este código esta feo" y en busca de la perfección lo cambia una y otra vez, porque no le cuadra como quedan las clases, o los paquetes, métodos muy largos, o no se, simple intuición.

Para que el que no lo sabe (hasta hace poco yo no lo sabia), hay un termino en ingles "Code Smells" para definir este tipo de "código feo", no me aventuro a traducir al español este termino, y no es mas que practicas cuando programamos que debiéramos evitar, o que vemos y compulsivamente deberíamos tratar de refactorizarlas y cambiarlas por el bien del sistema que estamos "construyendo" y ya veran el por que en los artículos recomendados abajo. Este termino fue bautizado por Kent Beck, un guru de la programación ágil, y que ayudaba a Martin fowler (otro guru mas www.martinfowler.com), cuando escribía el libro "Refactoring: Improving the Design of Existing Code" (yo lo tengo en PDF para el que lo quiera, se los recomiendo), y es allí donde definen, los famosos "Code Smells". Pero dejémosle a los especialista las explicaciones, aquí pongo algunos artículos sobre "Code Smell" para los interesados, ya que no valdría la pena que yo le dijera en español, lo que esta bien explicadito en ingles :D.

http://martinfowler.com/bliki/CodeSmell.html

http://wiki.java.net/bin/view/People/SmellsToRefactorings

http://www.codinghorror.com/blog/archives/000589.html (gracias al Karel)

PD: Bueno no soy buen escritor, pero si quería terminar de abrir el blog, y que todos nos ayudemos a mejorarnos como programadores, asi que espero que los mas especialistas, empiecen a contribuir y que nos hagamos la costumbre de revisar al menos una vez al día, y comentar sobre los artículos que se postean, dentro de ese apretado tiempo de que todos disfrutamos. Y que cualquier puede postear, y sino tiene tiempo de entrar o algo que lo mande a los otros, para postearlo.

Nace el blog

2008-06-17T13:22:00.000-07:00

Queremos crear un blog para compartir informacion relacionada con el mundo de la programacion, los nuevos lenguajes y tendencias. Creo que sera mejor que enviar emails, asi tenemos toda la informacion concentrada en una pagina, donde todos podemos ver y discutir sobre cuestiones de programacion y asi ser mejores programadores.

We want to have a blog to share information related to programming, OO design and principles, languages and new tendencies within the IT industry.