4 bits blog

Ya os he hablado alguna vez de los cursos que dan los miembros del GUL de mi antigua universidad de vez en cuando.

Resulta que este año van a montar por primera vez cursos de verano, llamados Summer Camp, por ahora sólo hay dos días programados:

• 30 de Julio: Python (15.00) y C (17.30).
• 31 de Julio: Apache (15.00) y Taller de seguridad (17.30).

Aunque la mayor novedad es que voy a realizar una pequeña colaboración con mi compañero de trabajo en el taller de seguridad, ayudándole con la información sobre desbordamientos y defensas para éstos.

Si queréis saber algo más sobre cualquiera de esos temas pasaros por allí.

PD: Cuando tenga las transparencias de la charla de seguridad a lo mejor las enlazo por aquí.

Una de las cosas que hacen grande al IDE Eclipse (que recientemente ha estrenado versión, la 3.4) es la cantidad de plugins que uno encuentra para casi cualquier cosa. Uno de esos tipos de plugin, de los más útiles, son los de herramientas de revisión de código. Si nunca habéis usado uno y tenéis la moral baja, no los uséis ahora; la primera vez siempre sonroja un tanto. En mi caso, he utilizado 3 hasta la salida del nuevo Eclipse. La mayor parte de lo que viene a continuación lo encontré después de aquel post Plugins de Eclipse, así que vamos con ellos:

FindBugs

Éste estaba en la lista anterior. Es un analizador de código bastante eficiente en lo suyo (bugs potenciales y algunas malas prácticas de programación) marcando todo lo que encuentre en 3 niveles de gravedad. Personalmente es mi favorito, sobre todo para empezar, pues no me resulta tan paranoico como los demás y puedes corregir casi todo lo que marca.

PMD

Más completo que el anterior (mucho más), además de todo lo anterior, también comprueba la complejidad o longitud del código. Pero resulta un paranoico que ofrece pocas soluciones reales. Por ejemplo, te dice que una variable se puede declarar como final y cuando la declaras te dice que no, que no se deben declarar variables finales, que uses campos. ¿¿¿¡¡En qué quedamos!!???

A su favor tiene que es mucho más completo y que también permite buscar código duplicado (malditos copypastes).

Enerjy

Me enteré de este plugin a través de JavaHispano, debido a su reciente gratuidad. Es similar al PMD, tiene algunas reglas más paranoicas todavía (uso de tabulador en lugar de espacios) y tiene la grave, gravísima desventaja de que no se ejecuta bajo demanda. Aunque puedes marcar qué proyectos excluir del análisis, me parece un tanto inviable en workspaces con muchos proyectos. Una ventaja que le encuentro es que te cambia automáticamente los bucles for de Java 1.4 por los de Java 5 (donde es posible, claro), aunque tampoco estaría mal que lo hiciera sólo si estás trabajando con Java 5 ó superior :-/

Fin

Esta última fiebre revisionista me dio tras leer Revisiones de código automatizadas con Eclipse, donde se habla más extensamente de los 2 primeros y también del CheckStyle. Éste último lo instalé, me empezó a señalar que las variables no cumplían con el estándar de nombrado y, con la misma, lo envié al limbo. Paranoias vale, pero las justas; una variable boolean que no se llame sexo no es seria ;)

¿Habéis utilizado alguno de estos plugins? ¿Quizá otro que desconozca? ¿Qué ventajas y desventajas veis a estas herramientas?

¿Tienes tiempo de sobra y no sabes qué hacer con él? ¿Las vacaciones o las no vacaciones te agobian y querrías distraerte un rato? ¿Tienes un alma caritativa, pero no sabes por dónde empezar? ¿Te gustaría ayudar en algo de lo que usas habitualmente?

Si respondes sí a alguna de estas preguntas, es que quieres colaborar y no sabes por dónde empezar, pues desde aquí te lo voy a poner fácil, te voy a dar unos cuantos sitios dónde podrías comenzar a ayudar en proyectos libres de formas variadas.

El burro delante para que no se espante, 4 bits

Si estás suscrito al feed, o has llegado aquí de cualquier otro modo, verás que este blog no tiene mucho contenido, siendo sinceros este blog está un poco abandonado. Los autores (Lek y yo) no tenemos mucho tiempo, ganas, ideas, … vamos no tenemos de nada, y vemos como nuestra idea inicial se va por el desagüe.

Así que desde aquí si te gusta la programación y la informática, y quieres colaborar, eres bien recibido. De hecho ni siquiera hace falta que escribas en el blog, puedes apuntarte al grupo de Google de 4 bits, y allí preguntar, hablar, discutir, proponer, ¡lo que quieras!

Grupos de usuarios

Que te gustaría colaborar en algo más grande, normalmente a nivel provincial o autonómico, hay gente que se une y forma grupos de usuarios de cualquier cosa (Mac, Linux, Windows, ….) así dependiendo de lo que uses podrás unirte a uno de ellos y conocer a gente interesada en temas similares a los tuyos.

Yo te propongo el GUL de mi universidad, en el cual hay mucha gente y necesitan ayuda en muchas cosas. Para que te hagas una idea, ahora mismo alojan el mirror de Debian en españa.

Leer el resto »

Uno de los problemas a los que nos enfrentamos los programadores es a la continua evolución de nuestro sector. Lo que hoy es la tecnología más puntero, la caña de España y cool hasta las trancas… mañana será una suerte de recordatorio de lo malos que éramos. Sí, he dicho malos. Hay 2 factores, creo yo, para que ver nuestro código de hace +2 años nos produzca un cierto sonrojo: La natural transformación de nuestra algoritmia particular producida por la experiencia, pero también el factor externo de las nuevas herramientas que van surgiendo.

Si funciona no lo toques, es sin lugar a dudas una de las frases más conocidas… y una de las causantes de que problemas irrisorios se conviertan en auténticos tumores terminales. Ante un cambio brusco en la tecnología (como el cambio de Java 1.4 a 5), los programadores nos vemos obligados muchas veces a desdoblarnos, a mantener distintas versiones de un mismo programa sin poder unificar. O, lo que es peor, a quedarnos anclados en una tecnología muerta (Cobol sigue siendo hoy en día uno de los lenguajes con mayor futuro profesional).

Debido a una serie de cambios en la empresa, Bellz se ha pasado unos meses lidiando con un proyecto que en su día me tocó en gracia. Corría el año 2004 y lo que entonces era una solución aceptable ahora se presentaba como claramente insuficiente. Entonces lo que estaba de moda en nuestra empresa era Zeus para gestionar los XML. Hoy apesta; hoy habríamos usado JaxB, que todavía no huele mal. La cosa es que el programa, que funcionaba perfectamente cuando se terminó, se mostraba obsoleto sin que nadie se decidiera a meterle mano. Y cuando Bellz tuvo que modificarlo… explotó.

Otro ejemplo. En su día, allá por los albores de este siglo, se optó por utlizar la librería HTTPClient para las comunicaciones HTTP(s). Los problemas empezaron a llegar cuando salió la JVM 1.5 y resultó ser incompatible con la librería de marras. Nadie se preocupó de mirar los proyectos y revisarlos para evitar problemas. Si quieres revisar estos proyectos, o arreglarlos para hacer que funcionen en un cliente, tendrá que ser bajo tu cuenta y riesgo.

Pero imagino que vosotros tengáis también ejemplos parecidos. Programas basura, obsoletos, con los fuentes perdidos, hechos a medias (la mitad de un padre y la otra mitad del becario)… contadnos vuestra particular galería de los horrores.