sábado, octubre 29, 2005
Contar binario con las manos
Pues eso: cómo contar en binario con la mano. Sería mucho más fácil si tuviésemos 8 dedos por mano.
Vía mini-d.
Vía mini-d.
viernes, octubre 28, 2005
Por qué fracaso el teléfono iTunes
Un gran artículo en Wired cuenta por qué fracasó el teléfono iTunes, es decir, el ROKR desarrollado en conjunto por Motorola y Apple.
Primer problema: Motorola quería unirse con Apple para ganar factor cool y vender más teléfonos. Por su parte, Apple lo que quería era vender más canciones de iTunes y, sobre todo, no matar su mejor negocio, que es el iPod. Apple teme que los móviles con MP3 le hagan perder su posición privilegiada en ese mercado. Por lo tanto, en el fondo le interesa que se vendan pocos móviles con MP3. En resumen, conflicto de intereses entre los fabricantes del móvil que tuvo como resultado un producto muy capado: tenía un límite artificial para no poder contener más de 100 canciones.
Segundo problema: Una vez que lo tuvieron hecho, buscaron algún operador de telefonía que lo subvencionase. Ninguno quería hacerlo: el teléfono sólo permitía añadir música conectándose al PC. Lo que quieren las compañías de móviles es que los usuarios se bajen la música a través de sus redes... para pasarles la correspondiente factura, lógicamente.
Tercer problema: Además, las compañías quieren meterse también en el negocio de la música on-line y que los usuarios compren en sus tiendas, no en iTunes. Para colmo, esperan poner precios de 2.75 dólares, mucho más que los 0.99 del iTunes. Pero esperan que los usuarios los paguen porque ya pagan algo similar por los famosos politonos, que son versiones de las canciones con mucha menos calidad. Lógico, ¿no?
Merece la pena leer el artículo entero. También habla de DRM, de p2p en los móviles y de compañías que hicieron que los fabricantes retiraran el soporte Bluetooth de los aparatos para que cuando los usuarios quisieran meter datos tuvieran que pasar por su red.
Primer problema: Motorola quería unirse con Apple para ganar factor cool y vender más teléfonos. Por su parte, Apple lo que quería era vender más canciones de iTunes y, sobre todo, no matar su mejor negocio, que es el iPod. Apple teme que los móviles con MP3 le hagan perder su posición privilegiada en ese mercado. Por lo tanto, en el fondo le interesa que se vendan pocos móviles con MP3. En resumen, conflicto de intereses entre los fabricantes del móvil que tuvo como resultado un producto muy capado: tenía un límite artificial para no poder contener más de 100 canciones.
Segundo problema: Una vez que lo tuvieron hecho, buscaron algún operador de telefonía que lo subvencionase. Ninguno quería hacerlo: el teléfono sólo permitía añadir música conectándose al PC. Lo que quieren las compañías de móviles es que los usuarios se bajen la música a través de sus redes... para pasarles la correspondiente factura, lógicamente.
Tercer problema: Además, las compañías quieren meterse también en el negocio de la música on-line y que los usuarios compren en sus tiendas, no en iTunes. Para colmo, esperan poner precios de 2.75 dólares, mucho más que los 0.99 del iTunes. Pero esperan que los usuarios los paguen porque ya pagan algo similar por los famosos politonos, que son versiones de las canciones con mucha menos calidad. Lógico, ¿no?
Merece la pena leer el artículo entero. También habla de DRM, de p2p en los móviles y de compañías que hicieron que los fabricantes retiraran el soporte Bluetooth de los aparatos para que cuando los usuarios quisieran meter datos tuvieran que pasar por su red.
jueves, octubre 27, 2005
Mileuristas y los Ingenieros
Todo el mundo habla de los mileuristas, esa gente que en el artículo de El País referenciado se define así:
Kirai ha aportado una visión del tema desde el punto de vista de los Ingenieros. Como casi todo lo que escribe, muy interesante y muy clara; pero hay un par de cosas en las que no estoy de acuerdo.
Por una parte, a la hora de plantear opciones las dos primeras son:
El problema es que la segunda es casi igual que la primera: muchos mileuristas son gente con bastantes estudios o que no ha dejado de estudiar aunque tenga más de 30 años.
El otro punto en el que no estoy de acuerdo es en este:
Lo que no me convence de esta visión es eso de que un Ingeniero no debería picar código. Para mí picar (buen) código -en sistemas no triviales- es algo difícil que sí requiere estudios. No es lo mismo que poner ladrillos. Y no creo que se pueda hacer esa división que hay en la construcción de casas entre arquitectos y albañiles. Creo sinceramente que no se puede ser un buen arquitecto de software sin saber escribir buen código y sin estar familiarizado de primera mano con el sistema que diseñas.
¿Cuál es la solución? Ni idea. Pero, a la larga, siempre merece la pena intentar hacer las cosas bien aunque no te las reconozcan.
"El mileurista es aquel joven licenciado, con idiomas, posgrados, másters y cursillos (...) que no gana más de 1.000 euros.
Kirai ha aportado una visión del tema desde el punto de vista de los Ingenieros. Como casi todo lo que escribe, muy interesante y muy clara; pero hay un par de cosas en las que no estoy de acuerdo.
Por una parte, a la hora de plantear opciones las dos primeras son:
1.-Hacerse mileurista y esperar a ver que pasa frustrándote cada día.
2.-Seguir estudiando y esperar a ver que pasa pero aprendiendo cosas cada día
El problema es que la segunda es casi igual que la primera: muchos mileuristas son gente con bastantes estudios o que no ha dejado de estudiar aunque tenga más de 30 años.
El otro punto en el que no estoy de acuerdo es en este:
Mis amigos que marcharon a Alemania son más que “Dosmileuristas” y no están “colocando ladrillos/picando código” [...]
Lo que no me convence de esta visión es eso de que un Ingeniero no debería picar código. Para mí picar (buen) código -en sistemas no triviales- es algo difícil que sí requiere estudios. No es lo mismo que poner ladrillos. Y no creo que se pueda hacer esa división que hay en la construcción de casas entre arquitectos y albañiles. Creo sinceramente que no se puede ser un buen arquitecto de software sin saber escribir buen código y sin estar familiarizado de primera mano con el sistema que diseñas.
¿Cuál es la solución? Ni idea. Pero, a la larga, siempre merece la pena intentar hacer las cosas bien aunque no te las reconozcan.
lunes, octubre 24, 2005
Fabricar en Europa no es caro
...o al menos eso dice Kevin Rollins, presidente de DELL, en el País Negocios del 16 de octubre:
Así justifica que ellos mantegan sus fábricas en Europa. Pero si está tan claro, ¿por qué el resto de fabricantes de PC no lo hacen?
El coste de montar un PC son siete u ocho dólares, pero transportarlo cuesta 40 ó 50.
Así justifica que ellos mantegan sus fábricas en Europa. Pero si está tan claro, ¿por qué el resto de fabricantes de PC no lo hacen?
¿Bubble 2.0 o algo nuevo?
Ahora que se está celebrando la WebDosBeta, la noticia principal en Memorandum habla sobre la burbuja 2.0 y Joel Spolsky afirma que no va utilizar el término Web 2.0 nunca más ni a enlazar a ningún artículo que lo mencione.
Las tripas de un disco duro
A través de DíaUno descubro un vídeo del interior de un disco duro. Impresiona ver la velocidad a la que se mueven las cabezas.
viernes, octubre 21, 2005
El periódico de la blogosfera
Por un artículo en Wired me entero de la existencia de Memorandum. Es una especie de Google News pero que utiliza como fuente blogs. La versión enlazada está dedicada a noticias tecnológicas, así que te encuentras una especie de periódico con las principales noticias del momento con sus correspondientes comentarios en distintos blogs. Ahora mismo, lo más caliente es Flock... por si alguien no se había dado cuenta :-)
jueves, octubre 20, 2005
Video iPod
Nuevamente, en Ars Technica tienen la mejor revisión del Video iPod que he visto, con fotos muy ilustrativas y comentarios muy interesantes.
Lo que más me ha llamado la atención: cómo a pesar de ganar nuevas capacidades, el iPod ha ido adelgazando (eso sí: ha perdido FireWire); la posiblidad de conectarlo a una televisión; y que para el iPod de 60 GB dan una duración de la batería de 20 horas con música: eso empiezan a ser cantidades serias tanto de memoria como de tiempo.
Ah, y por supuesto, tienen una vivisección :-)
Lo que más me ha llamado la atención: cómo a pesar de ganar nuevas capacidades, el iPod ha ido adelgazando (eso sí: ha perdido FireWire); la posiblidad de conectarlo a una televisión; y que para el iPod de 60 GB dan una duración de la batería de 20 horas con música: eso empiezan a ser cantidades serias tanto de memoria como de tiempo.
Ah, y por supuesto, tienen una vivisección :-)
Leyendas urbanas sobre la velocidad de Java
En este artículo sobre leyendas urbanas sobre la velocidad de Java explican cosas curiosas como:
- Es más rápido un new en Java (10 instrucciones máquina en las implementaciones actuales) que un malloc en C (entre 60 y 100 instrucciones).
- Programas como Ghostscrip y Perl gastan (o malgastan) hasta entre un 20 y un 30 por cierto de su tiempo en malloc y free.
- La gestión dinámica de memoria con el recolector de basura es más rápida que con malloc y free: mientras estos últimos van tratando los bloques uno a uno, el recolector de memoria trata varios de golpe. Como justificación, este estudio dice que reemplazó los asignadores de memoria de C++ por un recolector de basura y muchos programas pasaron a ir más rápido.
También es muy interesante el fragmento respecto a C++ donde explica por qué es más rápido usar la pila que el heap para poner objetos.
Lo que muestra el artículo es que se ha hecho mucha investigación en este campo y que las máquinas virtuales de ahora no son como las de 1995, así que mejor no seguir manteniendo las leyendas urbanas.
Como sé que hay gente que no estará de acuerdo con esto, aquí va un artículo que cuenta cuándo el C es la mejor herramienta. La verdad es que a mí no me ha convencido y algunas de sus afirmaciones respecto a Java (desventajas por no usar macros y problemas de fallos de caché por culpa del consumo de memoria) se ven rebatidas en el otro artículo. Y además, ¿seguro que la eficiencia es importante en el programa que pone de caso de estudio: un resolvedor de juego de cartas? ¿Seguro que merece la pena tener código que usa/abusa de macros y compara estructuras con memcmp y truquillos similares como se vanagloria el autor? Si la eficiencia no es determinante yo prefiero mil veces un if (cartaA == cartaB) a un if (memcmp(cartaA, cartaB, sizeof(carta)) == 0).
- Es más rápido un new en Java (10 instrucciones máquina en las implementaciones actuales) que un malloc en C (entre 60 y 100 instrucciones).
- Programas como Ghostscrip y Perl gastan (o malgastan) hasta entre un 20 y un 30 por cierto de su tiempo en malloc y free.
- La gestión dinámica de memoria con el recolector de basura es más rápida que con malloc y free: mientras estos últimos van tratando los bloques uno a uno, el recolector de memoria trata varios de golpe. Como justificación, este estudio dice que reemplazó los asignadores de memoria de C++ por un recolector de basura y muchos programas pasaron a ir más rápido.
También es muy interesante el fragmento respecto a C++ donde explica por qué es más rápido usar la pila que el heap para poner objetos.
Lo que muestra el artículo es que se ha hecho mucha investigación en este campo y que las máquinas virtuales de ahora no son como las de 1995, así que mejor no seguir manteniendo las leyendas urbanas.
Como sé que hay gente que no estará de acuerdo con esto, aquí va un artículo que cuenta cuándo el C es la mejor herramienta. La verdad es que a mí no me ha convencido y algunas de sus afirmaciones respecto a Java (desventajas por no usar macros y problemas de fallos de caché por culpa del consumo de memoria) se ven rebatidas en el otro artículo. Y además, ¿seguro que la eficiencia es importante en el programa que pone de caso de estudio: un resolvedor de juego de cartas? ¿Seguro que merece la pena tener código que usa/abusa de macros y compara estructuras con memcmp y truquillos similares como se vanagloria el autor? Si la eficiencia no es determinante yo prefiero mil veces un if (cartaA == cartaB) a un if (memcmp(cartaA, cartaB, sizeof(carta)) == 0).
martes, octubre 18, 2005
Las mejores 20 fuentes gratis
Por aquí comentan las supuestas 20 mejores fuentes gratis. Hay algunas muy buenas.
sábado, octubre 15, 2005
PEZ MP3
La chorrada del día: un reproductor MP3 con forma de PEZ. Sí, aquellas pastillas que tomábamos de pequeños antes de que tomar pastillas significase otra cosa...
viernes, octubre 14, 2005
Productividad
Juanjo Navarro, uno de los tipos más productivos de la blogosfera en español, como demuestra con proyectos como Planeta Código, Versión Cero o Locos Bajitos, ha abierto un nuevo blog sobre productividad personal y organización del tiempo, Semana Vista. Precisamente el otro día me llamó la atención un libro sobre ese tema titulado «Getting Things Done»... pero me parece que no voy a leerlo porque no tengo tiempo ;-)
Por cierto, muy interesante también esta entrada sobre Wikis de Juanjo donde descubro WikiHow, un Wiki dedicado a cómo hacer cualquier cosa, hasta cómo tocar la guitarra como Eddie Van Halen.
Por cierto, muy interesante también esta entrada sobre Wikis de Juanjo donde descubro WikiHow, un Wiki dedicado a cómo hacer cualquier cosa, hasta cómo tocar la guitarra como Eddie Van Halen.
miércoles, octubre 12, 2005
Linux en el mundo del cine
Sigamos citando a Barrapunto, ya que estamos en racha. Por cierto, una de las razones por las que probablemente no se suela citar mucho en las bitácoras a Barrapunto es porque -paradójicamente- es muy leída; es decir, mucha gente no la citará porque creerá que sus lectores también leen Barrapunto, como apuesto que hace más del 75% de los lectores de este blog. Si hay alguno que no la lea, que levante la mano ;-)
Bueno, pues al grano. El otro día salió una noticia contando que para hacer la película sobre Halo están utilizando Linux. Pero lo mejor fue un comentario que enlazaba a este artículo (de septiembre de 2003) donde se cuenta cómo Linux se fue metiendo poco a poco en el cine. Es realmente apasionante.
Un pequeño resumen: Al principio Linux se utilizó para renderizar, pero las estaciones de trabajo donde se hacían los diseños eran SGI, Sun y similares.
Si Linux para gráficos era más lento que Windows, ¿por qué no se pasaron a Windows? Pues porque tenían un montón de código que ya era Unix y portarlo a Windows no era nada fácil. Afortunadamente, nVidia hizo un driver decente para Linux y el problema de la velocidad se solventó. ¿Cuál fue el resultado?
Otra parte muy interesante del artículo trata de la contradicción de usar un sistema operativo libre para desarrollar aplicaciones cerradas y propietarias.
Lo curioso es que eso mismo se puede aplicar por ejemplo a la informática de un banco: no va a esperar a que Microsoft le arregle un bug en Windows y será mejor pagar a alguien para que lo haga.
Y hablando de aplicaciones para desarrollar animaciones para el cine, ha habido un resultado cuando menos curioso:
El artículo está (muy bien) escrito por el director del proyecto de código abierto CinePaint. Otro de los detalles que cuenta es que los estudios no pagarían por un software al que no le pudieran meter mano, así que aunque por ejemplo Apple Shake es cerrado, a los estudios se les proporciona el código fuente. Pero parece que quieren utilizar el Photoshop y Adobe no está por la labor de dejarles ver el código fuente...
Otra historia apasionante gracias a Barrapunto.
Bueno, pues al grano. El otro día salió una noticia contando que para hacer la película sobre Halo están utilizando Linux. Pero lo mejor fue un comentario que enlazaba a este artículo (de septiembre de 2003) donde se cuenta cómo Linux se fue metiendo poco a poco en el cine. Es realmente apasionante.
Un pequeño resumen: Al principio Linux se utilizó para renderizar, pero las estaciones de trabajo donde se hacían los diseños eran SGI, Sun y similares.
Making Linux a success on servers and renderfarms was simple compared to the next step — the desktop.
The chief obstacle: graphics drivers. Linux graphics performance was terrible, much slower than other operating systems. [...]
Si Linux para gráficos era más lento que Windows, ¿por qué no se pasaron a Windows? Pues porque tenían un montón de código que ya era Unix y portarlo a Windows no era nada fácil. Afortunadamente, nVidia hizo un driver decente para Linux y el problema de la velocidad se solventó. ¿Cuál fue el resultado?
Robert Weaver noticed a tremendous performance boost upgrading from RISC workstations to Linux PCs during Star Wars: Episode II. “The old system was so slow that the clones firing lasers appear to be throwing javelins,” says Weaver. “We've seen about a 5x speed improvement in Linux. I'd say Linux is one of the most successful efforts we've had. I can't say enough good things about it. It is intuitive, incredibly stable, and we can get stuff fixed at a moment's notice.”
DreamWorks' Ed Leonard says the performance of Linux-based machines makes artists more productive.
Otra parte muy interesante del artículo trata de la contradicción de usar un sistema operativo libre para desarrollar aplicaciones cerradas y propietarias.
Contrary to common sense, to build the best secret proprietary software you need an open-source platform underneath it. The reason is that proprietary software can require tweaks to the operating system itself that no proprietary operating system vendor would be interested in implementing. Moreover, motion picture production is a very time-sensitive business. A problem in the operating system can't be allowed to hold up production. With open source, studios can throw programmers at anything, whether at the software or OS level.
Lo curioso es que eso mismo se puede aplicar por ejemplo a la informática de un banco: no va a esperar a que Microsoft le arregle un bug en Windows y será mejor pagar a alguien para que lo haga.
Y hablando de aplicaciones para desarrollar animaciones para el cine, ha habido un resultado cuando menos curioso:
Now, three of the most popular 3D animation drawing packages are available in Linux versions: SideFx Houdini (Linux in 1999), Alias Maya (Linux in 2001), and SoftImage (Linux in 2001). [...]
An irony of the migration of software to Linux is that Apple and Pixar became leading suppliers of Linux software. The most popular motion picture compositing software — Apple Shake (Linux in 2000) — and the most popular renderer — Pixar RenderMan (Linux in 1999) — are both sold by companies headed by Steve Jobs.
El artículo está (muy bien) escrito por el director del proyecto de código abierto CinePaint. Otro de los detalles que cuenta es que los estudios no pagarían por un software al que no le pudieran meter mano, así que aunque por ejemplo Apple Shake es cerrado, a los estudios se les proporciona el código fuente. Pero parece que quieren utilizar el Photoshop y Adobe no está por la labor de dejarles ver el código fuente...
Otra historia apasionante gracias a Barrapunto.
Números grandes
Vamos a citar un poco más a Barrapunto... y a la Wikipedia.
En una noticia sobre propiedad intelectual me dio por poner en duda que fuese un derecho natural, probablemente porque después de leer «La lucha por la dignidad», ese gran libro de José Antonio Marina y María de la Válgoma*, no me convencen esos «ganchos transcendentales» que son los derechos naturales, tan válidos como decir «porque lo pone la Biblia». Lo curioso es que a alguien se le ocurrió contestar sobre si los derechos naturales al extenderlos pasaban a ser reales, irracionales, irreales, complejos... Y eso me llevó a mí a acordarme de que el otro día aprendí que hay dos tipos de números que desconocía: los algebraicos y los trascendentes. Parece que para los derechos humanos pegan más los segundos ;-)
El caso es que buceando por la sección de números de la Wikipedia de nuevo me encontré con esta curiosa entrada sobre números grandes donde me han contestado a dudas trasncentales que me amargaban hace tiempo, como cuál es la probabilidad de ser fulminado por un rayo o de que me toque la lotería... o de las dos cosas a la vez.
* Al final acabé antes levantándome a coger el libro de la estantería que buscando por Internet para comprobar el nombre exacto. A veces funciona mejor el método de búsqueda tradicional que Google.
En una noticia sobre propiedad intelectual me dio por poner en duda que fuese un derecho natural, probablemente porque después de leer «La lucha por la dignidad», ese gran libro de José Antonio Marina y María de la Válgoma*, no me convencen esos «ganchos transcendentales» que son los derechos naturales, tan válidos como decir «porque lo pone la Biblia». Lo curioso es que a alguien se le ocurrió contestar sobre si los derechos naturales al extenderlos pasaban a ser reales, irracionales, irreales, complejos... Y eso me llevó a mí a acordarme de que el otro día aprendí que hay dos tipos de números que desconocía: los algebraicos y los trascendentes. Parece que para los derechos humanos pegan más los segundos ;-)
El caso es que buceando por la sección de números de la Wikipedia de nuevo me encontré con esta curiosa entrada sobre números grandes donde me han contestado a dudas trasncentales que me amargaban hace tiempo, como cuál es la probabilidad de ser fulminado por un rayo o de que me toque la lotería... o de las dos cosas a la vez.
* Al final acabé antes levantándome a coger el libro de la estantería que buscando por Internet para comprobar el nombre exacto. A veces funciona mejor el método de búsqueda tradicional que Google.
lunes, octubre 10, 2005
El bytesexual
La Wikipedia es la rehostia.
Perdonen el palabro técnico en este blog habitualmente circunspecto, pero es lo que pensé cuando me puse a leer sobre números reales y fui pasando de una entrada a otra hasta que llegué a la representación de enteros en el ordenador y me encontré con esta interesante tabla que compara el uso de prefijos decimales o binarios:
Ahí se puede ver cómo cuando hacemos la aproximación «1 k = 1000» y estamos en realidad con ks binarios cometemos un error de sólo un 2.40%, pero cuando hablamos de Gigas el error en porcentaje pasa a ser de un 7.37%; por eso los fabricantes de discos duros se decidieron decir el tamaño de los discos con megas decimales, para que pareciera que había casi un 8% más de capacidad.
Lo mejor fue cuando me puse a leer sobre endianness. Ya sabía casi todo lo que ponía ahí; lo que me sorprendió es que existieron ordenadores, como el PDP-11, que no eran ni little-endian ni big-endian, sino que tiraron por la calle de en medio y eran middle-endian.
Pero lo más gracioso fue que aprendí que este concepto de endianness también se le llama byte sex, el sexo de los bytes, y hay ordenadores que no son ni little, ni big ni middle, son bi... bi-endian, también llamados bytesexuals, es decir, que pueden escoger (a veces por hardware, otras por software) ser little- o big-endian. Y no son ordenadores raros; algunos ejemplos: el ARM, el PowerPC, el DEC Alpha, el MIPS y el IA-64 (conocido en barrio como Itanium).
Impresionante lo que se puede aprender en la wikipedia.
Perdonen el palabro técnico en este blog habitualmente circunspecto, pero es lo que pensé cuando me puse a leer sobre números reales y fui pasando de una entrada a otra hasta que llegué a la representación de enteros en el ordenador y me encontré con esta interesante tabla que compara el uso de prefijos decimales o binarios:
| Prefix | Name | [[SI]] Meaning | Binary meaning | Size difference |
|---|---|---|---|---|
| k or K | kilo | 103 = 1000 | 210 = 1024 | 2.40% |
| M | mega | 106 = 10002 | 220 = 10242 | 4.86% |
| G | giga | 109 = 10003 | 230 = 10243 | 7.37% |
| T | tera | 1012 = 10004 | 240 = 10244 | 9.95% |
| P | peta | 1015 = 10005 | 250 = 10245 | 12.59% |
Ahí se puede ver cómo cuando hacemos la aproximación «1 k = 1000» y estamos en realidad con ks binarios cometemos un error de sólo un 2.40%, pero cuando hablamos de Gigas el error en porcentaje pasa a ser de un 7.37%; por eso los fabricantes de discos duros se decidieron decir el tamaño de los discos con megas decimales, para que pareciera que había casi un 8% más de capacidad.
Lo mejor fue cuando me puse a leer sobre endianness. Ya sabía casi todo lo que ponía ahí; lo que me sorprendió es que existieron ordenadores, como el PDP-11, que no eran ni little-endian ni big-endian, sino que tiraron por la calle de en medio y eran middle-endian.
Pero lo más gracioso fue que aprendí que este concepto de endianness también se le llama byte sex, el sexo de los bytes, y hay ordenadores que no son ni little, ni big ni middle, son bi... bi-endian, también llamados bytesexuals, es decir, que pueden escoger (a veces por hardware, otras por software) ser little- o big-endian. Y no son ordenadores raros; algunos ejemplos: el ARM, el PowerPC, el DEC Alpha, el MIPS y el IA-64 (conocido en barrio como Itanium).
Impresionante lo que se puede aprender en la wikipedia.
Pruebas automáticas de aplicaciones GUI
Ha aparecido Dogtail, un entorno para realizar pruebas automáticas de aplicaciones GUI. Las pruebas se hacen mediante scripts de Python que utilizan las funciones de accesibilidad.
De momento sólo funciona para aplicaciones GTK; tienen planeado el soporte para KDE4, aunque para KDE ya existía KD Executor (que no es libre). Otro intento de hacer lo mismo es LDTP (Linux Desktop Testing Project), que también se basa en las funciones de accesibilidad pero utiliza C en vez de Python.
A mí cada día me interesan más las pruebas automáticas, pero como se discute en el Wiki de Ward, para aplicaciones GUI son especialmente complicadas.
De momento sólo funciona para aplicaciones GTK; tienen planeado el soporte para KDE4, aunque para KDE ya existía KD Executor (que no es libre). Otro intento de hacer lo mismo es LDTP (Linux Desktop Testing Project), que también se basa en las funciones de accesibilidad pero utiliza C en vez de Python.
A mí cada día me interesan más las pruebas automáticas, pero como se discute en el Wiki de Ward, para aplicaciones GUI son especialmente complicadas.
sábado, octubre 08, 2005
Rendimiento en Gnome y en Windows
Después de hablar de los procesadores de 64 bits, vamos a seguir con un poco más de rendimiento. Desde el blog de progreso del Gnome 2.10 encuentro un enlace a la página de Federico Mena Quintero donde cuenta cómo hace profiling del selector de ficheros Gnome y mejora su rendimiento. (Por cierto, que si tuviera un poco de paciencia para escribir algo útil, tendría que hablar de KCachegrind, una herramienta impresionante gracias a la cual conseguí bajar el tiempo de ejecución de un programa de casi media hora a un segundo.)
Y lo curioso es que desde la página de este hombre dedicado a Gnome llego a la página de Rico Mariani, que se dedica al rendimiento en Microsoft. Además, en el último artículo a fecha de hoy presentan a David Broman, que es uno de los encargados del API de profiling.
Hay tantas cosas interesantes que leer y tan poco tiempo... Si alguien dispone de este preciado bien para perderlo, que disfrute viendo esta nueva maravilla de Gnome: offscreen rendering. No sé si será útil, pero mola :-)
Y lo curioso es que desde la página de este hombre dedicado a Gnome llego a la página de Rico Mariani, que se dedica al rendimiento en Microsoft. Además, en el último artículo a fecha de hoy presentan a David Broman, que es uno de los encargados del API de profiling.
Hay tantas cosas interesantes que leer y tan poco tiempo... Si alguien dispone de este preciado bien para perderlo, que disfrute viendo esta nueva maravilla de Gnome: offscreen rendering. No sé si será útil, pero mola :-)
Ventajas de los procesadores de 64 bits
Como dice JJ que que no se enlaza mucho a Barrapunto, yo voy a hacerlo. ¡Ale!
En realidad ya pensaba enlazar a esa historia antes de leer la de JJ. Todo empezó cuando el otro día leí una entrada en Código Escrito sobre la gestión de memoria en procesadores de 64 bits. La entrada creo que está equivocada porque confunde el que los procesadores de 64 bits tengan un ancho de palabra en el bus interno de 64 bits con que el bus que se comunica con la memoria sea de 64 bits, cosa que ya ocurre desde el siglo pasado, creo recordar.
La historia enlazada de Barrapunto sobre procesadores de 64 bits tiene algunos comentarios interesantes que apuntan que, además de las ventajas en forma de mayor cantidad de memoria direccionable, lo más importante de la arquitectura AMD64 (o EM64T como la llama Intel) es que tiene más registros de propósito general. Eso permite que los compiladores generen código más rápido, con menos accesos a memoria.
En cualquier caso, como apunta otro comentario, para muchas cosas el cuello de botella en la actualidad no es la CPU, así que no hay que preocuparse tanto con esto de los 64 bits. Al menos de momento.
En realidad ya pensaba enlazar a esa historia antes de leer la de JJ. Todo empezó cuando el otro día leí una entrada en Código Escrito sobre la gestión de memoria en procesadores de 64 bits. La entrada creo que está equivocada porque confunde el que los procesadores de 64 bits tengan un ancho de palabra en el bus interno de 64 bits con que el bus que se comunica con la memoria sea de 64 bits, cosa que ya ocurre desde el siglo pasado, creo recordar.
La historia enlazada de Barrapunto sobre procesadores de 64 bits tiene algunos comentarios interesantes que apuntan que, además de las ventajas en forma de mayor cantidad de memoria direccionable, lo más importante de la arquitectura AMD64 (o EM64T como la llama Intel) es que tiene más registros de propósito general. Eso permite que los compiladores generen código más rápido, con menos accesos a memoria.
En cualquier caso, como apunta otro comentario, para muchas cosas el cuello de botella en la actualidad no es la CPU, así que no hay que preocuparse tanto con esto de los 64 bits. Al menos de momento.
martes, octubre 04, 2005
BDUF
Yo no sabía lo que significaban las siglas «BDUF» hasta que lo leí en el wiki de Ward: Big Design Up Front, «el gran diseño de entrada» o algo así. Vamos, ponerse a hacer un diseño muy detallado y buscando que sea perfecto antes de programar ni una sola línea. Para los de Extreme Programming eso es malo, muy malo.
Pero parece que para Joel, no tanto:
Lo hace en un artículo en el que de paso publica la especificación que hizo para su proyecto Copilot.com, una aplicación para que los colegas les arreglen el ordenador a sus colegas de manera remota, saltándose NAT y proxies y demás estorbos.
¿Quién tiene razón? A mí la postura de los del Extreme Programming me parece razonable: tampoco dicen que no haya que hacer diseño (tienen lo que llaman la metáfora del sistema), pero que debe ser algo ligero. Tal vez a mí me guste un poco más detallado, pero sin que llegue a ser muy pesado.
Vamos, que me gustan los diseños como las mujeres: ni muy gordas ni muy delgadas ;-)
Pero parece que para Joel, no tanto:
I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.
Lo hace en un artículo en el que de paso publica la especificación que hizo para su proyecto Copilot.com, una aplicación para que los colegas les arreglen el ordenador a sus colegas de manera remota, saltándose NAT y proxies y demás estorbos.
¿Quién tiene razón? A mí la postura de los del Extreme Programming me parece razonable: tampoco dicen que no haya que hacer diseño (tienen lo que llaman la metáfora del sistema), pero que debe ser algo ligero. Tal vez a mí me guste un poco más detallado, pero sin que llegue a ser muy pesado.
Vamos, que me gustan los diseños como las mujeres: ni muy gordas ni muy delgadas ;-)
Programar: un juego de niños
He descubierto Alice, un juego para aprender a programar. Dicen que programar es difícil y que meterlo en un juego lo hace más atractivo.
Yo entiendo que, al principio, es difícil ver «x = x + 1» y no pensar «¿Pero cómo va a ser x igual a x + 1?». También entiendo que cuesta mucho lidiar con los errores que da el compilador cuando simplemente te olvidaste un punto y coma. Sin embargo creo que esa primera fase de la programación no es tan difícil de superar. Lo verdaderamente complicado de programar es conseguir que los programas sean entendibles y mantenibles. ¿Conseguirá el juego transmitir esos valores?
Yo entiendo que, al principio, es difícil ver «x = x + 1» y no pensar «¿Pero cómo va a ser x igual a x + 1?». También entiendo que cuesta mucho lidiar con los errores que da el compilador cuando simplemente te olvidaste un punto y coma. Sin embargo creo que esa primera fase de la programación no es tan difícil de superar. Lo verdaderamente complicado de programar es conseguir que los programas sean entendibles y mantenibles. ¿Conseguirá el juego transmitir esos valores?
