Singleton, the bad but not the good

Realmente, este post es la lista de links hacia otros posts que acabo de leer sobre las ventajas y desventajas de utilizar el singleton pattern.

El primero:

Como siempre, Stack Overflow tiene lo que estaba buscando: respuestas, comentarios y más links para seguir leyendo:

Con lo cual llegué, llegué a estos dos posts:

Esto también me llevó al siguiente artículo, sobre porqué es importante evitar la construcción de objetos dentro de la lógica de la aplicación y, en cambio, es más adecuado inyectar dichas dependencias para evitar faltar al principio de single resposibility y facilitar la construcción de tests para tal código:

La verdad es que esta pesquisa estuvo enfocada especialmente en los problemas, porque inició a partir de que estaba evaluando utilizar un singleton para contener la configuración de un sistema (sin el uso de un framework), pero -curiosa coincidencia- justamente la misma tarde que empecé a pensar en el diseño y a hacer algunas pruebas, asistí a un meetup donde se habló en contra del uso de métodos estáticos y del singleton pattern.

El uso de singletons, como resumen personal, representa un problema porque existe una tendencia a tratarlos como variables globales, por lo cual no aparecen en las interfaces de los métodos que los utilizan y, en consecuencia, quedan ocultos a los ojos del programador cuando éste trata de trabajar o construir tests con dichos métodos. Hevery lo pone en pocas palabras:

Singletons are nothing more than global state. Global state makes it so your objects can secretly get hold of things which are not declared in their APIs, and, as a result, Singletons make your APIs into pathological liars.

Para concluir, espero que este espagueti de ideas sea una aportación útil para ustedes.

Templates en PHP con Twig

Recientemente estuve buscando un motor de templating para PHP. Por mi experiencia con el sistema de templates de Django conozco algunas de las cualidades que un buen motor de templates debe reunir. En esta búsqueda particular, estaba interesado en encontrar un motor que cumpliera con lo siguiente:

  • Un lenguaje simple, pero poderoso: los símbolos empleados por el motor debían ser legibles, claros y fáciles de teclear. Necesitaba un lenguaje que soporte estructuras de control y ciclos. Así mismo, requería que el motor escapara el contenido desplegado para hacerlo seguro, que implementara filtros y que contara con una librería de funciones útiles para procesar el contenido generado.
  • Herencia: existen sistemas de templating orientados a construir pequeños fragmentos de páginas, a fin de evitar tareas repetitivas, facilitar el despliegue de información y colocar en un sólo sitio el esquema para de desplegar cierto tipo de contenido. Sin embargo, no todos los motores que he visto soportan herencia, es decir, la capacidad de tomar un template como base para la construcción de otro, evitando así hacer la inclusión de templates en forma repetitiva para armar las partes de un sitio que deben aparecer en todas las páginas que éste contenga. La herencia nos permite simplemente indicar a un template cual será su layout, tomando como base un template padre.
  • Buen desempeño: evidentemente, el tiempo de respuesta es importante, así que me interesa que el motor de templates no sobrecargue demasiado el procesamiento y despliegue de las páginas de tal suerte que haga al sistema más lento, afectando así a la experiencia del usuario.

Con todo esto en mente, me puse a revisar algunas de las herramientas disponibles para PHP y decidí probar Twig. Este sistema de templates no sólo cubre en principio las tres cualidades que buscaba sino que además soporta una notación muy parecida a la que ya conozco (la de Django y Jinja), por lo cual me resultó menos complicado su empleo. El motor es fácil de instalar, sobre todo con el uso de Composer, y su funcionamiento, que actualmente estoy evaluando, me ha parecido satisfactorio.

Un motor de templates es una herramienta muy útil para construir sistemas porque ayuda a mantener una separación entre la presentación y la lógica de los sistemas. Esto permite distribuir el trabajo entre los desarrolladores que trabajan en la construcción de las mecanismos internos de un sistema y aquellos que se encargan de elaborar la interfaz de usuario del mismo. Además, el código fuente de ambas partes queda mejor ordenado y más limpio porque la combinación de markup con código de control generalmente hace que tengamos que separar mentalmente todas las líneas de código que son meramente de presentación de aquellas que realizan operaciones sobre la información. Esto, especialmente si hablamos de programas grandes, dificulta en alguna medida las tareas de mantenimiento que son intrínsecas a todo sistema.

Visita el sitio oficial de Twig.

Para leer en la compu

He estado usando Reader, en Windows 8.1, por ahora que estoy probando esta versión del sistema operativo. Hay ciertas cosas que me agradan de él (quiero decir, de Reader): tiene una buena velocidad de respuesta. Los subrayados se realizan rápidamente, con bastante precisión. La UI es muy simple y te ayuda a permanecer enfocado en el documento. Los documentos aparecen en pantalla completa. La interacción con la aplicación a través de la pantalla táctil es bastante natural y fluida (sobre todo considerando que lo estoy usando en una computadora con características muy estándar; nada del otro mundo).

Algo que no me ha gustado: la aplicación no almacena la ubicación (el número de página) en la cual me quedé al cerrar un documento. Al menos esto sucede con los documentos PDF y no sé si hay algo que yo debería hacer para que Reader guarde la ubicación de mi lectura. Por todo lo demás, la aplicación cumple muy bien con mis necesidades de lectura.

Reader: http://apps.microsoft.com/windows/en-us/app/reader/8a4ae377-a4ab-4260-9b80-f9382360e291

TDD para mayor certeza

La primera ventaja que he experimentado al usar Test Driven Development (TDD) es la confianza que uno siente de saber que al menos la suite de tests de un sistema sigue corriendo con éxito. Esa comprobación me ha permitido continuar con el desarrollo de más características con una mejor certeza sobre el buen funcionamiento y la consistencia del diseño en una aplicación que estoy construyendo. Aquí les dejo algunas de las reflexiones derivadas de mis lecturas recientes sobre agile development y el uso de tests dentro del proceso de desarrollo de Django, así como de la aplicación de tests en mi práctica de desarrollo de software.

Debo decir que no tengo mucha experiencia, aún, programando tests, tampoco soy un gran partidario de los tests exhaustivos, pero comprendo el gran valor del uso de estas técnicas. Sin embargo, no estoy muy dispuesto a realizar tests en varios niveles de un sistema en desarrollo, tampoco creo tener suficiente tiempo para ello. Pero si existe una forma te hacerlo que posibilite acelerar el ritmo con que se construye un sistema y al mismo tiempo hace más divertida esta tarea, entonces sí que me pongo a elaborar tests.

La aplicación de TDD en metodologías ágiles, según lo que he leído en días recientes sobre XP, me parece satisfactoria y práctica. Primero, la idea de hacer tests como una actividad cotidiana durante el desarrollo de un sistema, en la cual cada programador aporta los tests de aquello que le toca desarrollar, siguiendo la pregunta “¿qué es lo que podría fallar con esta modificación?”, esta idea, decía, es una buena aproximación al problema de hacer que los tests prueben lo que tienen que probar, es decir, es una manera útil de hacer que los tests, muy probablemente, se adecuen con mayor exactitud a la funcionalidad en cuestión, porque se construyen en en el momento mismo, antes, de hacer las modificaciones al sistema.

Luego, no es necesario esperar a que un departamento de pruebas dé su veredicto sobre el funcionamiento del sistema. Cada programador puede, cada vez que lo considere necesario, ejecutar la suite completa de tests del producto y detectar problemas inmediatamente. Hay que recordar que los tests deben estar automatizados y manejar un esquema común en el proyecto, justamente a fin de facilitar a todos la evaluación del estado actual del sistema.

Así, por ejemplo, después de algunas horas de haber elaborado un conjunto de tests para desarrollar una nueva característica, haber programado la característica en sí, correr la suite de tests y ver que todo sigue funcionando, el programador está listo para pasar a una nueva característica. Pero, por el contrario, si resulta que algún test empezó a fallar, en ese mismo momento el o los programadores involucrados seguramente contarán con información suficiente para resolver algún problema no previsto en sus aseveraciones y ponerse a trabajar en ello, hasta conseguir comprender la situación y hacer las correcciones necesarias. Todo en un mismo ciclo.

Como ya lo decía, no tengo argumentos para estar en contra de los tests. Sin embargo, sí considero que es importante optimizar el modo y la cantidad como se realizan. Cuando todo el equipo de desarrollo tiene la responsabilidad de elaborar los tests relacionados con cada funcionalidad que es incorporada o modificada en un producto, en mi opinión el proceso de escritura de tests se vuelve habitual y cómodo. Los programadores desarrollan mejores habilidades para identificar y analizar problemas y para diseñar sus soluciones, y aprenden la importancia que tiene contar con elementos de comprobación de que sus hipótesis y su trabajo parecen funcionar como se espera. En el camino, cada programador desarrolla mejores habilidades para programar tests.

Todo esto promueve una visión más experimental sobre la programación. Es importante resaltar que la actividad de programar está muy sujeta a la incertidumbre. Un desarrollador se ve enfrentado con un conjunto de requerimientos de los cuales puede o no conocer mucho. Con base en ello, elabora a su vez un conjunto de suposiciones sobre la manera de satisfacer dichos requerimientos. Las suposiciones se encuentran en varios niveles: pueden ser desde ideas sobre cómo podría resolverse un caso particular, hasta  asunciones sobre lo que se cree que aportará elementos de valor a un producto desde la perspectiva del usuario. El panorama puede ser muy complejo, y es por ello que la experimentación se vuelve una alternativa para posibilitar la construcción del producto. Considero que TDD puede ser una herramienta útil al respecto, básicamente porque su práctica consiste en la formulación de una o varias hipótesis sobre lo que puede fallar, luego,  en un proceso que implica otras hipótesis y comprobaciones en sí, se implementa el código que debe satisfacer el funcionamiento probado por el test y, con base en los resultados observados, se deciden nuevas actividades.

Estos son algunas de las impresiones y efectos que he notado a partir de que empecé a hacer un esfuerzo por aplicar Test Driven Development en mi proceso de desarrollo. Nada más queda por mencionar que ha resultado ser más interesante de lo que me imaginaba, y ya veo varias ventajas derivadas de este ejercicio. Construir una cultura de desarrollo de software empleando TDD no sólo implica un beneficio a nivel del software, sino que dota a los programadores de elementos metodológicos útiles para pensar la programación y su validación con un enfoque ágil. Esta es mi impresión general en estos momentos. Cunado las pruebas arrojen más resultados, estaré reportando lo que haya aprendido.

Hace mucho

Que no escribo para este blog, el único, hace ya mucho. Salía a andar en bici por la ciclopista en aquellos días. Han pasado cosas mientras tanto. Por suerte, las ideas han seguido fluyendo, el mundo de la programación me ha revelado sus encantos, la computación ya no es un todo, la vida en equipo y en grupo es clave, pero sigue siendo una umbral que hay que cruzar.

Hace unos días me encontré el Python Brochure. Ese encuentro me hizo pensar en el tiempo que llevo programando y también en el que he sido un sysadmin con pretensiones de DevOps guy. Durante esos 6 a 8 años Python ha estado entre mis principales intereses. Recuerdo que un día me encontré en internet un tutorial para aprender a construir aplicaciones con interfaces gráficas usando Python y Tcl. No terminé de leer el tutorial, pero a partir de eso decidí volver a ser becario en desarrollo de sistemas en la Universidad. En el proceso, leí el tutorial oficial de Python.

Un día apareció la siguiente gran revelación. Necesitaba construir una aplicación web rápida y confiable para un proyecto en el cual colaboro. Me puse a buscar qué alternativas había en torno a las necesidades que tenía identificadas. Mi experiencia con PHP y PostgreSQL ya me permitían sopesar las posibilidades de lo que encontrara empleando ambas tecnologías en combinación. También había ya ganado experiencia con JavaScript y diseño de páginas web. Por otro lado, tenía el interés de aprender algo nuevo. Entonces empecé a pensar en Python.

Nunca había usado Python extensivamente para algo, pero desde la vez que leí el tutorial, un par de veces, me encantó la manera en que estaba diseñado el lenguaje. Cuando recordé que un día, en un curso que tomé siendo becario, alguien mencionó un framework para desarrollo web llamado Django, me metí a internet a ver qué podría ofrecer esa herramienta. La sorpresa fue grande, muy grande. En unos pocos minutos, siguiendo el tutorial, había elaborado un blog con una capa de abstracción flexible y potente hacia la base de datos. El manejo de las clases principales era simple y claro. El diseño de la aplicación me pareció limpio y elegante.

Sin dudarlo más, ese mismo día empecé a programar la aplicación con Django, siguiendo los excelentes manuales disponibles en la documentación, hará ya unos tres o cuatro años. Los resultados que he obtenido con ello han sido grandiosos. Programando con Python y Django he aprendido las mejores prácticas que empleo en desarrollo de aplicaciones y he conocido con mucho mayor detalle cómo funcionan las tecnologías web, y cada día que los utilizo aprendo cosas nuevas sobre programación y desarrollo de sistemas. El software construido es confiable y el respetar los estándares propuestos por la comunidad de Python me ha permitido escribir código ordenado, conciso, limpio y funcional.

Pero eso no es todo. Las herramientas desarrolladas por la comunidad de Python son excepcionales. He trabajado con ReportLab, Fabric, Gunicorn, Tastypie, Django REST Framework, Virtualenv, entre otros. Lo más notable de estos módulos es la simplicidad y la potencia que ofrecen para trabajar. Amabas palabras, “simplicidad” y “potencia”, tercera vez que las menciono a menos de 10 palabras de distancia una de la otra, son quizá las que resumen mejor la forma en que pienso acerca de las tecnologías que conozco desarrolladas con Python, incluido Python mismo. No dejo de asombrarme cada vez que reviso la documentación de esta o aquella librería y encuentro lo bien pensadas que están las funciones en estas herramientas al mismo tiempo que se puede hacer mucho con poco código. Eso me gusta de Pyhton.

Otra cosa que disfruto de Python es su cultura. En ella, cada pieza de código es una manera de comunicar, no sólo de hacer. La filosofía batteries included, según la cual la librería estándar debe ser rica y versátil, todo ya incluido, ayuda a maximizar las posibilidades del programador. No han sido pocas las veces que me he dicho “debe haber algo que lo hace en Python” y que he acabado encontrándolo en la librería estándar. La brevedad del lenguaje y la iniciativa por la comunidad para definir lineamientos de diseño y estilo motivan la claridad y el balance del código programado en Python. Basta ser un poco afín con estos valores para adoptar prácticas valiosas que después se generalizan a la utilización de otros lenguajes, e incluso a otras actividades ajenas o cercanas a la programación.

Hay que recordar que cada quién tiene sus gustos. En mi caso, Python es uno de ellos. Para mí, es una fuente de inspiración, de aprendizaje y de desarrollo. Y hay que mencionar aquí, ya para cerrar,  y por si faltara más, que las tecnologías que he mencionado en este escrito son libres y gratuitas mayoritariamente. Por eso me atrevo a recomendarles Python ampliamente este día, esperando que aquellos que no lo conocen descubran una gran herramienta para hacer sistemas y pensar en otras cosas.

Consejos para el ciclismo de calle

Llevar la bicicleta a la calle, ya sea para dar un paseo o para transportarse, usándola como remplazo del coche o el transporte colectivo, es algo que, sin duda, requiere un grado determinado de experiencia y dominio del vehículo de pedales. Es fácil encontrar en Internet muchos artículos que hablan al respecto, muchos de ellos provenientes de países donde la bicicleta se usa con más frecuencia como una alternativa común de transporte. Se me ha ocurrido escribir una reseña más sobre el mismo tema porque en los últimos días he tenido la oportunidad de irme pedaleando al trabajo, de modo que, con cuatro o cinco viajes, poca cosa realmente, puedo decir que tengo una primera impresión de lo que es necesario conocer para salir al camino con un grado básico de seguridad. Finalmente, no me atrevería a manejar entre los coches si no me sintiera capaz de hacerlo. Será una reseña más sobre el mismo tema, pero espero que sea de provecho para el ciclista que aventura sus primeras salidas en el tránsito citadino.

En primer lugar diré que es un buen aliado el conocimiento del manejo y, más aún, la experiencia al volante, no en la bici sino en el coche. Es de gran ayuda saber cómo se comporta el tránsito vehicular, cuáles son las reglas de manejo comúnmente usadas, el reglamento de tránsito, la manera de dar avisos a los otros choferes, las respuestas repentinas que son frecuentes en el camino, como el momento en que alguien se va a dar la vuelta, o se va a estacionar, sin avisar, o que el colectivo va a detenerse porque hay gente haciendo la parada o lista para descender, cosas por el estilo. También es importante porque nos permite entender lo que es manejar al lado de otro tipo de vehículos; sabemos así que aveces no es tan obvio que hay un ciclista pisandonos los talones y que si nos movemos descuidadamente, y el ciclista también es descuidado, no será cosa justa echarse toda la culpa de un incidente. Es necesario, pues, conocer la perspectiva del chofer para tomar en cuenta su posibilidad de detectarnos en todo momento.

Otra cuestión importante es la del esfuerzo. Pienso que es importante, igual de importante que en el entrenamiento, tener en cuenta siempre la posibilidad de abusar de la capacidad que uno tiene. Debe ser muy peligroso si, por un sobreesfuerzo, a mitad de la calle sufrimos un mareo o, peor aun, una baja en las capacidades de respuesta o ejecución. Más vale manejar tranquilamente, cuidando no obstruir el flujo de los coches, a un ritmo que nos garantice nuestra mejor marcha sin excedernos en la intensidad. La mayor amenaza de no respetar el trabajo que nuestro cuerpo soporta sería la de sufrir una caida o un choque por el déficit en los mecanismos de respuesta o de control, o, incluso, sufrir un desmayo a causa de un esfuerzo mal atendido. Más aún, este cuidado es indispensable en toda actividad física que se realice; por sí solo, el sobreesfuerzo es ya un riesgo grande para la salud. Igualmente, es recomendable llevar una buena alimentación y dormir lo suficiente para no tener deficiencias energéticas que puedan tener un efecto en el mismo sentido.

Hay que llevar consigo lo más indispensable para superar los incidentes más comunes del ciclista. La llanta ponchada requiere de parches, desmontadores, bobma de aire, aveces hasta una cámara nueva y, desde luego, el conocimiento de cómo realizar la reparación. Es bueno llevar alguna llave de tuercas ajustable (perico), puede ser una pequeña, para poder corregir cualquier desajuste sufrido por una tuerca mal apretada o para poder realizar alguna reparación no prevista pero simple. Los tornillos tipo Allen son muy usados en el ensamblaje de bicicletas, por eso es indispensable tener un paquete de llaves para las medidas más frecuentes (generalmente 3, 4, 5 y 6) en nuestra bicicleta; hay que revisar cuáles son y tenerlos siempre a la mano. Dos desarmadores a la mano, uno plano y uno de cruz, siempre nos pueden salvar de muchos apuros. Es bueno también llevar agua, casco, gafas y guantes, así como un teléfono celular, dinero y una ficha técnica con información nuestra: datos personales, tipo de sangre, especificaciones sobre alergias o padecimientos, teléfonos a los cuáles llamar por si ocurre un incidente (tanto de centros de atención médica como de familiares o conocidos que puedan acudir en nuestra ayuda). Este es el paquete de cosas que usualmente llevo conmigo para los recorridos recreativos o de entrenamiento, desde luego que también para salir a la calle para recorrer distancias largas o muy transitadas.

La seguridad es un asunto de previsión, por eso es importante tener siempre un conocimiento claro de las condiciones en las que se encuentra nuestro vehículo. Tener la certeza de que no nos falta ningún tornillo, de que todas las tuercas están bien ajustadas y que las llantas están en buen estado, entre otras cosas, no sólo nos garantiza mayor seguridad de no sufrir algún incidente, sino que nos brinda mayor confianza de que somos menos propensos a uno o, en todo caso, de que una falla no será tan grave como para ponernos en peligro. Es una buena práctica pasar una revisión periódica y cuidadosa de todos los tornillos y tuercas de la bicicleta, revisar la presión de aire de las llantas, checar que los desviadores de la cadena no están torcidos, que los chicotes y zapatas de los frenos están en buenas condiciones, que la superficie de las llantas no está demasiado lisa, ajustar los conos y tazas de todos los baleros que lo requieran, mantener los rines alineados, agregar grasa y aceite a todos los puntos que lo necesiten y tener la bicicleta limpia para poder hacer todo lo anterior con menores reservas y mayor precisión. Es de gran ayuda contar con algún taller de confianza en el que nos puedan asesorar acerca de tales cuidados y donde podamos llevar la bici para reparaciones que requieran mayor experiencia. Adicionalmente, recomiendo la sustitución de piezas cuyo estado ya no es tan óptimo como para seguir haciéndoles enmendaduras (esto no solo va para la bici), sobre todo cuando alguien con experiencia nos lo indica; generalmente es la vía más costosa a corto plazo, pero pienso que muchas veces resulta más caro, a la larga, hacer reparaciones improvisadas como amarrar con alambres, hilos o cintas adhesivas, pegar piezas rotas, usar aditamentos o sustancias que no son adecuadas para una bicicleta, entre otras coas. Este es mi punto de vista, pero confío más en el gasto oportuno, siempre y cuando sea posible, claro está.

En forma resumida, presento aquí una lista de los puntos que considero importantes para manejar un poco más seguros en la calle. En primer lugar, atiendo a las capacidades del ciclista. Es importante el dominio de la bicicleta, por ello cabe destacar las siguientes habilidades:

  • Capacidad de manejar con una mano, cualquiera que ésta sea, y hacer cosas con la otra: cambiar de velocidad, tomar un objeto sobre una mesa, acomodarse los lentes o el casco, etc.
  • Habilidad para voltear hacia atrás por cualquiera de los dos lados y en cualquier posición que se maneje. Esto es importante porque nos permite “espejear” para hacer cambios de carril, detenerse o, simplemente, saber qué tenemos atrás. Es lo mismo que hacemos al manejar en coche.
  • Desde luego, experiencia de la bicicleta en distintas circunstancias. Es bueno haber manejado muhcas bicicletas y tener mucha experiencia a bordo de una, pero es aún mejor conocer bien la bici que usamos con mayor regularidad, cosa que se logra con el uso mismo.
  • Contar con una buena condición física es, a la vez que un fin, un buen principio. Esto nos garantiza que seremos capaces de enfrentar cualquier situación imprevista, como, por ejemplo, tener que dar un rodeo por calles inexploradas a causa de un cierre de las vías que acostumbramos utilizar; si nos topamos con pendientes espantosas o con que el camino es mucho más largo de lo que esperábamos no será gran problema, mas allá del tiempo, si nuestro cuerpo está acostumbrado al ejercicio.
  • Conocimiento del reglamente de manejo, experiencia al volante y con los hábitos de manejo comunes de nuestra comunidad.

Sobre los hábitos del ciclista es importante tener algunas consideraciones:

  • Dormir bien y alimentarse sanamente.
  • Tomar abundantes líquidos, no sólo cuando se maneja sino también en nuestra vida cotidiana.
  • No lo he mencionado pero, como usualmente pasa, es mejor salir con tiempo de sobra que ir a toda prisa, poniendo en riesgo no sólo a nosotros mismos sino también a los peatones u otros animales que circulen por la calle. Más vale ir con calma, y la anticipación suele ser un buen inicio.
  • Otro punto que no he mencionado es el del gusto por el paseo. Es bueno disfrutar del recorrido y del gusto que da ir en bicicleta. Mientras mantengamos la atención en lo que hacemos, es una buena práctica hacer de cada recorrido una aventura emocionante. Eso depende de muchos factores, pero un punto de partida es la disposición del ciclista para pasar o no un buen momento. Procuren estar tranquilos y tomar con buenas expectativas la bicicleta siempre que estén a punto de iniciar su viaje.

Acerca del cuidado de la bicicleta, retomo los siguientes puntos:

  • Hay que vigilar el buen estado de la bici. Garantizar que nuestro vehículo (incluso si nos lo han prestado) goza de buena salud mecánica nos dará seguridad y confianza.
  • Es recomendable realizar, siempre que esté a nuestro alcance, todas las reparaciones que sean necesarias, usando tanto las piezas como el equipo adecuado.
  • Es bueno contar con un buen mecánico, para dirigirnos a él siempre que tengamos alguna duda o para que se encargue de las reparaciones que desconocemos.

El equipo de seguirdad es importante:

  • Llaves Allen de las medidas más usadas en la bicicleta que tenemos.
  • Una cámara de llanta, por si es necesario renovarla a consecuencia de una ponchadura.
  • Desarmadores, plano y de cruz.
  • Llave perica pequeña que ajuste con todas las tuercas de nuestro vehículo.
  • Parches y desmontadores para llantas.
  • Ficha de información personal: datos personales y médicos.
  • Casco, gafas, guantes y agua. No lo mencioné arriba, pero es adecuado usar accesorios que nos hagan más visibles para otras personas, como ropa con colores brillantes y reflejantes en la bicicleta.

Con esta serie de recomendaciones considero que tenemos un buen principio para poder aventurar nuestros primeros viajes en la calle, entre los coches. Sin embargo, estoy seguro al afirmar que sólo he citado aspectos de los más esenciales. No he dicho nada, por citar algunos casos, acerda de las recomendaciones para manejar de noche, del cuidado que hay que tener cuando vamos en lugares con alta densidad de peatones, de la forma de evitar o prevenir el ataque de los animales que usalmente asechan al ciclista, de la protección de la bicicleta contra robos, entre otras cosas. Es grande la lista de factores que será bueno considerar al momento de afrontar nuevas situaciones en la bicicleta, y esto también dependerá de los fines con los que lo hagamos, pero espero que el lector encuentre una buena guía de entrada para abordar una situación que muchas veces es tomada a la ligera. Espero que les sea de provecho, y ¡pásenla bien con su bicicleta!

Algunos enlaces interesantes:

http://www.sheldonbrown.com Un sitio en inglés con información diversa y divertida sobre el ciclismo. Para aficionados o profesionales, esta página es excelente por la gran diversidad de temas que aborda.

http://www.ciclosmaestre.com/mecanica/manual-indice.asp Un manual de mecánica sencillo y muy bueno para aprender a cuidar de nuestra compañera metálica de dos ruedas.

http://www.state.il.us/kids/isp/bikes/default.htm Instrucciones en inglés sobre distintos aspectos de seguridad en la bicicleta, formas de comunicarse con los automovilistas, aditamentos de seguridad, entre otras cosas.

http://bicyclesafe.com Un subtítulo de la página: How to Not Get Hit by Cars (Cómo evitar ser golpeado por los coches). No se necesita más explicación.

El título por fin

Generalmente se empieza por saber qué es lo que uno quiere escribir, el tema. Lo que me ha puesto en dudas este día es la manera de iniciar el escrito; si se empieza por el contenido o por la forma, si ha de darse a conocer, uno mismo, el título o el argumento en primera instancia, el párrafo primero o el concluyente, su última frase.

Mi caso es impreciso. Unas veces empiezo por escribir los párrafos, sin saber todavía qué título los ha de introducir, les ha de determinar una primera impresión, comprometiendo todo su sentido, incluso; otras veces ideo un título, hasta me atrevo a escribirlo, pasan días, varios días, y no tengo la más remota impresión de lo que ese título quiere nombrar, no siembra más palabras en mi espíritu que aquellas cuya combinación lo hacen algo, una frase, casi vil, aunque tenga la intuición de un tema oculto, glorioso, actual o interesante. Tan engañoso es esto.

Un caso contrario, por ejemplo, es el título para este escrito. Hace unos mínutos no me imaginaba escribiendo algo que tuviera que ver con títulos y párrafos y significados, órdenes y secuencias, ni siquiera me proyectaba, en ese pasado próximo, aunque al mismo tiempo inalcanzable, pues del tiempo formó parte y es de lo que está hecho, como la memoria, escribiendo para este preciso momento. Es decir, soy sincero, no sabía que algo iba a escribir, y sigo sin saber qué más he de escribir. Ya me doy una idea de esto y de aquello, pero siento que son las palabras las que me guían, me figuro como si así fuera. Decía que el título de este escrito es mi ejemplo; no conozco aún las palabras que deberían aparecer al principio, dos o tres, cuatro, esa conjunción de morfemas y lexemas que logren el sentido apropiado para el resto, sentido del cual me han hecho víctima y, por ello, quisiera poder presentar ante el lector.

Pero no lo encuentro. El título para esto está tan perdido como la siguiente oración, sólo vislumbro sus aristas, no todas, de hecho, tampoco su color o su tamaño. Cuando termine tal vez piense dos o tres minutos para averiguarlo. A veces pasan dos palabras, en los últimos párrafos, cuyo conocimiento, de que son los últimos, también me es revelado de forma inadvertida, y de repente, cuando menos lo esperaba, ahí está, concebido, el nombre para nombrar a todas las oraciones juntas. Lo que estoy diciendo, pues, es que probablemente no soy bueno como escritor ordenado, que no escribo con plena conciencia de lo que voy a hacer, sin sistema y sin planeación.

No siempre. También las hay, redacciones mías, que fueron concebidas a la manera de una buena receta, sabiendo desde un principio lo que deseaba obtener, un pastel, por ejemplo, el más típico, por cierto, un pastel de crema de cacao con nueces, un rico baño de tres leches bien preparadas, crema untada en sus paredes internas, atrapada hasta el momento de ser comida, atrapada otra vez. Pastel de crema de cacao, se hace con esto y con esto otro, y se hornea y se deja reposar, úntese suavemente los ingredientes, en muy resumidas cuentas. Quizá mis escritos no sean tan buenos como delicioso, yo creo que sí, mi ejemplo, pero esto ilustra, tengo la esperanza, lo que quiero decir.

Volviendo a lo iniciado, me doy cuenta de momento que tal vez muchos escritos son así. Pienso que es bueno anticipar las palabras, pero a veces debe ser un buen ejercicio dejar que las mismas se entreveren, se intrinquen, escribiéndolas como aparecen cuando parecen venir de ninguna parte, por mera generación espontánea, casi. Con orden o sin él, las frases se van componiendo, construyen un significado, me sugieren una manera de continuar y un nombre. Al final o al principio, me atrevo a decir que es una cuestión secundaria, más no irrelevante, sobre todo cuando se quiere hacer algo sistemático, la del orden de la escritura. Será necesario practicar el ejercicio de la planeación, conocer sus reveses y sus frentes, sí, pero también será vlioso encontrar algún sentido en donde antes no lo había.