bitácora de uno

He estado buscando un rato una herramienta que analizara el código C++ y Java de Osmius. Haberlas haylas pero son privativas y me ha extrañado lo poco que hay en software abierto.
Así es como he llegado a CCCC con el poco afortunado nombre de “C and C++ Code Counter”.

CCCC hace bastante más que contar las líneas de código y los comentarios. Se basa en la tesis de Tim Littlefair que pretende establecer relaciones entre:

• líneas de código
• líneas de comentarios
• cantidad de sentencias de control (if, while, for,..)
• flujos de llamadas y de información entre los módulos y ficheros
• y la cantidad de relaciones de herencia entre las clases

y

• la complejidad del proyecto y su impacto el rendimiento y en la facilidad de desarrollo y mantenimiento.

En su tesis no consigue llegar a conclusiones principalmemente por la falta de datos reales (como suele ocurrir en muchos trabajos académicos), pero maneja conceptos interesantes - un poco por lo menos - como “McCabe’s Cyclomatic Complexity“.

Es verdad que con un solo proyecto sacas algunas pocas conclusiones, pero si cada proyecto publicara el resultado de estos análisis podríamos compararalos entre sí y ver si realmente correlacionan con su uso, el lenguaje utilizado, o la utilización o no de frameworks. Otra utilidad sería comparar un mismo proyecto a lo largo del tiempo.

La salida de CCCC contra los ficheros C++ del proyecto Osmius.

En Java todavía no lo he probado.

En la web de Google Code podemos encontar una apartado que han llamado Google Code University y en el que bajo licencia Creative Commons hay meterial que podemos usar para aprender, y enseñar si se da el caso, sobre:

• Programación AJAX.
• Sistemas Distribuidos. Clusters.
• Seguridad en la Web y cómo romperla.
• Lenguajes: C++, Java y Python.

Además en la sección “Tools” hay una Introducción a las bases de datos y a MySql y otro sobre los Sistemas de Control de Versiones con buena pinta para comenzar en estos asuntos.

Navegando por ahí encontrarás material escrito y vídeos interesantes.

Vía | Code Project

Hoy he leído por ahí un artículo en que se planteaban qué es lo que hace falta para ser el mejor programador del mundo.

Pues yo lo veo claro:

¡Hace falta ser imbécil!

Otra cosa es para ser un buen programador o programadora. Otra cosa.

En el Computer Science Club podemos ver un video de una presentación de Bjarne Stroustrup sobre los principios sobre los que se está diseñando C++0x que viene a ser la evolución de C++.

A good programming language is far more than a simple collection of features. My ideal is to provide a set of facilities that smoothly work together to support design and programming styles of a generality beyond my imagination

El buen programador no es aquel que sabe más lenguajes de programación, sino el que maneja bien los conceptos sobre los que se apoya cualquiera de ellos y sabe cuál es más ventajoso para cada tarea. Luego llegará el momento de traducir a la implementación concreta del lenguaje en concreto que elijamos, pero creo que es más importante codificar claro y saber reusar y diseñar y además me parece más divertido.

A mi me gusta C++ pero eso es un accidente como el haber nacido en un país determinado: empecé con C y he trabajado bastante con C++, pero podría haber sido con Java. Me parecen estériles las discusiones sobre si es mejor uno u otro. Es como los equipos de Tigres y Leones (”todos quieren ser los campeones”) de Torrebruno que tanto daño han hecho.

El enlace original.

Escribir aplicaciones que funcionen en Web es un infierno. Nosotros por ejemplo en el proyecto Osmius hemos hecho la consola utilizando Java y los desarrolladores pasan bastante tiempo lidiando con problemas de compatibilidad entre navegadores. En uno de ellos se ve bien y en otro es un desastre. “Hay que poner una tabla y en la primera celda meter una imagen de un pixel para que se vea bien en IE” ¡¡¿¿Que??!!

Cuando me lo cuentan me indigno. ¿Cómo puede ser que a estas alturas sea tan difícil diseñar ventanas guapas y bonitas sin problemas de compatibilidad? Lo que quiero yo cuando desarrollo aplicaciones GUI es diseñar rápido e ir al grano. Joder, es que hecho de menos el Visual Basic, si, si.

Gran parte del problema es el que apunta Ismael Olea (el video de la conferencia dura una hora o así, pero con unas pipas o palomitas ni te das cuenta y merece la pena): Nos vemos obligados a cambiar de tecnología de desarrollo cada dos por tres, y así no hay manera de contar con herramientas estables. Te imaginas que los mecánicos o los arquitectos renovaran su tecnología cada tres años… pues eso un desastre.

La gente de Adobe parece que está atacando el problema de facilitar el diseño y la ejecución de aplicaciones Web mediante Apollo, que ahora pasan a llamar AIR.

También ha metido SQLite en AIR como Google con su Google Gears, para poder trabajar sin conexión y que se sincronicen los datos cuando la tengas. No sé si en un mundo hiperconectado como se prevee es tan importante esto de tecnologías para cuando no estés conectado.

¿Merecerá la pena empaparse de esta tecnología? ¿Alguno/a lo habéis usado? ¿En cuanto tiempo será obsoleta? No sé si ir a GTK o QT y dejarme de historias….

Leo en ComputerWorld este artículo sobre conocimientos que en tu currículo no aportan nada o - siempre según ellos - te pueden hasta quitar puntos.

Creo que si lo que sabes es de tarjetas perforadas y no se ve una evolución en tu carrera profesional, osea te quedaste en hacer los agujeros en los cartones, lo que te descarta no son tus conocimientos sino tu actitud. En el otro extremo estaría alguien que siempre está en la moda del momento y se vería obligado a cambiar de C++ a Java, a .NET, a Php, a Ruby on Rails y a Flex, con pocas probabilidades de dominar una técnica de verdad.

Tambien pienso que lo suyo en los proyectos software es controlar más sobre el modelo de datos, el modelo de procesos, saber tirar sentencias contra bases de datos que no la dejen cuajada y hacer el código limpito, que dominar mucho - mucho una técnica. Vosotros diréis, pero yendo lo anterior por delante vaya la lista traducida del mencionado y referenciado artículo.

• Cobol: Tuvo su momento y su subidón en el 2000.
• Bases de Datos No-Relacionales: Esto es de los 80 y está claro que ahora el tema es Oracle, MySql, SQL-Server, DB2,…
• Redes no IP: Hace no mucho (10 años) no se sabía si ganaría IP o Token-Ring u otra.
• cc:Mail: Sistema de correo de los 80.
• ColdFusion: Lenguaje de programación Web de los 90 comprado luego por Macromedia y luego por Adobe.
• Programación en C: Dice el artículo que ha sido sustituido por C++ y C#.
• Power Builder: Este compitió cara a cara con Visual Basic en los 90.
• Ingenieros Certificados en Novell NetWare: LA red es otra cosa hoy.
• Administradores de PC en Red: ¿?
• OS/2: Este Sistema Operativo lo sacaron Microsoft e IBM en 1987. Se veía en bancos.

Dos comentarios:

1. Si controlas algo minoritario pero eres de los pocos, te puede ir muy bien (con sus riesgos). Nicho que lo llaman.
2. Lo de C: Habrá mirado esta gente en qué se hacen los drivers en general. O, el kernel de linux. O los UNIX. O han mirado en Monster o InfoJobs. No sé, pon Clipper antes que C ¿no?

TIOBE Software es una empresa de asesoramiento y seguimiento de la calidad del software.

Además no son tontos y publican un informe anual sobre la popularidad de cada leguaje de programación basado en la disponibilidad de ingenieros de software especializados, cursos e información de compañías de terceros, y consiguen visitas.

Tengamos en cuenta que no nos están hablando del mejor lenguaje de programación (quien quiera perder el tiempo….) o en cuántas líneas de código se han escrito en cada lenguaje.

Sus resultados pueden ser útiles antes de plantearse qué lenguaje aprender o en qué tecnología implementar una idea o un proyecto de software. Se agradece esta ayuda relativa, porque esto del software es muy poco acotable. Para construir un edificio de 30 pisos sabes que te puedes tirar uno año para levantarlo y si tienes no-sé-qué-problemas, seis meses o un año más. Como decía Sergio el otro día en el software no hay tope, no hay certeza. Te puedes pirar dos años o que nunca se haga.

La clasificación según popularidad y con su diferencial respecto a hace un año es:

• 1.- Java : -2,93%
• 2.- C : -2,75%
• 3.- C++ : -0,18%
• 4.- Php : -2,24%
• 5.- VBasic : -1,83%
• 6.- Perl : +0,19%
• 7.- Python: +1,05%

El enlace a los resultados lo tenéis aquí.
Esto me ha llegado vía…. Barrapunto.

En la revista de este mes de Linux+DVD viene el primer artículo de una serie de dos (por poco) sobre ACE y cómo empezar a usarlo.

También se describe Make Project Creator (MPC), herramienta que os recomiendo para generar Makefiles para combinaciones de sistema operativo y compilador a partir de un solo fichero fuente. Se trata de escribir los programas una sola vez y que podamos compilarlos y ejecutarlos en sistemas operativos diferentes sin esfuerzo por nuestra parte. Otra vez la reutilización.

La propuesta de la gente de Linux+ es: “Escríbeme un artículo y te lo pago en forma de suscripción a la revista o con publicidad sobre su empresa o tu producto”. Nosotros la hemos aceptado pero creo que el mayor beneficio es el de ponerse a escribir aunque sea un sólo artículo. Escribir es una manera de pararse a pensar, ordenar las ideas y organizarlas para que sea otro el que pueda entenderlas. Es un ejercicio interesante.

Ayer presentamos Osmius 1.0.

Nos queda mucho. Viendo la botella medio vacía significa que hay curro a saco y que necesitamos mantener la ilusión, proporcionada financiación y adecuado trabajo, todo manteniendo a raya las dudas e inseguridades. Viendo la botella medio llena vemos que Osmius tiene un enorme potencial y que al menos potencialmente sirve para casi todo.

Podemos monitorizar el valor de tus acciones en bolsa y avisarte con un SMS si baja o suben de tanto, o si tu lavadora peta, o si tus sistemas se caen o si…. Eso está claro tanto o más que hay que trabajar y trabajar bien. De igual forma que Chico, Edu y Cabe lo han hecho creando las bases de una consola Java que es la pera.

Que tiemblen esta empresillas tipo Oracle, HP o IBM que vamos a por todas. La idea es buena y la gente también, y los egoísmos están claros y son a medio plazo… temblad, temblad.

Mientras haya risas…

Cómo le explico yo a un amigo, a mi madre, lo que hago cuando desarollo software de manera que me entienda y no desconecte la atención al primer tecnicismo. Siempre he creido que por duro, elevado o elitista que sea tu trabajo, debes ser capaz de explicarlo de forma que lo entienda alguien alejado de tu campo profesional. En ocasiones lo he creido un deber por aquello de la difusión del conocimiento. Debía ser deformación científica, pero esencialmente estoy de acuerdo con mi yo de hace unos años, así que al tema:

Respecto al software, la idea de cómo explicarlo creo que la saqué del libro “El hacker y las hormigas 2.0″.

Cuando uno hace software para un equipo de “sí mismo” o “sí mismo más uno o dos” , la cosa puede complicarse, pero si desarrollas software en esos equipos de ochenta personas el infierno es una caca comparado con tu situación profesional. Y si aparecen gurús de “la encumbración de la obviedad”, de ese tipo que piensa que el carisma se transmite, entonces, querido lector, sí que estás jodido.

Pero yendo al asunto de cómo explicarle a alguien lo que hago actualmente como desarrollador de Osmius creo que la idea es la siguiente:

Imagínate que estás construyendo un edificio de tres metros de altura con palillos y pegamento. Primero pienso - sin tener claro del todo - la estructura inicial del edificio de cara a una funcionalidad que debe cumplir para cierta gente a quienes llamamos usuarios. Lo siguiente sería cómo empezar a levantarlo sin nunca tener la visión global - en software no ves tu monstruo-programa excepto en momentos específicos poco transmisibles tipo epifanía o iluminación puntual.

Es algo así como ver lo que haces a través de un cucurucho amarrado a tu cara, de forma que sólo ves la superficie de una moneda de un euro, dejando a la imaginación el resto. Tú vas poniendo palillo tras palillo (línea tras líneas, clase tras clase, método tras método, patrón tras patrón,…) pero no tienes del todo claro qué es lo que estás construyendo de forma exacta incluso suponiendo unos requisitos certeros.

En tu cabeza “cabe” una imagen simplificada de lo que haces. Los detalles de todo llega un momento en el que no puedes aprehenderlos. Y si hay treinta como tú - cada uno con su cucurucho - olvídate de una visión aceptablemente exacta.

La Gestalt en proyectos de software, bajo este punto de vista en mi blog, no chuta.

Llega un día en que tratas de ver si tu edificio de palillos se sostiene y si aguanta para soportar todo por lo que en realidad lo has hecho. Es un reto. Es un reto que muchas veces pierdes. Quitas los soportes y tu edificio de palillos se viene abajo. y todavía no sabes bien el porqué…. pero lo sabrás. Te mola saberlo….

No se si los que desarrolláis software tenéis la misma sensación… pero me gustaría…. sobretodo por compartirla.

Viendo como veo estas cosas, se entenderá por qué no creo demasiado en los equipos de más de cinco o seis personas. Imagínate a seis (tíos y tías) cada uno con su nivel de motivación y con una visión de un centímetro cuadrado, desarrollando un software tipo muralla china.