Code smells
Artículo a leer. Aquello que hace que nuestros códigos apesten. En codinghorror
« Abril 2006 | Inicio | Junio 2006 »
Artículo a leer. Aquello que hace que nuestros códigos apesten. En codinghorror
Actualización del entorno de desarrollo para Mac OS X por excelencia. Aparentemente la nueva versión sólo incluye bugfixes y soporte para DWARF, pero Apple recomienda la actualización a todos los usuarios.
Pues nada, a bajar 915 MB. Por cierto, más info y descarga en developer.apple.com
Listado de frameworks php para facilitar el trabajo de los desarrolladores. Surgidos con el boom de ruby on rails y su "agile development", es de suponer que liberarán al programador de las tareas más tediosas, permitiéndole centrarse en lo realmente importante.
Puestos a documentar, documentemos todo, incluidas las clases de ActionScript 2.
Al trabajar y crear clases, intuitivamente voy documentando las mismas en estilo JavaDoc. Ahora bien, cuando el número de paquetes, clases e interfaces, es numeroso, interesa tener toda esta documentación a mano. Interesa generar toda esa documentación que está en formato comentario, como HTML.
Y a partir de esta necesidad, surge el estudio de varias herramientas de generación
Antes de nada, indicar que no se ha tratado de un estudio exhaustivo, sino de una búsqueda más o menos rápida de una herramienta que sirva. Las herramientas estudiadas han sido:
Pese a esta "limitación" ( entrecomillado porque en realidad no es tal ), ha sido la herramienta escogida por su rapidez, comodidad de uso y resultados obtenidos.
Uno de los problemas que surgen cuando más de una persona trabaja en un proyecto, es el de la documentación. Sobre todo, si esta, o los briefings previos al proyecto, están sujetos a cambios constantes. Es frecuente entonces, que se produzcan situaciones como duplicidades de documentos, etc…
Cuando uno piensa en documentación, en documentación de proyectos, en listas de tareas a realizar etc… uno piensa en “centralizar”. Esto es, una documentación única, a la que todo el mundo tenga acceso y pueda modificar ( o al menos los implicados en el proyecto ), fácil de actualizar y de consultar. Que no de lugar a duplicidades de ficheros, ni a ficheros ( word, por ejemplo ) con nombres del tipo “documentación_v01” o “documentación_11_2_06 ) etc…
Con esto en mente, parece evidente que la mejor forma de llevar una documentación actualizada y actualizable es un wiki. Un “repositorio central de conocimientos”, accesible por todos vía la intranet, fácil por tanto de consultar, siempre actualizado en una misma url no importa cuantos cambios ( y realizados por quien ) haya, y fácil de modificar. Con las características habituales de un wiki, haciendo hincapié en un control de versiones, bloqueo mientras otro usuario edita, etc…
Decidida pues, la forma de documentar, toca la hora de decidir la herramienta. Cuando uno piensa en wiki, lo primero que le viene a la cabeza es MediaWiki , el wiki en el que está soportada la wikipedia
Sin embargo, y tras mirar y comparar ( no de un modo extremadamente exhaustivo, pero sí con ciertas pruebas, y buscando información, leyendo artículos etc.. ), la decisión fue por DokuWiki.
DokuWiki es un wiki sencillo de utilizar, pero con una serie interesante de características. Las que más nos gustaron son:
Para más información sobre DokuWiki, podéis acudir a la página del proyecto. También podéis acudir a alguna de las revisiones que hizo Juanjo Navarro cuando estudiaba qué wiki instalar en planeta código
instalar un wiki, mas sobre dokuwiki, Traducción de la sintaxis del wiki al castellano
Damien Katz resume en diez puntos lo que considera son las características que definen a un mal programador, que además, no sabe que lo es.
Personalmente, estoy de acuerdo con algunas de sus afirmaciones, aunque con otras no tanto (cada vez que veo una función con varios puntos de retorno me dan ganas de asesinar a alguien), como supongo que era de esperar.
La idea subyacente que yo extraigo de ese artículo es que hay que ser sumamente crítico con el código propio. Y si se decide que se quiere tirar por un camino no muy acorde con los corsés de las "best practices", y se es consciente de que se está haciendo algo no muy "canónico", pero se decide hacerlo tras considerar las condiciones de contorno, adelante con ello.
En el fondo, supongo,como pasa con tantas otras cosas, se trata de tener el sentido común suficiente para saber cuándo hay que pasarse las normas por el arco del triunfo. Algo que no es fácil, desde luego, pero que muchas veces es necesario.
Safari, a partir de la versión 1.3 incluye varias herramientas de debugeo que por defecto están desactivadas.
Para activarlas, según indica la documentación de Apple, hay que abrir sesión en el Terminal, y escribir:
defaults write com.apple.Safari IncludeDebugMenu 1
Tras reiniciar Safari, aparece un nuevo menú, a la derecha del de Ayuda, llamado Debug, que incluye, entre otros, una consola de Javascript o un inspector del DOM.
Yo nunca he sido capaz de manejar vi, aunque reconozco que barrunto que es algo bastante potente.
De todas formas, para los usuarios del editor, aquí va una chuletilla con los tropecientos mil, llamémosles, atajos de teclado.
:q! ;)
Editado. El link directo no funciona, imagino que porque en tucows validarán el refereer o algo así, pero si se copia la url y se pega en una ventana o pestaña nueva del navegador, sí funciona bien
En developerWorks, fuente de muchos y muy buenos artículos sobre bastantes aspectos del desarrollo de software, abren la caja de Pandora, y sueltan una explicación razonada sobre las ventajas e inconvenientes de la utilización masiva de html dinámico.
Una buena ayuda para intentar separar el hype de la realidad, sobre todo para quien se acerque a la tecnología por primera vez.
Libro de lectura obligatoria, cierto, pero no voy a hablar de él en concreto, sino que voy a permitirme recomendar la lectura de una divertidísima anécdota de Marc Hedlund que tiene bastante relación con el tema del libro.
Muy divertida, de verdad.
Adobe lanza, en versión prerelease, un framework para desarrollar clientes web basados en html dinámico, pensado sobre todo para usuarios con conocimientos básicos de html, css y javascript, de forma que la integración de dicho framework sea lo más sencilla posible.
Los ejemplos que acompañan al lanzamiento son significativos, y permiten apreciar claramente que el nivel de funcionalidad conseguido es bastante alto.
Para más información, y descargas del framework y de documentación, se puede acudir a Adobe Labs.
Una de las obsesiones de por aquí es conseguir terminar ganándonos la vida honradamente desarrollando y vendiendo nuestra propia colección de aplicaciones.
El ganarse la vida como desarrollador independiente tiene infinidad de atractivos, eso es innegable, pero también una serie de obligaciones que no tiene el trabajo por cuenta ajena. Una de esas obligaciones, en realidad la que probablemente sea la más importante de todas es la de dar soporte a los usuarios de tus aplicaciones.
Es evidente que todas las personas somos diferentes, más aún si cabe cuando estamos utilizando un programa determinado. Es difícil encontrar dos usuarios que ejecuten la misma tarea de la misma forma, y es más difícil aún encontrar dos usuarios que tengan opiniones similares sobre qué es lo que verdaderamente necesita una aplicación para que sea la mejor del mundo.
Por eso, es crítico saber qué solicitudes de mejoras hay que atender, a qué tipos de usuarios hay que proporcionar todo aquello que pidan, y a quién no hay que hacer ni caso.
En Creating Passionate Users tocan el tema con bastante profundidad, aportan una lista de tipos de solicitantes de funcionalidades, y aconsejan a cuáles de esos tipos escuchar.
Ya hace tiempo que se especulaba con la posibilidad de la inclusión de un recolector de basura para las aplicaciones Cocoa en Mac OS X 10.5, pero estos últimos días ha vuelto a hablarse bastante sobre el asunto.
Una de las ventajas, y a la vez, uno de los inconvenientes de Objective-C es que el manejo de memoria debe hacerse "a mano". No hay recolector de basura, por lo que es responsabilidad del programador liberar los recursos que haya inicializado, cunado ya no sean necesarios.
Esa forma de manejar la memoria supone una ventaja inmediata: no hay cuellos de botella en la performance de la aplicación por culpa del recolector de basura. Además, se mejora el control del programador sobre la aplicación y se minimiza el uso de recursos.
Sin embargo, el tener que manejar la memoria a mano trae consigo dos complicaciones. Por un lado, el tener que eliminar de memoria las referencias a mano hace que sea más sencillo (al menos en mi caso, extremadamente sencillo) el dejar leaks de memoria, puntos en los que el uso de memoria de la aplicación va creciendo ya que no se eliminan, por error del programador, estructuras de datos, por ejemplo.
Pero además, para el que llegue a Cocoa desde Java o desde cualquier otro de los lenguajes que sí gestionan memoria, el tener que preocuparse de retener y liberar objetos es probablemente lo que más duro se le va a hacer en su aprendizaje del lenguaje.
Resumiendo: que el manejo automático de memoria puede ser una ventaja para el programador, sobre todo para el que no llegue a Cocoa desde el mundo de C++. Veremos si al final termina por implementarse o no
Hace tiempo ya reseñamos el poster de patrones de diseño de la gente de Head First. Ahora, via The Farm, nos hemos encontrado con estos otros posters. Por ahora, son doce patrones.
Hay cierta tendencia en algunas comunidades de desarrolladores a considerar que el programador más brillante es aquel que mejor conoce la api de su lenguaje de elección. Se muestra respeto, incluso cierta veneración, por aquél que es capaz de recitar de carrerilla la cadena de herencia de un componente de interfaz de usuario, siendo ese respeto y admiración directamente proporcionales a la profundidad de esa cadena de herencia.
Pero tener buena memoria no tiene porqué significar lo mismo que ser competente. En realidad el aprendizaje compulsivo de una api puede ser un recurso para esconder ciertas carencias.
No digo con esto, evidentemente, que no haya que tener cierto conocimiento de qué se puede y quéno se puede hacer con la api del lenguaje. Pero ese conocimiento debe estar orientado sobre todo a evitar el reinventar la rueda, el implementar cosas que ya están implementadas.
Programar es una actividad creativa. Requiere de una creatividad distinta a la que necesita un diseñador cuando está frente a un documento de Freehand recién creado, pero no por ello deja de precisar de altas dosis de imaginación, abstracción, intuición, aprovechamiento de las propias experiencias, capacidad de improvisación y de cambiar y adaptar sobre la marcha la idea inicial.
¿Qué es preferible, por tanto, trabajar en la fijación en la memoria de una lista de funciones que va a cambiar, que va a ser modificada, ampliada por un extremo y reducida por el otro en la próxima revisión del lenguaje, o intentar mejorar la intuición, la capacidad de abstracción, el lado creativo en definitiva?. Porque, si hay algo seguro en este mundo, es que la api va a cambiar. Las librerías de la primera versión pública de Java (Java 1.02) eran alrededor de 200 clases. Hoy, sólo en J2SE hay unas 3500. ¿Qué inversión es más rentable a largo plazo, la memorización de esas librerías, o la interiorización de aquello para lo que se pueden utilizar, de forma que se pueda volver a ellas como referencia cuando sea necesario concretar una solución?
Porque el manual siempre va a estar ahí, encima de la mesa, dispuesto a echar una mano cuando se le pida. El problema es que el manual que va a estar ahí mañana no tiene porqué ser el mismo que está hoy. Entre otras cosas porque el lenguaje en el que tenemos que trabajar puede cambiar. ¿O es que a nadie le ha caído nunca un proyecto encima en un lenguaje del que no tenía ni idea?
Además, si sólo se mira al manual, si sólo se saben atacar los problemas del día a día a base de academicismo se cae en el peor de los riesgos que puede asumir un programador: el anquilosamiento, la muerte de la imaginación, la muerte de la capacidad para buscar soluciones alternativas. Cuando todo se basa en seguir los procedimientos, en atenerse a una forma estricta y encorsetada de hacer las cosas, se pierde la capacidad de buscar soluciones alternativas, que antes o después, van a ser necesarias.
Y si algo se necesita, a día de hoy, con la complejidad del software que construimos, es la capacidad de respuesta, de implementar soluciones imaginativas, de pensar sin restricciones, sin corsés. No es fácil, no...
