4 bits blog

Hace unos días Ulrich Drepper, principal desarrollador de la GNU libc, ha publicado un documento titulado “Todo lo que un programador debería saber sobre la memoria” (en PDF y en Inglés).

En él, Ulrich explica cómo funcionan todos los mecanismos conocidos de la memoria, la RAM, la cache, los procesadores multinúcleo, … No me he leído el documento, pero por las opiniones de varios sitios parece muy interesante y a tener en cuenta si se va a desarrollar una aplicación en la que necesitemos un buen rendimiento y manejo de la memoria.

(Vía D’Oh!)

En un blog dedicado a la programación no podemos olvidarnos de algunos personajes que han marcado un hito en esta ciencia tan especial. Y un puesto destacado entre este elenco de genios y visionarios lo ocupa una mujer, aunque parezca mentira: Ada Lovelace. Su nombre os sonará de algo, espero, pues en su honor se llamó así al lenguaje Ada. Más espectacular aún es la fecha en que vivió, en ¡¡¡pleno siglo XIX!!!, lo que la conviritió en el primer programador de la historia:

Se la atribuye el desarrollo instrucciones para realizar cálculos en las versiones tempranas del ordenador, pues escribió para Charles Babbage un programa capaz de calcular los números de Bernoulli. Adicionalmente aportó a la informática conceptos como Bucle o subrutina, instrucción, e inventó una notación para describir algoritmos en la maquina analítica de Charles Babbage, creando de esta forma el primer lenguaje de programación

Hija de Lord Byron (sí, el poeta), recibió una fuerte educación en ciencias y matemáticas. Finalmente conoció a Charles Babbage en 1833. Mi tocayo era un visionario que ideó una serie de proto-ordenadores, pero con una base matemática mucho más pobre que Ada. Ada se entendió de un modo especial con la máquina en que trabajaba Babbage, lo que la permitió afinar ciertos aspectos de la misma y realizar varios programas con tarjetas perforadas. La máquina nunca llegó a funcionar, pero este trabajo sirvió posteriormente a otros genios incomprendidos como… Turing.

Lamentablemente, como todas las estrellas que brillan en demasía, su vida se extinguió prematuramente debido a un cáncer a los 36 años (siguiendo la tradición familiar, como su padre).

Referencias

• Wikipedia
• Enciclopedia.us.es
• LaFlecha.net
• ChicasLinux.org

Después de mucho tiempo tenemos por fin el esperado resultado de lo que se venía conociendo como Google Phone, y no es más que un (podríamos decir) sistema operativo para móviles que cuenta con el apoyo de un montón de empresas y que encima ofrece una plataforma de código abierto para el desarrollo de aplicaciones.

Todo esto se ha bautizado como Android, que según parece no es más que el siguiente conjunto de librerías:

• Núcleo Linux.
• Una librería de C (libc).
• freetype
• sqlite
• El motor de renderizado de webs webkit.
• OpenGL
• Un framework para desarrollar aplicaciones en Java.

La verdad es que he visto poco sobre este tema, pero por las pocas imágenes y comentarios que he visto tiene una pinta realmente buena, sobre todo porque los sistemas para móviles actuales dan un poco de pena.

Y para rematar la faena, se ha realizado un concurso para desarrollar aplicaciones para Android, en el cual se reparten 10 millones de dólares en premios:

• 50 premios de 25.000 dólares a los proyectos que pasen la primera criba.
• 275.000 dólares extra a los 10 mejores proyectos.
• 100.000 dólares extra a los 10 siguientes.

Pues me he pasado 2 semanas migrando una aplicación interna de la empresa de Swing a SWT… ¿el motivo? En realidad, como se apunta al final en Why SWT? ninguno más allá del reto que supone aprender SWT. Las diferencias son grandes, pero salvables. En general, SWT parece un código más limpio y las equivalencias son bastante lógicas:

• Lo que en Swing es JFrame, en SWT es un Shell
• Lo que en Swing es un JPanel, en SWT es un Composite
• En SWT no hay JCheckBox, JRadioButton, JButton… todo son Button con diferentes estilos
• JList y JComboBox son, respectivamente List y Combo
• Todos los cuadros de texto que tiene Swing se agrupan en un solo componente, Text (con diferentes estilos, aunque está muy limitado en comparación)

Podríamos seguir así, haciendo una lista interminable.

La principal diferencia, sin embargo, es que en SWT es obligatorio que todo lo que se haga sobre la interfaz gráfica se haga en el mismo hilo (thread) de ejecución. Es lo que llaman el UIthread, que será fácilmente reconocible porque es el que crea el objeto Display. Si queremos modificar el interfaz gráfico desde otro hilo, la clase Display nos provee de 2 métodos para hacerlo, asyncExec (Runnable) y su compañero syncExec (Runnable).

Y justo cuando termino, leo que Chuidiang posteó hace poco una pequeña guía de SWT y JFace que no me habría venido mal. Ahora tocará aprender JFace :)