Ceklog

Del 16 al 18 de diciembre se celebró en Guadalajara la segunda Debconf-es a la que tuve el placer de asistir. Hubo un montón de charlas muy interesantes sobre aspectos específicos de Debian y también sobre otros aspectos más específicos como seguridad, programación, ética, etc.
Yo me llevé la cámara pero al final no hice ninguna foto porque no me gusta cargar con ella, menos mal que hay gente que siempre la lleva encima y tenemos magníficas fotos (todas menos en las que yo salgo :)).

Las conferencias sirvieron para dar un poco de impulso al proyecto, sobre todo al de localización/traducción al Español que es el que más nos interesa para tener todo en Castellano en la próxima versión de gnuLinEx.

Os animo a que veáis los vídeos de las charlas porque son muy interesantes para todos los niveles. A los que estéis interesados en traducir Debian al Castellano os recomiendo la lectura de la Charla de i18n y traducción que se dió ayer a través del IRC

El post se titula «La realidad de un programador» porque ahora la palabra informático es tan amplia que hasta las secretarias que hacen calendarios para el jefe dicen que trabajan de informáticas.
Banalidades aparte, la finalidad de este post es la de recomendaros la lectura de esta noticia publicada en Barrapunto enviada por un “s/informático/programador/”, de lectura imprescindible para cualquier “s/informático/programador/”.

Algunos extractos que me han gustado especialmente son:

Si os tengo que resumir en una palabra el trabajo de programador, esta palabra sería AISLAMIENTO. El trabajo del informático no es un trabajo normal. Es un trabajo muy estresante. Dependes de una maquina la cual puede tener infinitos fallos, que tú debes resolver. Es un trabajo en el que estás solo, repito, solo. Es un trabajo mental que no dura solo las horas de trabajo sino que te lo llevas a casa. El mejor ejemplo que puedo poner de llevarte trabajo a casa es cuando intentas compilar una cosa y el puto compilador te da un error inexplicable que nadie en el mundo sabe lo que significa, esa sensación de impotencia no se la deseo a nadie. No me puedo imaginar un trabajo que pueda provocar esa puta sensación de indefensión frente a la jodida máquina, dan ganas de darle una patada al puto ordenador y mandarlo a tomar por culo. Puedes pasar días con ese puto error (a mi me ha pasado) y nadie en el mundo (ni con internet) sabe lo que pasa, y tu trabajo depende de eso, es desolador, desquiciante, puede acabar con la moral de cualquiera.

Por no hablar del tipo de jefes y de compañeros que te sueles encontrar. El tipo de jefe suele ser el típico “listo” que ha llegado allí por enchufe, no tiene porque se ingeniero en informática ni nada, todo vale, teleco, matemático, físico, químico, abogado, ¿fontanero?, da lo mismo, programar sabe todo el mundo. Por supuesto el piensa que tu titulo de ingeniero no vale nada, pues el está por encima de ti y además sin estudiar. Demostrar a alguien que no sabe de informática lo bueno que eres es imposible. La valía de un informático no suele importar. Lo que importa es que tragues con todo sin rechistar. Los compañeros suelen ser por lo general otros “pringaos” como tu. Suelen ser buenas personas, serios, introvertidos, como no puede ser de otra manera pues las horas frente al ordenador dejan su marca. Tu estás en el mismo saco que ellos, y tenéis los mismos problemas, a excepción de los trepas, que con esos mejor ni hablar. En mi trabajo pasábamos la mitad del tiempo maldiciendo a los trepas y el puto día que decidimos dedicarnos a la informática. Es de los peores trabajos que puedo imaginar. Después está el sueldo que es una puta miseria y que en los últimos años la cosa va a peor. Todo son becarios, contratos de practicas, y si no te gusta pues a la calle, que ya vendrá otro de fp a hacer tu trabajo.

El trabajo mental del informático equivale al trabajo mental que realizan 50 fontaneros, o 200 barrenderos, etc, es decir, la mente del informático es explotada sin piedad y además te pagan cuatro duros.

Un ejemplo, lunes 9 AM, llega mi jefe: “Mira, te tienes que estudiar está bonita API de 500 páginas, creo que una semana podrás, y después me haces un programa en leguaje x2r4 que extraiga la retribución incremental de los registros impares al cuadrado, lo compilas, me haces una librería dinámica, lo documentas todo, y me hace una interfaz de usuario ¿lo has entendido? Ok. Tiene que estar en dos semanas ehh. No te duermas”.

Y yo pienso: “¿Que cojones hago yo aquí aprendiéndome una puta API de los cojones, para hacer un puto programa sin sentido, por cuatro duros y además aguantar que mi jefe se lleve todo el mérito, ¿Qué cojones hago aquí si cualquiera con menos estudios cobra más que yo, y además, en su trabajo, no se tiene que aprender putas APIs, ni gilipolleces que a nadie le importan? En resumen, ¿Qué cojones hago yo aquí?”

Prefiero barrer un suelo a escribir una línea más de código fuente. Por lo menos así la gente sabría cual es mi trabajo y mi mente no estaría inundada de palabras clave sin sentido, de punteros a ninguna parte, de bytes incompletos o de bits desesperados.

Tenemos tanto intrusismo profesional porque nuestro trabajo es una MIERDA y la mierda atrae a las moscas

Después del éxito del anterior post en el que se ofrecía trabajo y con el que se consiguió dar curro a Daniel (no tendrás queja Danielín ;)), me han pedido que ponga otras ofertas de trabajo en la bitácora por si a alguien le interesa. Que conste que yo de esto no percibo ni las cáscaras y que sólo lo hago para hacer un favor a estas empresas y a mis lectores, por supuesto.

En concreto estamos hablando de 3 puestos de Programador Senior para la empresa Opensistemas ubicada en Madrid y uno o dos puestos para la empresa Adaptia ubicada en Cáceres.

Podéis ver el perfil que se está buscando para los 5 puestos en esta dirección de Infojobs. De todas formas enviad vuestro currículum aunque no cumpláis todos los requisitos que es muy posible que se pongan en contacto con vosotros de todos modos para haceros una entrevista. Básicamente se buscan programadores C/C++ y Java bajo entornos *NIX (GNU/Linux sobre todo).

Podéis hacer llegar vuestros currículums por correo para una atención más rápida, en concreto para los puestos de madrid enviadlos a info(en)opensistemas(punto)com y para los de Cáceres enviadlos a alberto(punto)caso(en)adaptia(punto)es, podéis decir que habéis visto la oferta en esta bitácora para romper el hielo

No obstante si preferís mandármelos a mí porque tenéis más confianza o porque os da menos corte yo se los remitiré a los jefes, mis correos son cesar(punto)gomez(en)adaptia(punto)es o cgomez(en)opensistemas(punto)com.

Vía lightme llego hasta la web de Lars Wirzenius que nos explica las verdades sobre la programación y los programadores. Para pasar un buen rato:

This page contains a number of important programming truths that every budding programmer should know about. These truths are self-evident, and need no explanations.

If it compiles, it works.

If it compiles, it’s correct.

If it runs, it doesn’t have any bugs.

If it doesn’t have any immediately obvious bugs, it’s perfect.

If a bug doesn’t show, it doesn’t exist.

If it seems to work, it works.

Doing something right is easy. Avoiding errors only takes a bit of concentration.

The shorter the source code, the faster the program.

It’s obvious how to optimize a program.

Prorammers don’t make mistakes.

Run-time errors don’t occur.

Users don’t make mistakes.

I don’t make mistakes.

Errors of any kind are rare.

Error handling can be done in version 2.

It’s OK to crash on bad input.

It’s OK to give incorrect output on bad input.

Portability isn’t useful.

All the world’s a VAX. Or, these days, an MS-DOS box

The length of the feature list is important.

Speed is good, features are better.

Slowness can be fixed in hardware.

The bigger a program is, the better it is.

Random changes to a program fix bugs.

Testing takes only a short while.

Finding bugs is easy. Fixing bugs is trivial.

Bug-fixes don’t need to be tested.

Trivial changes of any kind don’t need to be tested.

The first approach, idea, or version is always the best.

A 1% crash rate is actually pretty darn good.

Code is self-evident. Comments aren’t needed.

Comments are meant for people other than the original author of the code.

Undocumented features are fun and useful.

It can always be fixed in the next version.

Surprised users are happy users.

Demonstrating for clients is the best debugging method.

Aquí os dejo un interesante manual de Subversion, el sucesor del mítico CVS

Manual Subversion 1.0 cortesía de Currie

Dide se ha dedicado a programar el algoritmo del juego de la vida en C ofuscado, aquí tenéis el resultado:

El código

Algunos lo hemos programado completo en ensamblador

Mi compañero de curro David Currie (¿a que mola la rima? :)) me ha pedido que enlace un post suyo por si hay alguien interesado en trabajar para la empresa OpenSistemas, que es con la que estoy colaborando actualmente.

Por si alguien está interesado reproduzco a continuación la información:

Para los que les interesa trabajar con Linux, C/C++, y con tecnologías Open Source, mi empresa (OpenSistemas) está buscando ahora mismo a gente para varios puestos de desarrollador junior. Los detalles de la oferta están en InfoJobs, y poco más puedo añadir excepto que (en mi opinión) las condiciones pueden ser bastante ventajosas tanto a nivel personal como profesional.

Si no tenéis cuenta en InfoJobs, o preferís hacernos llegar un curriculum por correo, me lo podéis mandar a mi personalmente a dcurrie(at)opensistemas(dot)com o bien a la dirección de la empresa, info(at)opensistemas(dot).com.

Por cierto, solo quiero aclarar que a mi no me pagan por traer a gente, para los que cuestionen mis motivos :).

Enlace al post original

P.D: A mi tampoco me pagan comisión (pero podrían)

Os invito a echar un vistazo al nuevo blog de David Currie, un compañero de trabajo que es un crack

Este es su segundo blog, el primero lo abandonó, pero como dice el refrán castellano: “La cabra siempre tira al monte”.

En el encontraréis cosas de programación, análisis y arquitectura de software y otros temas de interés para los programadores y analistas. El blog está en inglés, que para eso es su lengua materna, pero le achucharemos un poco para que lo traduzca a español y portugués, que para eso es políglota

Parece que la versión 2.0 de mi IDE preferido, Anjuta, para C/C++, va a salir en una o dos semanas con un montón de novedades entre las que destacan:

• *Navegación sobre Devhelp integrada
• *Integración de un diseñador GLADE
• *Task manager
• *Quizás un plugin para Subversion

Y más novedades…

Ya estoy deseando probarlo, aunque de momento no me voy a bajar la versión del CVS por una cuestión de salud “codigal”

Relatos imprescindibles de leer para los programadores, en www.fuckowski.com

Un extracto:

…
El “brainstorming” o “tormenta de cerebros” es (o debería ser) la reunión en la que todos aportan su talento y experiencia para encontrar soluciones óptimas a problemas. La realidad es que en la tormenta de cerebros, el manager suele poner la tormenta y tu tienes que poner el cerebro. Y en la tormenta, como en el río revuelto, la ganancia es para los pescadores. Tu piensas, diseñas y solucionas, que para algo querías ser ingeniero. El se apunta el gol, que para algo hizo un master en “strategy business janderklander”.

Así que uno llega a la sala de reuniones con la mosca detrás de la oreja. Ahí está él, con el portátil, la taza de café, y un montón de papeles (normalmente emails de los clientes con sus requisitos, es decir el problema en sí mismo, y ni un solo folio extra que indique que se ha dedicado algo de tiempo a solucionar nada).

Ya sabes a lo que te expones una vez más. Te van a preguntar el consabido “y ahora que hago” pero sin que se note. De soslayo. Como si tu fueras imbécil. Pero no queda ahí la cosa: vas a ser el conejillo de indias con el que poner a prueba los últimos discursitos aprendidos en los foros o “cookbooks”, para que los valides o rechaces, los corrijas, y en definitiva ayudes a perfilar esa superficial sabiduría, ese “arte de aparentar tener razón” (véase Schopenhauer) con la que estos individuos justifican sus desorbitados salarios ante la directiva (que normalmente no suele saber distinguir una churra de una merina).

Así que te lo tomas como algo personal. Se trata de dejar claro que A) una churra es una churra y una merina es una merina, es decir, una idea es una idea y una gilipollez es una gilipollez, y uno sabe distinguirlas; B) se puede hacer demagogia hablando del sexo de los ángeles o quizás de pintura abstracta, no de software; C) no se aprende en un foro en una hora lo que le ha costado a uno varios añitos de carrera, otros cuantos de trabajo, mucho café y muchas horas extras; D) un inútil con un libro no es un ingeniero; E) Un master, una corbata y una PDA hacen juego, pero no proporcionan sentido común al que carece de él.

Total, que empieza el circo. Abróchense los cinturones. Aférrese uno con fuerza a sus principios, porque le van a aplicar el método Ludovico (véase La Naranja Mecánica). Le van a inmovilizar en una silla, a administrar una droga, a colocar unos soportes en los párpados, y le van a obligar a visionar dos horas de Power Point. Le van a someter a uno a espantosas torturas psicológicas con el doble objetivo de sacarle información, y a la vez convencerle de realidades alternativas.
A continuación reproduzco fragmentos reales (doy mi palabra de honor) de reuniones con mi actual IT manager acerca de varios proyectos Java y VB en los que “hemos” trabajado.

Perla 1: Hibernate
[manager] ¿Qué utilizamos para la capa de datos?
[yo] Usemos Hibernate
[manager] Es mejor usar Entity Beans
[yo] ¿Por qué?
[manager] Entity Beans son J2EE estándar, y además están en un pool, Hibernate no tiene pool así que va mas lento.

Cuando quise explicarle la burrada que había soltado, eran tantas las ideas que se me vinieron a la cabeza de golpe que sufrí un shock y tuve que ir a por un vaso de agua. Creo que esto es una técnica deliberada de argumentación, que debería denominarse “tan gorda es la burrada que no se puede rebatir”. Si alguien dice que “dos y dos son cinco”, se puede argumentar que son cuatro. Pero si alguien dice que “dos y dos son una constelación cercana a Alfa-Centauri”, sólo se puede rebatir “¿pero de qué estás hablando?”, y te pueden replicar “Cómo se nota que no has hecho un Master Janderklander”.
…

Para partirse de risa, jajajaja.

Gracias a Vaijira por el enlace.

Esta mañana me decía un compañero de faenas que era conveniente no usar NULL en C++, y mi curiosidad me llevó a preguntarle el porqué sin una respuesta convincente :).

Me puse a buscar una razón, la encontré y se la dije sin decirle que lo había leído en Internet, jejeje.

The pointer is initialised to 0, and not “NULL”. There is no such thing as “NULL” in C++, so the number 0 is what we have, and use. The reason is, oddly as it may seem, that C++ is much pickier than C about type correctness. Typically in C, “NULL” is defined as “(void*)0.” C++ never allows implicit conversion of a “void*” to any other pointer type, so this definition is not good enough. The integer 0, however, is implicitly convertible to any pointer type.

Como pone aquí, en C, NULL está definido como (void *)0 y C++ nunca permite una conversión implícita de un (void *) a cualquier otro tipo de puntero, por lo que no es bueno del todo usar NULLs cuando se programa en C++. Sin embargo, el entero 0 se puede convertir a cualquier tipo de puntero de forma implícita por lo que es más correcto.

Curiosidades de la vida que uno desconoce y conviene apuntarlas en un weblog

Todos los que programamos o leemos código estamos acostumbrados a leer palabras en el código como TODO o WARNING. Estas palabras son muy útiles para la documentación de nuestros programas y para encontrar puntos en los que debemos poner más atención de lo nomal a la hora de modificar.

Algunas de estas palabras más comunes son:

TODO: Indica cosas que quedan por hacer.
BUG: Da detalles de un bug que está localizado en ese punto.
WARNING: Indica que se ha de tener cuidado a la hora de hacer algo.
COMPILER: Cosas a tener en cuenta para el compilador.
KLUDGE: Indica que una solución no es elegante y que puede ser mejorada, es decir, es una chapuzilla para que la cosa funcione.
TRICKY: Indica que para llegar a la solución se ha utilizado un truco.

¿Alguien sabe alguna palabra reservada de este tipo más?

Hoy vía Más que código he descubierto la bitácora Refactoring en Español que cuenta trucos y consejos sobre la refactorización.

Refactorizar el código es modificarlo mejorándolo pero sin pervertir la funcionalidad del mismo y es una forma muy aconsejable de hacer los programas más eficientes y mantenibles.

Otra bitácora más para mi feedreader.

A través de artERNATIVO llego a esta web en la que podemos encontrar muchos y buenos libros técnicos (casi todos de programación).

Una más para mis bookmarks.

Estos artículos son muy útiles para aquellos que este año comienzan una Ingeniería Informática y no saben como afrontar una práctica en la que deban programar en algún lenguaje de programación. Sin más preámbulos:
- Cómo NO realizar una práctica de programación(Español)
- How NOT to go about a programming assignment (Inglés)

A los que tenéis un poco de experiencia tampoco os vendría mal leerlo

Los punteros a funciones (function pointers) son punteros, es decir, son variables que apuntan a la dirección de una función. Estos punteros son muy interesantes porque proveen técnicas muy elegantes y, sobre todo, eficientes. Se suelen usar para reemplazar sentencias switch/if, para realizar un enlace tardío (late-binding) o para implementar “callbacks”.

Debido a su sintaxis complicada no se trata con mucha profundidad en los libros de programación en C/C++, es por esto que recomiendo encarecidamente la web www.function-pointer.org que lo explica bastante bien.

En mi caso lo necesito para el “late-binding”, tengo que llamar a una función de la que no sé el nombre y no puedo hacerlo con métodos virtuales porque las funciones no son virtuales, por lo tanto no están en la V-Table. Esto implica que no se puede hacer de otra forma que no sea con punteros a funciones.

Espero que el enlace le sirva a alguien, aunque probablemente la parroquia no está muy interesada en programación tan específica, es más probable que este post le sirva más a los visitantes de El Oráculo

Hoy la cosa va de programación concurrente
Mutex es la abreviatura de “mutual exclusion”, es decir, exclusión mútua. Las variables Mutex son la forma más común de implementar la sincronización de threads y de proteger datos compartidos cuando acontecen multitud de escrituras sobre esos datos compartidos.

Una variable mutex actúa como un candado protegiendo los datos o recursos. El concepto básico de mutex en Pthreads es que sólo un thread puede cerrar el candado en un determinado instante. Incluso si varios threads intentan cerrar el mismo candado sólo uno saldrá victorioso. Ningún otro thread podrá poseer ese mutex hasta que el que lo cerró lo abra. Es decir, con esto conseguimos que los threads se turnen para acceder a datos protegidos o compartidos.

Los mutex pueden ser usados para prevenir “condiciones de carrera”. Este es un ejemplo de una “condición de carrera” en una transacción de un banco.

En este ejemplo se debe utilizar un mutex para cerrar el “Balance” mientras un thread está utilizando este recurso compartido.

Muy a menudo la acción llevada a cabo por un thread que posee el mutex es la actualización de variables globales. Esta es la manera más segura de asegurar que los threads que actualizan la misma variable van a arrojar un resultado final igual al que arrojaría un sólo thread que realizara todas las operaciones.

Una típica secuencia en el uso de un mutex es:
1. Crear e inicializar la variable mutex.
2. Varios threads intentan bloquear el mutex.
3. Sólo uno lo hace y es el poseedor del mutex.
4. El poseedor del mutex realiza un conjunto de acciones.
5. El poseedor del mutex desbloquea el mutex.
6. Otro thread toma el mutex y repite el proceso.
7. Finalmente el mutex es destruido.

Cuando varios threads compiten por un mutex, los perdedores se bloquean hasta que el ganador desbloquea el mutex.

Y hasta aquí la lección de hoy

A ver si alguno de los feligreses de esta humilde parroquia tendría a bien recomendarme un buen depurador o debugger para GNU/Linux

Los que vengo usando son los front-ends KDbg y el de Kdevelop para el GNU Debugger, pero no me acaban de convencer. El KDbg me convence un poco más que el interno de Kdevelop, pero ninguno son para tirar cohetes.

Se me olvidaba, es muy importante que soporte multithreading, es decir, varios hilos de ejecución, ya que lo necesito para programar un framework con posix threads.

Gracias

Como sabéis he estado buscando manuales y libros sobre pthreads. En el post anterior mencionaba la dirección de http://techbooksforfree.com/, web en la que se pueden encontrar libros tecnológicos gratis.
El hecho es que he encontrado un libro excelente titulado Advanced Linux Programming, y, por supuesto, trae un capítulo muy interesante que versa sobre los POSIX Threads

Hay veces en las que es un engorro tener que utilizar un editor en modo consola como el Vi o el Emacs, pero hay otras ocasiones en las que no hay más remedio, por ejemplo si necesitamos editar un fichero en un sistema UNIX antiguo o si las X-window no arrancan.

Es por esto por lo que son muy útiles las Quick Reference Cards o Guías rápidas ya que en un par de folios se explica el funcionamiento del programa.

Algunas guías interesantes son:

Vi Quick Reference
GNU Emacs Reference Card
Bashreference

Más Guías Rápidas en esta web.