miércoles, 21 de noviembre de 2012

[007] La biblia del programador

Introducción

20 años en el mundo de la programación dan para mucho. He visto pasar ante mi muchas tecnologías y algunos paradigmas de la programación. He leído a los mejores programadores y me he nutrido de sus experiencias haciéndolas mías.

¿ Qué es para mi la programación ?

Si fuese un programa podría contestar fácilmente a esta pregunta y diría que la programación es una ciencia, pero como soy un ser humano la contestación se complica. Si programar se entendiese solamente como darle instrucciones a un ordenador, sería algo que haría todo el mundo. Mi definición de la programación sería las siguiente:

" Disciplina de ingeniería que con habilidad crea arte."

La escritura de código de programación hay que verla con ojos de autor, tal cual un escritor literario que con sus letras crea algo que toma vida propia. Por ello la literatura y la programación son mucho más que el simple acto de escribir. Ha de convertirse en una experiencia religiosa.

En la parte de oficio que tiene la programación, es puro bricolaje y como tal necesita herramientas. Es el único trabajo que permite a la par ser ingeniero y artista.

¿ y Qué es un programa ?

Un programa es un mecano de piezas que para unirlas son necesarias diversas cualidades, y que una vez unidas se crea un bello objeto matemático de técnica, ingeniería y arte. Si queremos ver un programa como algo físico podemos compararlos con cualquier aparato mecánico. El interior de un programa es muy parecido a como en una máquina una rueda dentada engrana con otra. Está lleno de simetrías.

Un programa es algo muy hermoso cuando sus usuarios no han necesitado casi formación para manejarlo volviéndose extremadamente coherente, cuando es claro y limpio... cuando está bien estructurado. Tan hermoso como para imprimirlo en papel de pergamino y llenar una pared con él.

"El mejor programa es aquel que sea tan fácil de entender como un electrodoméstico."

Esto quiere decir que el programador ha puesto toda la complejidad de su parte. Nadie necesita un curso intensivo de formación para usar una lavadora. Es algo comprensible a la par que elegante.

¿ Cómo es un mal programa ?


  • Es aquel que limita o no permite añadir fácilmente características una vez terminado. 
  • Es aquel que se convierte en algo extremadamente complejo para el usuario. 
  • Es aquel que no tiene una base sólida que podría ser utilizada como un framework de trabajo para posteriores proyectos. 
  • Es aquel que tiene muchas dependencias de productos de terceros, dejando de ser una creación propia. 
  • Es aquel que tiene tantas imágenes que la suma del peso de las mismas es más del doble que el peso del código del propio programa. 
  • Es aquel que consume excesivos recursos obligando a los usuarios a tener computadoras potentes.
  • ES aquel que no podamos clasificarlo como minimalista.


Lo primero de todo...

El primer paso para empezar a programar es imaginar, sin escribir ni una línea de código. Hay que tomar una pluma, un lápiz o una estilográfica y comenzar a plasmar esa idea en un papel, dibujar, dibujar y dibujar. Para ello podemos utilizar UML o nuestros própios garabatos, incluso realizar un "Metaprograma". Una vez definida la estructura principal de nuestra creación podemos iniciar el proceso escribiendo código. Esta parte junto con las interfaces gráficas es el arte que mencionaba anteriormente. En una segunda parte el conocimiento y la aplicación de los mejores algoritmos es la ciencia.

El código debe ser terso y conciso. Tenemos que ser capaces de explicar cualquier algoritmo de nuestro programa en una sola frase. Para ello los algoritmos no deben ocupar más de una página.

Las características  que todo buen programa debe tener son:
  • GRANULARIDAD: Para que nos entendamos lo diré con otra palabra "Flexibilidad".
  • SIMPLICIDAD: Fracionar el programa en piezas separadas.
  • HOMOGENEIDAD: Evitar las excepciones o casos especiales dentro de los programas.
  • RECURRENCIA: Optimización, Optimización y más Optimización.
  • TRANSPARENCIA:  Los usuarios deben olvidar que hay un programa entre ellos y los datos.

Mis Herramientas son...

La primera herramienta que debe dominar un buen programador son las matemáticas, debe tener una bases sólidas, las cuales nos ayudarán a razonar y nos permitirán a través de la abstracción ver más allá de nuestros ojos. Otra herramienta muy importante para no perder las conexiones con el mundo real son seguimiento de las humanidades. 

"No podremos crear nunca un buen programa de contabilidad si no la entendemos."

El código de terceros es una herramienta vital en nuestros inicios, y yo diría que siempre. Nos permite aprender que es lo que debemos y no debemos hacer para dominar un lenguaje de programación, además nos proporciona un punto de vista nuevo desde el que contemplar nuestro trabajo. 

El inglés técnico es una herramienta vital para mi trabajo como programador. Aunque suene raro otra de mis herramientas se basa en rodearme de gente con mucho talento. El buen programador conoce tan bien sus herramientas como el pintor sus pinceles. El dominio de las herramientas de programación, y no me refiero sólo al IDE, permite crear la herramienta principal que son nuestros programas.

Como no fiarse de uno mismo...

Es sumamente importante que realicemos frecuentes revisiones de nuestro código. Los mejores programas son aquellos que se han realizado por una sola persona. Los programa realmente buenos, es decir las obras de arte, viven para siempre y nunca dejarán de escribirse.

Los tiempos son importantes, hay que controlarlos. En la mayoría de los proyectos el último 10% consume el 50% del tiempo.

Nunca hay que dejar de optimizar, optimizar y seguir optimizando. Nos saldrán piedras en el camino pero cuando desarrollemos un programa, se nos abrirán puertas y pasajes inesperados.

Lo que hay que tener...

Para ser un buen programador se necesita una combinación de talento, temperamento, motivación y trabajo intenso. Esto no es una profesión es un dogma de fe y son necesarios altos niveles de vocación para destacar. El riesgo más importante es aquel que pueda hacer perder el contacto con la realidad.

Un buen diseño implica adquirir con tu programa y con sus usuarios una serie de compromisos y equilibrios, y esta es la parte más compleja. Es importante no enamorarse con locura de una idea, ( los placeres sensuales llevados al exceso son una maldición más que una bendición ), cuidado con la adicción, ya que si lo hacemos estaremos destinados al fracaso, pues como hemos mencionado desconectaremos al programa de sus usuarios. 


"Hay que hacer que funcione en un tiempo razonable, y luego ser capaz de deshacerse de ello."

Los ciclos de programación han de ser rápidos en su edición, ejecución y depuración continua. Tiene que convertirse en algo divertido sentarse frente al portátil y dejar que fluya el código. No debe ser necesario tener que implementar en nuestros programas ingentes cantidades de comentarios, el programa en sí tiene que ser capaz de explicarnos lo que hace, para que sirve.

Hay que tener la capacidad, yo diría que la humildad, de no dar nunca por supuesto que uno sabe algo que otro no sabe. Ser un gran aprendiz de todos, antes que un gran oficial de algo. Debemos aprender a poner en duda nuestras propias suposiciones. Debemos tener un buen sentido estético con una aguda conciencia para infringirlo, mezclado con un poco de complejo de culpa que nos obligue a mejorar continuamente.

Un buen profesional será aquel que sea capaz de leer unas 25 páginas de código y comprenderlas en un tiempo razonable. Esto lo hará ser práctico, que no inteligente. He conocido a mucha gente inteligente que no es práctica.

El afán de absorberlo todo, libros, código de otros programadores, etc. ha de ser interminable. Aunque la creatividad sea un Don, también se puede aprender mucho de la creatividad de los demás. No hay que tener miedo en programar tantos proyectos distintos como se nos presenten. Si uno tiene interés, necesitará sólo una parte del talento necesario para crear algo coherente y de calidad.

Una de las mejores cualidades de un buen programador es aquella que le hacer llegar siempre al fondo de las cosas, abriéndose paso a paso entre los amasijos de código para descender al los niveles más fundamentales para resolver cualquier fallo de diseño.

Los trucos de la veteranía...

Para controlar la complejidad de nuestros proyectos debemos dividirlos en partes más pequeñas. Tenemos que descomponerlos en fragmentos manejables y simples. Empezaremos por resolver los fragmentos más difíciles. Esto mismo nos servirá para manejarse en la vida y arreglárselas bastante bien. Lo más importante es definir de la forma más precisa los interfaces entre nuestro sistema y el mundo real. 

El truco esta en definir los algoritmos de manera que los podamos tener completamente almacenados en nuestra cabeza. Como he mencionado tenemos que desarrollar la cualidad que nos permita organizar la idea en la que se basa nuestro proyecto en una estructura más simple y manejable, especificando cada componente. 

"No hay que comprometerse demasiado pronto, ni adelantar decisiones sino es necesario."

 Mi consejo es no meterse en desarrollos de varios años sin resultado alguno en el corto plazo, no más de un trimestre, para poder así evaluar, reagrupar y tener la posibilidad, si es necesario, de empezar de nuevo. No hay que dejar de construir programas rápidos y pequeños que usen algoritmos claros y concisos, es necesario para la salud mental de cualquier programador.

La resolución de los problemas de un proyecto nunca es algo que se me ocurre, siempre es algo que simplemente ocurre. 


"Siempre habrá una gran diferencia entre lo que nos gustaría hacer y lo posible."

Si trabajamos en equipo el ambiente para el intercambio de ideas ha de ser abierto. No hay que guardarse nada. En la transmisión de conocimientos está la estabilidad profesional y la sabiduría. Tenemos que tener nuestro propio estilo.

Hay que tratar siempre de aislar los algoritmos que son utilizados en diferentes procesos, para economizar en el código y mejorar así la velocidad. 

Hay que hacerse siempre las mismas preguntas: ¿ Que Quiere realmente el usuario ?, ¿ Que van a usar realmente de lo que quieren ?, ¿ En que les va a beneficiar ?, los usuarios siempre van ha hacer las cosas de manera diferente a como las ha implementado el programador.

Hasta que realmente se valida un programa por parte de los usuarios, trabajando con él durante algún tiempo, no se pueden ver sus puntos débiles.

La clave para el oficio de programar estriba en encontrar y aplicar las reglas que configuran el núcleo de nuestro aplicativo. Hay que tener conciencia de ello. 


"Los mejores programas proceden directamente del planeta de la intuición."


La materia prima...


La materia prima de un programa y su recurso más valioso son los datos, la información. Y no solo me refiero a la información que acabarán introduciendo los usuarios, sino aquella información interna (variables, tablas de decisión, ficheros de configuración, etc.) que se convertirá en el flujo de la vida del mismo.

El código en sí, también puede ser denominado como materia prima, pero deja de serlo una vez lo hemos plasmado en nuestro programa.

El éxito...

Bueno, supongo que el éxito debe ser algo así como hacer el programa adecuado en el lugar adecuado y en el momento oportuno. Por otro parte el éxito en el trabajo está en hacer la misma cosa una y otra vez, para ir aprendiendo cada vez un poquito más y así hacerlo cada vez un poquito mejor.

Tenemos que pensar que las buenas ideas no vienen fácilmente, por ello hay que rodearse de gente que sea mejor que tu. Más que cualquier otra cosa lo que nos tiene que motivar es el deseo de que nuestros programas sean usados por tanta gente como sea posible.

Si fracasamos en algún proyecto y nos hace caer, sólo nos queda para llegar a tener éxito una opción... Levantarse y volver a empezar.




lunes, 29 de octubre de 2012

[006] Optimizando Código

El sufrimiento de los lenguajes interpretados...


Un lenguaje interpretado es un lenguaje de programación que está diseñado para ser ejecutado por medio de un intérprete, en contraste con los lenguajes compilados. Teóricamente, cualquier lenguaje puede ser compilado o ser interpretado, así que esta designación es aplicada puramente debido a la práctica de implementación común y no a alguna característica subyacente de un lenguaje en particular.

Por todos es sabido que el Fox era un lenguaje interpretado hasta el punto de que nuestros programas podían generar código y compilarlo al vuelo. Así como la macrosustitución. El problema era el elevado consumo de recursos de la máquina y por tanto la lentitud de ciertas partes de nuestras aplicaciones.

A C Sharp le sucede exactamente lo mismo, y por lo tanto tenemos que invertir tiempo en la optimización de nuestro código si queremos que nuestras aplicaciones no desesperen a la gran mayoría de usuarios que tienen máquinas obsoletas pero funcionales.

La principal ventaja de un lenguaje interpretado es que es independiente de la máquina y del sistema operativo ya que no contiene instrucciones propias de un procesador sino que contiene llamadas a funciones que el interprete deberá reconocer. Basta que exista un interprete de un lenguaje para dicho sistema y todos los programas escrito en ese lenguaje funcionarán.


Aquí os marco algunas reglas del juego para que vuestro código esté optimizado y sea estéticamente bello:

  • Al igual que en Fox en C# debemos usar string.Empty en lugar de "", mucho mejor (Nombre == string.Empty) que (Nombre = "").
  • Si queremos obtener del  switch  toda la potencia del DO CASE de foxpro debemos utilizar enumeraciones. (A esto le dedicaré un capítulo entero para explicarlo.)
  • No introducir código en los eventos, hacedlo en un método a parte y llamarlo desde el método asociado al evento. Esto lo veremos en otro capítulo.
  • No gestionar la apertura y cierre de los formularios desde el mismo formulario, hay que hacerlo desde una clase externa.
  • Usa ficheros de recursos para todos los literales de la aplicación, ya sabéis los de tipo .resx, el que no entienda que no se preocupe que lo iré detallando todo.
  • Evita tener archivos de más de 1000 líneas, si sucede refactoriza. Divididlos en varias clases.
  • Evita métodos y propiedades públicas en las clases si no es necesario. Usa internal si son únicas del mismo ensamblado.
  • No crees métodos con más de 5 parámetros, para ello crea una clase o estructura. Los parámetros destrozan la memoria, crean la posibilidad de que los datos se corrompan, y crean más ciclos de microprocesador.
  • No utilices null como retorno de un método. Por ejemplo si tenemos una lista es preferible retornarla vacía.
  • Usa el archivo AssemblyInfo para documentar tu aplicativo.
  • Cuando abras conexiones (bases de datos, flujos de archivo, sockets, etc.), gestionalas con un try/catch y ciérralas en el bloque finally.
  • Igual que antes hemos mencionado como evitar los string con enumeradores, cuandos tengas que gestionar varios string utiliza la clase StringBuilder   .
  • Usa en tus aplicaciones siempre una arquitectura multicapa, esto lo veremos en capítulos posteriores.
  • Si apuestas por Microsoft no utilices tecnologías de terceros, ya que estos terceros nunca van a conocer la estratégia de Microsoft
  • Separa todas la clases no principales o de apoyo (validaciones, archivos de recursos, constantes, logger, etc.) en otros ensamblados, librerías.
  • No abuses de los web services, son un modelo que consume mucho. No hay que utilizarlos para conectar procesos internos.
  • No dudes a la hora de hacer uso de las herramientas del Visual studio, están ahí para hacernos la vida más fácil.
  • No escribas rutinas try/catch en todos tus métodos, ni dejes que los bloques introducidos en el try sean muy grandes. 


                                  

NEWS [Visual Studio 2012]



Sobre Visual Studio 2012


La compañía ha lanzado su solución de desarrollo integrada para crear y gestionar aplicaciones. Visual Studio 2012 proporciona un entorno de desarrollo más rico para crear atractivas aplicaciones que atiendan en todo momento las necesidades de los clientes y que sean accesibles desde cualquier lugar. Además, la compañía también ha anunciado el calendario de la actualización de Visual Studio, así como la disponibilidad de Visual Studio 2012 Express para Desktop, F # Tools para Visual Studio Express 2012 para Web y TFS Power Tools para Visual Studio 2012, entre otras.

Desde España, Microsoft contará con aproximadamente 10 partners que participarán en los lanzamientos locales y organizarán actividades alrededor del mismo a lo largo de los próximos meses. Entre los socios destacan PlainConcepts; GlobeTesting ; Kabel; Avanade; Certia e Ilitia; LARs como Insight, así como resellers especializados en nuestras herramientas de desarrollo como Danysoft Y Rambla Informática.

Características de Visual Studio 2012 : 


1 – Desarrollo innovador de aplicaciones
2 – Gestión moderna del ciclo de vida de las aplicaciones
3 – Posee herramientas para una planificación y gestión de proyectos ágil, que mantienen a los equipos alineados e informados.
4 – También tiene herramientas y flujos de trabajo para romper las barreras en la integración funcional y de equipos de trabajo.

Características .NET Framework 4.5:

- Proporciona a los desarrolladores una forma rica y productiva de crear aplicaciones en el cliente (Windows Forms, WPF, Windows 8 Store Apps), on premise (Windows Server) y en la nube (Windows Azure).



- Sus nuevas capacidades incluyen mejoras de rendimiento y la posibilidad de hacer más sencilla la programación asincrónica y paralela. Además, ofrece funcionalidad de .NET y XAML para Windows 8 Store Apps.

- .NET Framework 4.5 en el servidor también proporciona ASP.NET, WIF (Windows Identity Foundation), Entity Framework y WCF (Windows Communication Foundation). Asimismo, para la nube, Windows Azure proporciona soporte completo para desarrollo .NET con Windows Azure SDK para .NET.


Mi consejo...

Estuve jugando con una de las betas de Visual Studio 2012 en un Windows 7 Home premium de 64 bit, y mi consejo inicial es que esperemos a que un primer Service pack solucione todos los problemas que encontré al combinarlo con el 2010, o incluso al alterar el orden de instalación de los productos tanto de escritorio como para la web que incorpora el paquete.

Personalmente trabajo con un Visual C# 2010 Express SP1 y el Visual Web Developer 2010 Express SP1, y no he tenido ningún problema.



Eventos de lanzamiento...

El martes, 23 de octubre de 2012, en el Salón de Actos del Edificio C, de la Escuela Técnica Superior de Ingenieros de Telecomunicación de la Universidad Politécnica de Madrid va a tener lugar el evento Lanzamiento de Visual Studio 2012.

Asistirán profesionales del sector muy conocidos. Es una oportunidad muy interesante para conocer rápidamente qué trae de nuevo Visual Studio 2012.

Debido a las características locales del evento, las 8 charlas previstas serán muy cortas y directas, de apenas 30 minutos, y como colofón y salvo cambios por agenda, tendremos al final de las mismas la posibilidad de disfrutar de una charla de 5 minutos que nos dará César de la Torre desde Seattle.

martes, 16 de octubre de 2012

[005] Nomenclatura de las variables

Sobre las convenciones de nombres

He leído bastante sobre este tema. En lo referente a C Sharp todo el mundo dice que no hace falta indicar el tipo de las variables en su nombre. Existen excepciones como los interfaces que como sabéis empiezan por I, y algunos otros tipos más, pero mi experiencia me dice que aplique la lógica y actue en consecuencia.

La razón que dan los Gurús por la cual no es necesario tipificar las variables es que los actuales IDE ya se encargan de eso y por lo tanto el código se vuelve estéticamente mas legible, pero yo al aplicar la lógica les preguntaría a tan honorables señores... ¿ y que pasa cuando el código está impreso en papel ?



A día de hoy los papeles no tienen << Intellsense >> o la posibilidad de autocompletar código o mostrar tooltips informativos, así que mientras no sea de esta forma yo etiquetaré las variables como siempre lo he hecho.

Volviendo a la lógica antes mencionada si que es cierto que podemos simplificar la notación que utilizábamos en Foxpro para con C Sharp. Yo la he bautizado Notación CSF.

La Notación CSF (CSharpFox)

Una de las cosas que tenemos que tener muy claras es que no podemos abusar de las variables públicas como lo hacíamos en Fox. Tampoco va a ser necesario ponerle nomenclatura a todos los tipos de C Sharp, ya que son más que en Fox y además del tipo de variable, también deberíamos indicar el ámbito de actuación de la misma ( Lo que en Fox era publica, local, etc. )


Donde no pondremos notación...

  • En las variables públicas, puesto que serán pocas y además sabremos de un vistazo que son públicas ya que empiezan con el nombre de la clase Prg.
         Prg.TestMode = true;
  • En las variables de las clases estáticas que podamos crear ni en el nombre de las mismas, ya que serán muy utilizadas y aquí si que se necesita cierta estética en código... osea que en este caso estoy deacuerdo con los Gurús.
          static class Prg { }
  • En las variables de ámbito público de las clases instanciables.
  • En los nombre de los enumeradores.
  • En los nombre de las estructuras.
  • En los nombre de los delegados.

Donde pondremos notación y cual...

  • Utilizaremos siempre la notación Pascal (primer carácter de todas las palabras se escribe en Mayúsculas  menos en aquellas variables donde indiquemos el tipo al principio, aquí utilizaremos la notación Camell (Primera palabra en minúsculas siguientes en Mayúsculas).
  • No utilizar nunca el carácter _ en cualquier definición de C sharp (Varialbes, clases, etc.).  
  • Los nombres de todas las clases que creemos, menos las estáticas, empezarán con T mayúscula, esto lo heredamos de Delphi y nos sirve para diferenciarlas de sus objetos. No he utilizado la c, ya que me la reservo para los string. Ejemplo: TConfig
  • Al igual que en Fox todas las variable de objeto que creemos empezarán por la o minúscula: oConfig
  • Los tipos Buildstring, string y char empezarán con una c (ce) minúscula de caracteres al igual que en fox.
  • Los tipos int, decimal, double, float, long, short, uint, ulong, ushort, byte, sbyte empezarán con n (ene) minúscula. 
  • Los tipos bool con la l (ele) minúscula de logic, esto para las variables locales ( de clase o método) para las globales (las de la clase Prg. utilizaremos la palabra Is por ejemplo IsDemo.
  • Los tipos datetime con una d (de) minúscula).
  • En la definición de objetos gráficos utilizaremos 3 letras minúsculas y luego empezaremos por mayúsculas. Estas 3 letras pueden ser las típicas utilizadas en fox o las que crea automáticamente el C sharp, para mi es indiferente. Ejemplo: lblNombre, btnSalir, etc.
  • las variables de clase privadas podremos una p por ejemplo: pnEstado (Esta es privada y númerica).
Así de simple, ni más ni menos. Por otra parte me gustaría aprovechar este artículo para aclarar un concepto importante que suele llevar a confusión a los programadores de Foxpro.

En las clases de Foxpro las variables de las mismas las llamamos propiedades. En Foxpro 9 hay dos tipos de propiedades. Uno las que se comportan como simples variables (osea que se tiene acceso a ellas directamente)  y dos las que se les puede asignar los métodos Access y Assign.

En C Sharp las propiedades de una clase que se comportan como simples variables (osea que se tiene acceso a ellas directamente) se les llama CAMPOS y las propiedades con el método Access y Assign se les llama PROPIEDADES, con la diferencia de que los métodos Access y Assign se llaman get y set.

NEWS [ Aplicaciones estilo Metro ]

Crear aplicaciones al estilo Metro de Windows 8 con C#


Visual Studio es un eficaz entorno de desarrollo integrado (IDE) para desarrollar aplicaciones de Windows. Proporciona administración de los archivos de origen; compatibilidad integrada de creación, implementación y lanzamiento; XAML, Visual Basic, C#, C++, gráficos, edición de manifiestos y depuración, entre otras muchas cosas. Visual Studio tiene varias ediciones; usaremos Visual Studio Express 2012 for Windows 8. Puedes descargarla sin coste alguno junto con el kit de desarrollo de software de Windows (Windows SDK) para Windows 8; de este modo, dispondrás de todo lo necesario para crear, empaquetar e implementar aplicaciones estilo Metro.

Visual Studio Express 2012 for Windows 8 incluye varias plantillas de proyectos Tienda Windows que ofrecen algunos diseños para ayudarte a comenzar con las aplicaciones. La plantilla de proyecto Aplicación vacía (XAML) proporciona los archivos mínimos que necesitas para todas las aplicaciones estilo Metro.

WinForms también permite crear aplicaciones del estilo de Metro, a fin de cuentas no es ni más ni menos que incorporar al Form todos los objetos ( Botones, campos, etc.) con el estilo visual puesto en Flat.

Una de las más interesantes proposiciones de las aplicaciones Metro, es su sencillez, sus 2 dimensiones, los textos blancos en contrate con otros colores, etc. Todo ello hace que el proceso de redibujar o redimensionar  un formulario sea mucho más rápido que en otros estilos gráficos.