Antipatrones Software Noviembre 22, 2009
Posted by ravelus in Informática.add a comment
Un patrón software es una solución común, adaptable y probada para un problema conocido. Algo así como una plantilla de encaje que se ajusta a según qué condiciones (fuerzas y contexto) de manera que aporta una solución (diseño) implementable y ejecutable (software).
Un antipatrón es precisamente lo contrario. Dicho así de pronto parece claro que es algo así como un “lo que no hay que hacer” y que por tanto lo que voy a tratar aquí es un compendio de malas prácticas. Pero un antipatrón no es exactamente esto. Existen muchos libros que tratan de buenas y malas prácticas: en análisis, en diseño, en implementación, en pruebas… Un antipatrón no es una mala práctica, aunque su consecuencia es un mal diseño y por tanto puede abocar al fracaso de un producto software.
Un antipatrón es la aplicación de un patrón software bajo unas precondiciones erróneas, es decir: la aplicación de un patrón software en un contexto equivocado. Es algo así como decir: “tu intención era buena peeero no estudiaste bien las fuerzas y el contexto que intervenían en tu situación particular, y por ello tu solución es inadecuada”.
Bueno, esto parece diferente a lo que tradicionalmente considerábamos como mala praxis en el desarrollo software, y parece tener algo de atractivo. En estos momentos estoy leyendo un librito que trata este tema, y a medida que encuentre temas interesantes que pueda publicar lo haré. Veamos si no es un palabro más inventado para escribir libros y ganar dinero.
Lo que expongo a continuación es un breve resumen de patrones y antipatrones extraídos de la fuente que anexo al final del artículo. Para ir abriendo boca.
Patrones:
Cultura de reutilización: trata precisamente de establecer una política de reutilización de software y de que todo el equipo desarrolle pensando siempre en que sus artefactos son susceptibles de ser reutilizados.
Artefacto robusto: un elemento bien documentado, construído para alcanzar los objetivos y necesidades generales en lugar de limitarse simplemente a los objetivos específicos.
Generalización automotivada: Tratar de pensar en la generalización a la hora de desarrollar, en facilitar elementos que se puedan utilizar as-is.
Ingeniero senior de reutilización: es aquel que pone en práctica los patrones anteriores.
Antipatrones:
Artefacto no reutilizable: No sólo es aquel que no es reutilizable porque no se pensó en ello, sino que también es aquél que se pretendió que fuera reutilizable pero que en realidad no lo es (y esto último es más importante y más grave).
Reutilización orientada a repositorios: La creencia de que simplemente por crear una especie de almacén de piezas software que se pueden reutilizar, la reutilización viene de forma automática.
Síndrome del No-Está-Hecho-Aquí: Los desarrolladores desconfían del trabajo hecho por otros y tienden a desarrollar por sí mismos artefactos software que ya están hechos.
Reusabilidad declarada: La creencia de que algo es reutilizable simplemente porque lo digo yo o lo dijo alguien…
Reusabilidad orientada a incentivos: Una vez más, ofrecer incentivos para que los desarrolladores hagan software de mayor calidad (en este caso, reutilizable) no es el camino, pequeño saltamontes…
Producción antes de consumición: Algo así como que la reutilización vendrá por sí sola en cuanto empieces a pensar en desarrollar artefactos reutilizables. La realidad es que es necesario invertir fuertemente para que la reutilización sea un hecho probado: dedicar recursos y soporte.
Reutilización solamente de código: Creer que lo único susceptible de ser reutilizado es el código.
Reutilización orientada a proyectos: Limitar la generalización que lleva a construir artefactos reutilizables solamente como decisión que incumbe al ámbito del proyecto para el cual se desarrolla dicho artefacto.
Referencias:
http://www.sdmagazine.com/uml/thinking/s0002to.shtml
Revista Dr Dobb’s, actualmente la fuente no está disponible. El artículo lo encontré por ahí… lamento no poder facilitar más las cosas.
HowTo: Connect to a VPN in Linux Noviembre 10, 2009
Posted by ravelus in Informática.add a comment
Foreword
The following steps works fine in Ubuntu 8.04 Hardy. You should not have any problem in other versions.
Install required packets
First of all, we need to know which is the VPN infrastructure to connect. Depending on it, we’ll distinguish between 3 different cases:
A) – openVPN.
B) – Windows VPN
C) – Cisco VPN.
Once we certainly have this information, we can download the appropiate package:
A) – sudo apt-get install network-manager-openvpn
B) – sudo apt-get install network-manager-pptp
C) – sudo apt-get install network-manager-vpnc
If your distribution is not Ubuntu, try to search those packets in Synaptics, YaST or whatever.
After installing them, you should see a net icon in the status bar. Click on it and create a VPN connection. Introduce all the information provided to connect to your server and proceed as you would do in Windows.
When you have finished, click again in the net icon in the status bar and select your connection. The system will ask for your credentials. Type them and enter. Quite simple.
Useful links
http://www.cs.umn.edu/help/offsite/vpn.php#ubuntu_config
This is a useful link with a very simple tutorial including snapshots. In the examples it explains how to connect to a Cisco VPN, but the other cases are quite similar.
Here you can find information about packages to install and things like that.
Lanzarote, fuego por dentro Octubre 18, 2009
Posted by ravelus in Cultura, Experiencias.add a comment
Hace poco menos de un mes estuve con mi novia de vacaciones en Lanzarote, una de las islas que, como todos saben, conforma el archipiélago canario. Disfrutamos de un tiempo espléndido, visitamos lugares muy interesantes y cenamos a cuerpo de rey. Quería compartir aquí mi experiencia desde un punto de vista más o menos objetivo, para que futuros visitantes de la isla puedan tener un punto de referencia acerca de qué ver, qué comer y dónde hospedarse.
Hospedaje
Nosotros elegimos un apartotel por la privacidad de tener nuestra propia casita y el precio de este tipo de hospedajes. Encontramos una buena oferta en Sun Park en régimen de alojamiento y desayuno, por 16€ cada persona. Un precio muy asequible teniendo en cuenta que las habitaciones incluyen una pequeña cocina con todos los utensilios necesarios para preparar comida. Además el complejo hotelero tiene varias piscinas, salas de reunión, parques para los críos y demás. Situado en Playa Blanca, al sur de la isla, en dirección a Playa Papagayo.
Qué comer
Algunos días cenamos en los numerosos restaurantes que se ubican en el paseo marítimo de Playa Blanca, con vistas al mar y todo el pastel. Alguna vez elegimos pescado del día, como no podía ser de otra manera, y no nos decepcionó en absoluto. Cherne (como allí llaman al mero) fino, suave al paladar, aunque es más típica la Vieja. Los precios varían entre restaurantes levemente, pero en general se come barato y bien.
Qué ver
Montañas de fuego.

Vista del parque nacional de Timanfaya y el Atlántico al fondo
En pleno parque nacional de Timanfaya, en el centro de la isla, existe una ruta en autobús, por 8€ que le mostrará el árido y virgen desierto rojo de la isla, suelo protegido por la Unesco como Reserva de la Biosfera. Es algo fuera de lo común para los que vivimos en la península, y puede merecer la pena por ello; pero van a ver eso mismo: desierto.
La Cueva de los Verdes.
Un paseo de aproximadamente 1km por el interior de cuevas rehabilitadas por César Manrique, artista polifacético y gran defensor de la isla. En su interior no veremos las típicas estalactitas y estalagmitas, sino marcas de los ríos de lava que quedan de las últimas erupciones de la isla, allá por el siglo diecinueve. Todo decorado con luces de colores, da un aspecto bastante curioso. Lo del nombre de los Verdes es algo muy curioso que… no, es mejor que vaya y se lo cuenten. Cuidado con los desfiladeros, en algunos, inexplicablemente, no hay barandilla… Precio: 8€.
El volcán de Caldera blanca.
Ruta de senderismo a través de Timanfaya, por un auténtico pedregal que desemboca en los volcanes de Caldera Pequeña y Caldera Blanca más adelante, los volcanes con mayor altitud de la isla, a unos 500m de altura. Muy recomendable llevar bastón y calzado adecuado, esto es: botas de montañismo, no zapatillas deportivas. Dificultad: media, por la ascensión al cráter y el suelo pedregoso, no apto para tobillos frágiles.

Interior del volcán de Caldera Blanca
Jameos del agua.
Bueno, pues otra bajada a una gruta con un estanque subterráneo donde se aloja una especie endémica de cangrejo canijo y blanco. Los jameos son precisamente las salas subterráneas que la lava fue creando a su paso por debajo de la tierra y que después han quedado al descubierto al derrumbarse los techos de roca. Incluye un pequeño centro de interpretación donde aprenderemos cómo funciona el asunto del volcanismo, la formación de la isla y demás. Precio: 8€.

Jardín de cactus
Jardín de cactus.
Alberga miles de especies de cactus recogidas de todos los rincones del planeta, a cada cual más curioso. Precio: 6€.
Y para terminar…
… puede dar un paseo en camello por las áridas arenas de Timanfaya; el precio es de 12€ el alquiler del camello, en el cual pueden montar dos personas.
Malditos bastardos… Octubre 3, 2009
Posted by ravelus in Cultura.1 comment so far
El pasado domingo fui al cine a ver Malditos Bastardos, de Tarantino. Qué peliculón. Merece la pena pagar los 6 euros que cuesta la entrada para ver una película así. Aunque he de reconocer que me dolió un poco. Tarantino es uno de esos directores cuyas películas no se recuerdan por ser maravillosas en su conjunto, grandes historias, impresionantes personajes, no.
Tarantino hace películas de las que todo el mundo recuerda tal escena, o tal otra porque son pasajes, simplemente, geniales.
Aquella de Kill Bill donde ruedan cabezas por todas partes, o aquella de Pulp Fiction en que Samuel L. Jackson recita
un pasaje de la biblia, o la escena del coche, o tal otra… son escenas magistrales, en las cuales todo es sencillamente,
para enmarcar en un museo: los diálogos, los personajes, la situación.
Tarantino sabe sacar lo mejor de cada actor; en sus películas vemos al mejor Travolta, Jackson, Thurman, Willis, y por qué no decirlo, Pitt. Algunas de las mejores interpretaciones de estos actores están en sus películas.
Alguien me dijo hace poco, discutiendo sobre esta película, que la diferencia entre Robert Rodríguez y Tarantino, buenos amigos por cierto, es que la violencia de Robert Rodríguez es previsible y bestial; la de Tarantino es bestial, pero es imprevisible. De repente un personaje muere así, sin avisar; o una situación tranquila se convierte en una matanza. Y sin embargo no hay violencia gratuita; todo tiene un sentido y un por qué, y al final todo encaja, y las pequeñas historias cuadran, y el resultado es un todo que como las fractales en matemáticas es bello en sus niveles más elementales y bello en el todo que conforman.
Hay quien dice que esperaba más de esta última, que las tiene mejores, que es una pequeña decepción… yo no soy un cinéfilo devoto de Tarantino, pero bajo mi ignorante punto de vista es una película magistral, donde lo fundamental a destacar es el personaje de Hans Landa (Christoph Waltz), un general alemán. Digno de estudiar minuciosamente cada gesto, cada movimiento de este impresionante actor políglota (además de alemán, habla perfectamente francés, inglés e italiano). Bajo mi parecer, un digno merecedor del Óscar al mejor actor secundario.
Además, nuestro medio hispano Daniel Brühl se confirma como un actor de los grandes, y eso nos debe llenar de orgullo. Su papel es menos importante que en otras películas como Salvador o Goodbye Lenin, pero hace un buen trabajo.
Brad Pitt hace una buena puesta en escena, se nota que se ha preparado a conciencia su personaje, pues quien espere ver al típico guaperas sonriente y pillín está equivocado; verá a un Brad Pitt rocambolesco, entre Ace Ventura y Marlon Brando en El Padrino.
No sé si serán de los que se deja caer regularmente por las salas de proyección, o son más de palomitas, manta y sofá, o de los de compartir contenidos libremente en la Red; en cualquier caso, vean esta genial obra maestra.
P.D.: A título personal, quiero pedir perdón por mi ausencia de varios meses… espero estar a partir de ahora más atento al blog; de todos modos, gracias a los que en este período de hibernación (como diría el bloguero de Kriptópolis) no han dejado de visitar esta humilde página; apenas he caído poco más de 10 visitas diarias. Esto significa dos cosas: o bien que tengo tan pocas visitas que menos no puedo tener, o que el paro está haciendo estragos y la gente tiene poco que hacer. En cualquier caso, gracias por visitarnos, vengan cuando quieran.
10 Buenas prácticas de Testing Julio 26, 2009
Posted by ravelus in Informática.1 comment so far
Probar un sistema implica simular ese sistema, asegurarnos de que tal sistema hace lo que debe y no hace lo que no debe. Implica un análisis con el propósito de encontrar problemas y errores, medir la funcionalidad y la calidad, capacidades, etc.
Una cuestión muy importante a considerar es que no se puede probar todo. No existe el producto perfecto, siempre tenemos que hablar en términos relativos o porcentuales, como por ejemplo, tasas de error. El proceso de pruebas es un proceso creativo y difícil; es importante planificar qué se va a probar, definir qué escenarios se va a probar. Finalmente, es importante dedicar tiempo y recursos suficientes a dicha tarea.
Diez buenas prácticas:
1.- Haz de la autoevaluación del trabajo de cada uno una responsabilidad de equipo. Insiste en que Test y Evaluación (T&E) forme parte del trabajo diario de cada uno (utiliza smoke tests para apoyarte en ello). Es necesario garantizar la producción de trabajo de calidad todo el tiempo.
2.- Establece cuanto antes un plan integral de pruebas y evaluación. Establece pautas, objetivos y entregables de cada tipo de test. Puede establecerse en sesiones RAD (Rapid Application Development) al comienzo o en sesiones de tormenta de ideas.
3.- Realiza un parte preventivo de pruebas de todo el trabajo especificado. No dejes nada sin cubrir; haz escenarios de todo; esto también te ayudará a entender mejor los requisitos. Inspecciona periódicamente los test y su adecuación al comento de desarrollo actual. Desarrollo y pruebas van de la mano: crea los casos de prueba antes de desarrollar.
4.- Utiliza las pruebas como indicadores de progreso. Que las pruebas te sirvan como indicador seguro de que algo está hecho y funciona.
5.- Haz un inventario de los objetivos de las pruebas y diseña para “testabilidad“. Diseña una lista de qué debe ser probado antes de diseñar o implementar otra cosa.
6.- Prueba desde el principio y a menudo. Así retroalimentas el desarrollo y detectas problemas en el momento en que ocurren.
7.- Diseña y desarrolla test como si fueran entregables. Con la misma disciplina y método. Desarrolla test en paralelo con el código, actualiza los test cuando el producto cambia. Si escribes los test demasiado pronto, luego habrá que redefinirlos, así que tampoco es bueno adelantarse demasiado. La ingeniería de desarrollo de test es igual que la ingeniería de cualquier producto software.
8.- Provee herramientas y soporte adecuados para el testing.
9.- Mide costes, cobertura, resultados y efectividad de los test. Así entenderás mejor el proceso de testing y podrás controlarlo y gestionarlo.
10.- Entrena y gestiona al equipo. Así se tomarán el testing como algo serio y conocerán qué se espera obtener de dicha tarea. El gestor indica guías, la dirección a seguir, qué pasos dar, etc.
Referencias:
The Little Book of Testing, Vol I, varios autores.
Errores comunes en desarrollo software (IV y final) Julio 11, 2009
Posted by ravelus in Informática.add a comment
Por parte del producto como objetivo final nos encontramos con los siguientes problemas:
- Requisitos de “placa dorada”. Requisitos no tan importantes para el usuario como nosotros pensamos, obsesión por el desempeño y otros factores que como informáticos puedan parecernos clave pero que un usuario no valorará tanto. Alargan la calendarización, y si les damos demasiada importancia, restaremos valor a otros requerimientos clave para el cliente.
- Inestabilidad de los requisitos. Algo presente siempre, por lo tanto es fundamental vigilar y controlar los cambios en los requisitos. Alarga la calendarización.
- Desarrolladores de “placa dorada”. Los programadores suelen estar ansiosos por utilizar una nueva tecnología, herramienta o técnica que ha aparecido en el mercado, aunque no sea necesaria para el proyecto. La investigación en nuevos campos conlleva gran incertidumbre, y esto alarga la calendarización, además de aumentar riesgos.
- Negociaciones de tira y afloja. Es extraño que cuando se negocia un deslizamiento en la estimación de un producto automáticamente alguien añade nuevas funcionalidades, lo cual invalida la nueva estimación…
- Desarrollo orientado a investigación. Si quieres desarrollar proyectos, no te sumerjas demasiado en investigar nuevos algoritmos, técnicas, etc. El riesgo de fracasar o ralentizar el proyecto es muy elevado. Desde luego que, si no te queda más remedio hazlo, pero cuenta con el riesgo que ello conlleva y desde luego no esperes terminar el proyecto en un tiempo récord, precisamente.
Finalmente, en cuanto al factor tecnológico:
- Síndrome de la bala de plata. No dejes que los equipos confíen demasiado en una nueva técnica, herramienta, etc. como si fuera la solución de todos los problemas. Las balas de plata no existen en informática; no creas lo que te venden los comerciales…
- Ahorros sobreestimados de nuevas herramientas o métodos. Las organizaciones no mejoran su productividad a grandes saltos, sino en pequeños avances; entre los inconvenientes de utilizar nuevas tecnologías están: riesgos de utilizar algo tan novedoso que pueda no tener soporte para el cliente, adecuación, curva de aprendizaje, etc. Otro ejemplo de esto podría considerarse el reutilizar software. Nuevamente, el ahorro no es tan grande como se podría prever en un primer momento.
- Cambiar las herramientas a mitad de proyecto. Casi nunca funciona bien. La curva de aprendizaje, rehacer el trabajo ya hecho, errores inevitables cometidos por el desconocimiento de la herramienta… ralentizan el proyecto.
- Falta de control automático del código fuente. Expone al proyecto a riesgos innecesarios. Es fundamental utilizar un buen software de control de versiones, junto con una buena política de gestión de configuraciones. Muchas empresas se conforman con adquirir buenas herramientas de control, pero se olvidan de que sin una buena política de gestión de configuraciones la herramienta no es más que un soporte, algo que puede considerarse incluso como un elemento lelo si se utiliza sin cabeza.
Es posible que redacte en próximas entregas lo que bajo mi punto de vista sería una solución a todos estos problemas. No quiero decir con ello que tenga la solución a todos los problemas, que sea un gran consultor ni nada parecido; simplemente reflejaré lo que los autores aconsejan sobre esto y expondré qué cosas se podrían hacer para paliar estas situaciones. Y desde luego que exponer una solución no es el final de todo. No existen balas de plata, recordemos, y la aplicación de tales soluciones será unas veces más sencillo y otras más complicado, requiriendo en algunos casos de la implicacion de todo el equipo para alcanzar el éxito. Tampoco existen garantías absolutas, pero sí podemos aumentar nuestras posibilidades, y por esto bien puede merecer la pena el esfuerzo.
Errores comunes en desarrollo software (III) Julio 4, 2009
Posted by ravelus in Informática.add a comment
- Actividades fundamentales acortadas. En cierto modo, una consecuencia del error anterior. Cuando hay prisa, se recortan las tareas que no producen código directamente. Habitualmente las candidatas son: análisis de requisitos, diseño y elección de la arquitectura, curiosamente las fases con mayor riesgo y más claves del proyecto.
- Diseño inadecuado. Viene un poco en consonancia con lo que acabamos de anotar: diseños realizados con prisa, no atendiendo debidamente al tiempo requerido conducen a malos productos. Un diseño completo requiere varios ciclos.
- Acortar tareas de calidad. Cuando hay prisa, tratan de acortarse tareas de revisión de código y testing. Eliminar un sólo día de tareas de calidad puede alargar el proyecto entre 3 y 10 días más.
- Controles de gestión insuficientes. Antes de tratar de mantener un proyecto en el buen camino, pregúntate si el proyecto está en dicho momento en el buen camino.
- Convergencia prematura o demasiado frecuente. Cuando se acercan fechas de entrega del producto, es necesario realizar tareas de mejora de desempeño, documentación, preparación de la instalación del producto, etc. Se suele tender a converger demasiado pronto en el sentido de empezar a preparar la release demasiado pronto, lo cual es contraproducente porque luego habrá que volver a converger alguna vez más con nuevas mejoras producidas y además condiciona negativamente al proyecto. Realmente es complicado cómo decidir cuándo converger: no puede ser demasiado tarde porque hay un buen número de tareas propias de fase de release, como las que hemos apuntado antes, que deben ser realizadas, pero si se trata de integrar el trabajo demasiado pronto luego habrá que integrar nuevas funcionalidades y bug fixing realizado.
- Omitir tareas necesarias de las estimaciones. Es fácil olvidar tareas menos visibles pero necesarias, que luego añaden tiempo a la calendarización. Una buena medida sería guardar información histórica de anteriores proyectos para tener algo más de información acerca de qué se necesitó realizar y poder estimar con más conocimiento de causa.
- Planear ponerse al día más adelante. Si una estimación resulta no ser adecuada en la realidad, las estimaciones de las tareas dependientes de ella deben ser reajustadas en consonancia, y no esperar que el proyecto avance más deprisa a partir de tal momento. Es razonable fallar una estimación: uno aprende del proyecto a medida que éste avanza. Es necesario reajustar estimaciones también cuando cambian los requisitos.
- Programar a lo loco. Olvidarse de realizar un diseño bien trabajado. Sin razonar. Al más puro estilo ensayo y error. Esto conduce a tirar mucho trabajo que no vale, a perder mucho tiempo en experimentación poco productiva. Esto, que parece un error de novato, es a lo que conducen las calendarizaciones ambiciosas, cosa que está a la orden del día en muchas empresas.
Referencias:
Steve McConnell: Rapid Development, Taming Wild Schedules
Turismo rural en Aliste (Zamora) Junio 27, 2009
Posted by ravelus in Cultura, Experiencias.add a comment
Hace ya unas cuantas semanas estuvimos mi novia y yo haciendo turismo rural por la región de Aliste, al oeste de Zamora, una zona muy bella en cuanto a paisajes y tranquilidad que recomiendo a todo el mundo.
Aliste es una región húmeda, contrastando con la zona del este de Zamora (Tierra de Campos), mucho más seca. Mientras que el oeste es zona de pastos y vegetación abundante, que bien nos puede recordar al norte de España, la zona oeste es más típica de la meseta castellana, con campos de cereal y llanuras interminables. Cubre desde la sierra de la Culebra al norte hasta la zona de Sayago al sur de Zamora, por el oeste con la frontera de Portugal y con el este aproximadamente con la Vía de la Plata, antigua calzada romana utilizada para transportar plata desde las minas asturianas a los puertos de Cádiz, aunque probablemente se empezó a utilizar antes por otros pueblos. Hoy, carretera nacional y vía del peregrino del sur hacia Santiago de Compostela.
Estuvimos en un pueblecito llamado Ceadea, a pocos kilómetros de Alcañices, cabecera de comarca de la región. Es un pueblo tranquilo, típico de la región, donde las linderas de las tierras se separan con lo que ellos llaman cortinas, que no es más que un muro de piedra de unos 80 cm. de altura.

Vista del pueblo de Ceadea
Lamentablemente para mí, no es una buena zona de senderismo, debido a que no hay rutas bien trazadas y hay poca información al respecto. No hay una buena coordinación entre los distintos concejos para tratar de establecer un conjunto turístico regional importante, lo cual es una verdadera pena. En Muelas de Pan, por ejemplo, existe un pequeño museo de alfarería típica de la región, pero poca gente sabe cuándo está disponible.
De modo que los mejores conjuntos paisajísticos serán visitados en coche. Posiblemente desde el punto de llegada se pueda, posteriormente, hacer alguna ruta. Los lugares más interesantes son:
- La Sierra de la Culebra, a la que se puede acceder en coche, pasando por el pueblo de Villardeciervos, cuyas casas de piedra y madera son curiosas de ver; otro pueblo, éste semi-abandonado, sería Sta Cruz de los Cuérragos, un pueblo muy bello de calles y casas empedradas y tejados de pizarra. Desde allí se puede hacer una pequeña ruta a pie, de una media hora, descendiendo al Valle de los Infiernos, que cae a la derecha del pueblo, en un aparcamiento gratuito que hay.

Una casa típica de Villardeciervos, pueblo que prosperó gracias al contrabando con Portugal de diversas materias

Santa Cruz del Cuérrago
- Los Arribes del Duero, con varios pueblos para recorrer. El principal atractivo turístico de la zona probablemente sea el Puente Pino, en Pino del Oro, un puente de cien años de antigüedad, el primero de hierro que se construyó en España. Se accede por una carretera serpenteante por la cual no conviene correr mucho.

Puente Pino. Impresiona verlo en vivo y en directo
- Miranda de Duero, en Portugal. Cruzando la frontera, está este bonito pueblo (más bien ciudad) portuguesa, típicamente conocida por sus baratas toallas. Personalmente me quedo con sus bares, sus cafés bien cargados y aromáticos a 50 céntimos, sus bacalaos a la dorada y sus vistas del río Duero.

Catedral de Miranda do Douro, en Portugal
- La propia región de Aliste, con sus paisajes, sus vacas y su ternera de Aliste con denominación de origen, que tuve la oportunidad de degustar en la casa rural donde nos hospedamos y es una auténtica delicia. En horno de leña y chimenea tradicional. De la brasa al plato. Una gozada.

A la parrilla, sabe mejor
- Embalse de Ricobayo y región circundante. Es un embalse que se construyó hace varias decenas de años. En esa zona, más soleada y seca, existen algunas rutas de senderismo y escalada.
Otros pueblos interesantes son Tábara, Alcañices (donde hay una pequeña ruta muy agradable que discurre a lo largo de un arroyo, pasando la Torre del Reloj), Fornillos de Aliste… Como curiosidad sepan que en esta región la Casa de Alba tiene importantes extensiones terrenos…

Torre del Reloj de Alcañices. En el Medievo este pueblo estaba amurallado.
El visitante también podrá hacer alguna ruta a caballo y practicar deportes acuáticos.
Si pueden hacer una escapadita de fin de semana o un pequeño puente, no lo duden, visiten Castilla y León. No hace falta ir más lejos cuando lo bueno lo tenemos aquí.



