A través de Barrapunto: en http://www.galiciapms.eu/ que la Consellería de Innovación e Industria ha destinado 100.000 euros al desarrollo de una aplicación para elaborar presupuestos, por parte de Ardinova Consulting S.L. de A Coruña, orientada al sector de la carpintería metálica llamada Orzametal (que es de libre descarga desde GaliciaPMS, o desde la página http://www.orzametal.eu/).
El detalle es que la aplicación en cuestión es un tanto "descafeinada" incluso si su presupuesto fuera una décima parte del que es... la aplicación en cuestión consiste en una serie de formularios montados sobre el framework Symphony (lo que aligera más el trabajo y me hace dudar sobre la afirmación de que sea "100% galega", quizás "10% galega" sería más apropiado). Los formularios apenas dan funcionalidad de añadir, listar y gestionar mínimamente una serie de tablas de una base de datos.
Fuentes:
http://barrapunto.com/
http://www.conselleriaiei.org/ga/web/notic.php?ide=1815&pag=0
http://elprogreso.galiciae.com/nova/25088.html
domingo, 8 de marzo de 2009
lunes, 2 de marzo de 2009
Programadores del siglo XXI
He leído esto (http://blog.ivangadea.com/2009/02/27/management-del-siglo-xx/) que me ha recordado el eterno debate:
Me considero una persona tolerante a las ideas de los demás, pero hay una cosa que nunca he entendido completamente.
En determinadas escuelas de informática se ha instaurado la manía de meter líneas y separar el código de una manera artificiosa... con este me refiero a, por ejemplo, usar doble espaciado en el código y entre bloque y bloque de código poner una separación de 3 líneas y 6 cuando los bloques están en grupos separados. Ya no digo nada de los comentarios, siempre con bloques bonitos de varias líneas de /*** ... *** . . . *** ... ***/
Más allá de que al leer el artículo de management halla encontrado una razón más -que ya sospechaba- para este tipo de comportamiento a la hora de picar código, entiendo que halla gente que lo considere más bonito y claro.
Sin embargo personalmente soy de los que opino que el código, sin pasarse, cuanto más condensado mejor: no es lo mismo tener que analizar un bloque de código que ocupa 3 o más pantallas que uno que se puede ver en su conjunto sin tener que subir y bajar o imprimir en papel todo. Si a esto sumamos que, por suerte, la mayoría de los editores de código tienen resaltado de sintaxis con color, y que existen los comentarios // de final de línea...
Además NO todo el código es igual de complejo: ya sabemos esas zonas que deben estar super-optimizadas porque el 90% la CPU se lo pasará en ellas, o bien esas que tienen la operación más enrebesada. Yo soy firme defensor de la indentación adaptativa... hay zonas del código que en 2 segundos cualquiera reconocería, y otras que podemos estar todo el día sin saber que hacen a ciencia cierta. Lógicamente estas últimas zonas deberían llevar un formateado y unos comentarios mucho más completos y claros que las otras.
Es como quien para optimizar el código optimiza a diestro y siniestro, cuando normalmente basta con aplicar optimizaciones a 3 o 4 zonas claves y/o al flujo lógico del código para lograr un 95% de la posible optimización y el 5% restante ya son chorradas en las que el tiempo invertido apenas tendría resultados reales.
Es un punto de vista, supongo que habrá otros.
Me considero una persona tolerante a las ideas de los demás, pero hay una cosa que nunca he entendido completamente.
En determinadas escuelas de informática se ha instaurado la manía de meter líneas y separar el código de una manera artificiosa... con este me refiero a, por ejemplo, usar doble espaciado en el código y entre bloque y bloque de código poner una separación de 3 líneas y 6 cuando los bloques están en grupos separados. Ya no digo nada de los comentarios, siempre con bloques bonitos de varias líneas de /*** ... *** . . . *** ... ***/
Más allá de que al leer el artículo de management halla encontrado una razón más -que ya sospechaba- para este tipo de comportamiento a la hora de picar código, entiendo que halla gente que lo considere más bonito y claro.
Sin embargo personalmente soy de los que opino que el código, sin pasarse, cuanto más condensado mejor: no es lo mismo tener que analizar un bloque de código que ocupa 3 o más pantallas que uno que se puede ver en su conjunto sin tener que subir y bajar o imprimir en papel todo. Si a esto sumamos que, por suerte, la mayoría de los editores de código tienen resaltado de sintaxis con color, y que existen los comentarios // de final de línea...
Además NO todo el código es igual de complejo: ya sabemos esas zonas que deben estar super-optimizadas porque el 90% la CPU se lo pasará en ellas, o bien esas que tienen la operación más enrebesada. Yo soy firme defensor de la indentación adaptativa... hay zonas del código que en 2 segundos cualquiera reconocería, y otras que podemos estar todo el día sin saber que hacen a ciencia cierta. Lógicamente estas últimas zonas deberían llevar un formateado y unos comentarios mucho más completos y claros que las otras.
Es como quien para optimizar el código optimiza a diestro y siniestro, cuando normalmente basta con aplicar optimizaciones a 3 o 4 zonas claves y/o al flujo lógico del código para lograr un 95% de la posible optimización y el 5% restante ya son chorradas en las que el tiempo invertido apenas tendría resultados reales.
Es un punto de vista, supongo que habrá otros.
Suscribirse a:
Entradas (Atom)