Hemos leído: Bjarne Stroustrup: Programming. Principles and Practice Using C++

Programming: Principles and Practice Using C++En dos palabras: impresionante. La segunda es mamotreto de más de mil doscientas páginas, y el primer libro técnico que he leído que viene impreso a todo color.

El libro es un libro de aprendizaje para quien quiera iniciarse en el desarrollo y en C++, es decir, no presenta C++ como un lenguaje, sino que, a la vez que nos va explicando qué es y cómo se programa, lo va haciendo con C++.

Y eso significa que los punteros no se ven hasta la página seiscientos y pico, de las funciones típicas de C mejor no hablar, o más bien hablar de ellas en el último capítulo, tratadas como lo que son: obsoletas para un programador de C++, que tiene otras herramientas mucho más poderosas a su disposición.

EL libro es el mejor ejemplo que he podido ver que contrarresta la caduca y trasnochada falacia de que para aprender C++ primero hay que aprender C. Si todavía piensas así, léete el libro y verás.

Hay una cosa que siempre me ha molestado mucho. Y que conste que yo soy de los que aprendieron primero C y luego C++, no porque siguiera la regla falaz, sino porque cuando yo aprendí C, C++ era un animal mitológico casi en la cabeza del amigo Stroustrup. Recuerdo que se comentaba algo de un “C con clases”, de un metacompilador que traducía aquello a algo completamente ilegible que se suponía que era una mezcla de C y de preprocesador pero que sin embargo el compilador de C tragaba y generaba código. Hablamos de los tiempos del Turbo C 2.0. Ojo, Turbo C, no Turbo C++, ese vino luego. Y luego el Borland C++, en los tiempos mitológicos en los que Borland era alguien en el tema de los lenguajes de programación.

Vaya, me fui por los Cerros de Úbeda, debe ser cosa de la edad. Repitamos: hay una cosa que siempre me ha molestado mucho, es que es una lástima ver a chavalines con apenas conocimientos de programación pelearse con las funciones de C como printf y lo que es peor, con punteros. Así pronto se van a aburrir y van a pensar que C++ es algo enormemente difícil, y no es cierto.

Bueno, al menos no totalmente cierto. C++ es complejo. Pero no necesariamente uno tiene que ver esa complejidad el segundo día de clase. Y el libro lo demuestra plenamente. El capítulo sobre los punteros es antológico (recordemos, página seiscientos y pico, no cien), y el que explica la STL creando a mano y explicando la clase vector, también. Y el que trata sobre desarrollo de sistemas embebidos no tiene precio. Tampoco los tres o cuatro en los que explica la herencia y el polimorfismo mediante la creación de un envoltorio a parte de la biblioteca FLTK…

Vaya, realmente todos los capítulos son antológicos. Aparte de los conceptos sobre programación que no solo sirven para C++, el desarrollo de los mismos está completamente cuidado y, por primera vez en la historia de todos los libros básicos sobre programación que he leído, los ejemplos no son ejemplos chorra que luego no sirven para nada. Ya he dicho cómo envuelve la FLTK, cómo explica la STL construyendo una clase Vector que es homónima de la real y que tiene casi sus mismas características, pero no he dicho que las cadenas son, desde el primer momento, string (o más bien, basic_string<char>). Tampoco he dicho la cuidada forma en que parte de un diseño no válido y lo va mejorando paso a paso, explicándonos qué está mal y por qué (esa es otra, hacer que un aprendiz de C++ tenga que pelear con las cadenas de C (léase: de C) terminadas en nulo; es una aberración).

Por supuesto, la sempiterna calculadora que aparece en todos sus libros sigue estando, pero esta vez explica qué es una gramática y, a partir de ella, va refinando, paso a paso, el diseño original (que sólo es capaz de sumar y restar, y encima mal) hasta construir una calculadora capaz de realizar las operaciones básicas con un número indeterminado de agrupaciones con paréntesis y definición de variables y constantes. Ciertamente en algunos aspectos la construcción final no es la óptima ya que todavía no se ha visto la STL ni otros conceptos, pero el resultado es espectacular.

Quizás el arranque del mismo sea un poco fuerte para un estudiante novel, pero seguro que si lo termina y hace todos los ejercicios que vienen en él, estoy plenamente convencido de que cuando lo acabe, será un programador situado por encima de la media. Ojo, que no es un libro para aprenderlo en un mes, ni en dos, quizás en un año o incluso más, al menos si sigues y haces todos los ejercicios que vienen… Menos mal que uno ya pasó esa etapa, pero si tuviera que repetirla, indudablemente me gustaría hacerla con este libro como maestro.

Cómo abrir máquinas virtuales vmWare en ventanas independientes

Esta es una tarea pendiente que llevaba bastante tiempo detrás de conseguir. Quizás lo que cuente aquí sea evidente para todos menos para mi, pero por si acaso -y para que no se me olvide-, voy a dejar constancia de ello.

¿Qué desarrollador moderno no tiene varias máquinas virtuales para hacer sus experimentos y pruebas? Yo al menos tengo una buena espuerta de ellas, y si bien antes usaba Virtual PC, que no es un mal producto ni de lejos, al carecer de soporte para USB terminó haciendo que cada vez menos máquinas virtuales estuvieran en Virtual PC y más en vmWare, y en la última instalación de Windows decidí prescindir de Virtual PC ya que muchas veces lanzaba máquinas de ambos productos sin darme cuenta y terminaba con una bonita pantalla azul debida al bit de virtualización…

Virtual PC mantiene una lista de máquinas virtuales y cuando abres una la lanza en una ventana independiente. vmWare tiene similares opciones pero quedan encastradas en la misma ventana virtual, de modo que, aparte de estar siempre visibles, reducen la cantidad de máquina virtual que pueden mostrar. No obstante, todas esas cosas se pueden ocultar sin problema, pero entonces estamos un poco ciegos en cuanto qué tenemos abierto…

Una solución es lanzar las máquinas virtuales y luego entrar en ellas mediante escritorio remoto… pero si estás haciendo por ejemplo una aplicación que usa gráficos de forma intensiva el resultado no es muy bueno, no en relación a tener la pantalla directamente…

Así que yo empecé por tener una carpeta en el escritorio conteniendo un acceso directo a cada una de las máquinas virtuales que tengo, al abrir la primera todo va bien, pero al abrir la segunda ésta oculta la anterior de modo que luego tienes que estar saltando entre una y otra desde el menú Window, o, lo que es peor, si estás en pantalla completa tienes que quitarla, cambiar y volver (evidentemente, quien tenga un solo monitor no está afectado por ese problema, pero quien use dos como yo, se pueden mostrar dos máquinas virtuales a pantalla completa en vmWare, una en cada monitor).

Evidentemente, no hay ningún switch ni ninguna opción para hacer esto. Es decir, no hay ningún sitio ni en las opciones del programa ni en las de la línea de comandos que diga «abre cada máquina virtual en una ventana independiente». La forma más directa es ir al menú inicio, abrir una nueva sesión de vmWare, y desde el programa cargar la nueva máquina virtual (y eso si no está cargada ya en otra ventana) y lanzarla.

Pues bien, la solución es tan evidente que… bueno, mejor la digo y no se hable más:

Abrir cada máquina virtual wmWare en una ventana independiente a partir de un acceso directo.

Bueno, lo primero es añadir la ruta de vmWare a tu path. En mi caso es «C:Program Files (x86)VMware». Luego, cambiar el acceso directo de, por ejemplo «C:MisVMVM tontaVM tonta.vmx» a ‘vmware «C:MisVMVM tontaVM tonta.vmx»‘. Así se abrirá cada una en una ventana independiente.

Sí, ya lo sé, es una tontería.

Hemos leído: David S. Platt: Why Software SUCKS… and what can you do to about it.

En apenas 250 páginas el autor pone a caldo hasta a su propia madre, todo ello con motivos más que justificados.

Una traducción directa del título podría ser: ¿Por qué el apesta el software… y qué podemos hacer acerca de ello? Y el contenido refleja fielmente el título. Lectura recomendable para todo geek confeso o inconfeso, programador u operador de sistemas, eterno sufridor de los bugs y las malas decisiones de los arquitectos de aplicaciones, seas quien seas, sea cual sea tu rol en esta vida, si está relacionada de alguna forma con los ordenadores, deberías leer el libro.

Para echarte unas carcajadas de ti mismo y del vecino, de tu jefe y de tus empleados si los tienes, de Microsoft, de UPS, de Starbucks… Ciertamente en el libro hay mucho humor, pero humor negro y justificado. La parte sobre los acrónimos no tiene precio. No es que abunden los chistes, aunque alguno hay:

-¿Cuántos chicos del servicio de soporte técnico de Microsoft hacen falta para cambiar una bombilla?

-Sentimos no poder reproducir su problema. Todas las bombillas están funcionando bien.

Otro:

-¿Cuántos programadores de Microsoft hacen falta para cambiar una bombilla?

-Ninguno. Bill Gates anunciará que Microsoft® Oscuridad® es el nuevo estándar.

Aparte del humor hay planteadas muy buenas cuestiones sobre la usabilidad del software y de las páginas web, así como temas todavía más serios como la seguridad, etc.

Quizás la mejor parte del libro para un profano al desarrollo sea el final del libro, en el que plantea el ecosistema geek mostrándonos qué ocurre en una edición del TechEd o hablándonos de por qué Microsoft es ahora el demonio, por qué en otro momento fue el salvador del mundo y cómo Google viene a la zaga.

El único problema es que está en inglés, aunque por otro lado no es necesario que seas ningún experto en ordenadores para entender el libro, ya que el lenguaje es llano y carente de tecnicismos, y cuando hay alguno, antes lo explica.

Hemos leído: John Lakos: Large-Scale C++ Software Design

clip_image002

Bueno, realmente no lo hemos leído del todo, ya que nos quedan cien de las ochocientas páginas que componen este mamotreto, pero que si no pasa nada caerán esta noche de forma rápida, ya que son varios apéndices.

¿Por dónde empezar? Uf. Es un libro difícil de leer, no por la prosa, sino por el contenido, altamente –muy altamente- técnico. El autor parte de que ya sabes C++, pero no el C++ que puedas aprender en la escuela, sino C++ de verdad. No se entretiene en explicarte esto o aquello, sino que parte a saco, suponiendo que eres un programador profesional.

Como el título indica, el libro está destinado a los desarrolladores de grandes proyectos en C++, aunque ciertamente si eres uno que trabaja en solitario o con poco acompañamiento como yo el libro también te va a servir, y no poco, aunque haya partes que en principio no estén dedicadas a ti, pero siempre se pueden sacar buenas ideas y conceptos.

John comienza con el hecho de que la mayoría de libros sobre diseño de C++ se centran en la parte lógica en lugar de la física, es decir, mucha clase, mucho encapsulamiento, mucha jerarquía de objetos, pero sin tener en cuenta el coste de compilación que supone usar tales abstracciones en un lenguaje como C++. Y nos da ejemplos prácticos y nos muestra cómo un cambio trivial en una línea de un fichero puede suponer la compilación completa de un sistema que puede tardar horas o incluso días.

Después de estudiar métricas sobre el tema, el nivel de acoplamiento entre componentes, etc., comienza lo bueno: técnicas, sesudamente razonadas, para mejorar el diseño, no lógico, sino físico, de forma que los tiempos de compilación y la estabilidad de los interfaces públicos mejoren en gran medida.

Algunos conceptos son triviales y reducen drásticamente el tiempo de compilación, otros son más complejos y requieren una refactorización completa (o casi) del diseño. Lo bueno del libro es que siempre, siempre, vamos guiados por razonamientos formales y por ejemplos completamente válidos, de modo que la conclusión es obvia: el autor tiene toda la razón.

El núcleo del libro son los capítulos 5, 6 y 7, en los que nos habla de los tres niveles a considerar: el de los componentes (entendidos como una unidad física), el de los paquetes y el de los grupos de paquetes. Ciertamente en los tres capítulos se repiten casi las mismas las técnicas aplicadas a cada nivel, pero vienen destinadas a diferentes roles dentro de un teórico grupo de desarrollo. De hecho, he estado prácticamente como un mes y medio dedicado a leer, anotar y releer parte de estos capítulos, aunque el 7 se me quede un poco grande.

La tercera parte del libro trata sobre conceptos lógicos, y es más un compendio de reglas sueltas relativamente razonadas que un todo coherente. No obstante, resulta un buen complemento a lo anterior. Por ejemplo, nos explica la mejor forma de sobrecargar los operadores y por qué otras sobrecargas son generalmente incorrectas aunque formalmente válidas, el uso de tipos y de parámetros, por qué no sobrecargar el operador new de forma global y un largo etcétera.

Se nota que el libro es algo viejo. Nos habla de los espacios de nombres como novedad, y de las plantillas como algo ineficaz y peligroso y que de momento los compiladores no saben tratar adecuadamente, pero sin embargo, nos da razonadas ideas sobre su uso.

Aunque no es un libro para tener sobre la mesa de trabajo, sí que puede resultar útil su lectura periódica y su consulta cuando nuestro proyecto se vuelva un poco inmanejable. Además, al final de cada capítulo y del propio libro, viene un interesante resumen de todos los temas tratados en cada uno de ellos.

En fin, que se trata de un libro muy recomendable para aquellos profesionales de C++ o amateurs que quieran serlo.

Creación de contenidos para los lectores de eBooks II (PDF y otros)

La entrada anterior que tiene relación con ésta de aquí, y en ella explico la creación de ficheros PDF para los lectores de 6 pulgadas y el iLiad. En la que ahora nos ocupa voy a hablar un poco del DR1000 y voy a explicar cómo crear contenido para él, así como generarlo en otros formatos “fluyentes”.

Con el palabro de arriba quiero decir aquellos formatos en los que el texto fluye, de manera que no importa en qué aparato se lean, ya que será el software el que ajuste tanto el tamaño de letra como el propio texto.

 DR1000

Llevo unos días manejando uno de ellos, y ciertamente el tamaño y claridad de la pantalla es impresionante, como impresionante es el tratamiento de los PDF, incluso aquellos considerados enormemente complejos, como Scientific American o Circuit Cellar.

Antes de que saliera la versión 1.5 de su firmware, la duración de la batería no llegaba a las cuatro horas de uso continuado, con esta nueva versión puede llegarnos a durar hasta 12 horas, aunque lo normal en un uso normal sean unas 8, gracias a la opción de suspender a memoria transcurrido un tiempo configurable. El único inconveniente es que al pasar página se produce un desagradable parpadeo.

El uso del formato Mobipocket continua siendo testimonial, con apenas una opción para configurar el tamaño de fuente, aunque ahora, frente al iLiad, la búsqueda en diccionario es bastante rápida. Además, también podemos buscar una palabra en un PDF y de forma global sin tener cargado ningún fichero. No obstante, una vez estás viendo la palabra buscada, volver hacia atrás puede ser bastante complicado si no te lees atentamente el manual.

El tratamiento de ficheros PDF es más que exquisito dadas las características del formato, aunque sigue sin soportar el modo “tagged”, y encima te permite tener hasta cuatro documentos cargados en memoria, siendo la duración del cambio entre ellos menor que volverlos a cargar desde la SD.

Los pulsadores, pocos pero suficientes, son de contacto táctil, por lo que seguro que van a durar lo que dure el propio aparato (a no ser que uno se quede manco, claro.:-P).

También comparte el mismo problema que la mayoría de estos aparatos: el cable de cargar se inserta por la parte baja, con lo que no podemos apoyárnoslo en el cuerpo mientras se está cargando, y los cables USB acodados brillan por su ausencia…

Es completamente abierto, por lo que puedes añadir prácticamente cualquier programa que quieras (y que la gente haya portado o creado), de hecho yo tengo instalado el FBReader completamente integrado dentro del software. Por ahí anda circulando hasta un port del GTKSudoku. De la web del fabricante te puedes bajar un SDK bastante completo que trae incluso un emulador del bicho.

Contenido en PDF para el DR1000

No es necesario modificar un PDF para poder ser visto en el DR1000, no al menos si está en A4 y la fuente es de 8 puntos hacia arriba, ya que se ven perfectos, y cuando digo perfectos es perfectos, pese a que las imágenes a veces quedan algo mal si están en color en el original.

No obstante, podría interesarnos convertir una novela a PDF para aprovechar el gran tamaño de su pantalla, que al no ser A4 completo genera unos feos márgenes en negro. Por ello, siguiendo las pautas de la entrada anterior de esta serie, el tamaño de página para vertical es de 162 mm de alto por 197 mm de ancho, lo que podría resumirse en 16×20 sin problemas. Para el modo apaisado es de 20×15. ¿Por qué no son equivalentes e inversos uno del otro? Dado que el software de iRex coloca una barra de tareas en la parte inferior, al hacer el cambio, estos son los resultados descontando la misma.

No obstante, si queremos visualizar el texto a pantalla completa, el tamaño es de 162 mm por 203 mm, y en este caso sí que son completamente inversos.

La mayor recomendación que puedo hacer es colocar dos columnas para el texto en vertical. En la foto, el DR mostrando una página de los Cuentos Completos de Dick, volumen 4, con una fuente de 8 puntos:

clip_image002[4]

Y en esta otra de abajo, vemos al DR mostrando la novela cuyo título se puede leer en el propio documento, en apaisado, con una fuente de 10 puntos y tres columnas, que es la recomendación que hago para este formato:

clip_image004[4]

Contenido en FB2

Generar contenido en este formato, que suelen leer la mayoría de aparatos de seis pulgadas, el DR1000 y el iLiad si se les aplica el parche correspondiente, puede llegar a ser bastante complicadillo y laborioso. No obstante, el resultado es el más espectacular de todos. Dependiendo del lector que tengas, el software integrado en él para este formato podrá ser el Coolreader, que es el más común y que tiene problemas con la separación de sílabas y el FBReader.

Existen varios tutoriales en castellano en la red para generar este tipo de contenido, entre los que destacan:

· Tutorial de Katxan para generar en FB2

· Video tuturial de Kaxtan

Como comprenderéis, no voy a repetir lo que ya está hecho, y encima bien hecho. De paso, recomiendo la WEB de Lectores Electrónicos, en donde me encontraréis en los foros y seguro que veréis muchas más cosas interesantes.

Contenido en PRC (Mobipocket)

Por mor de completitud, generar contenido con este formato es trivial: instálate el Mobipocket Reader y úsalo para importar el contenido. Es así de fácil y en general el resultado va a ser parejo a hacerlo a mano con el Mobipocket Creator.