Git y svn (Tutorial básico)

8 de ene de 2011

He aquí un post bastante técnico. Para ver el “cómo hacerlo funcionar ya”, id hasta el final ;)

Ahora están bastante de moda los sistemas de control de versiones distribuidos, como Git, Mercurial y Bazaar.

No obstante, muchos de nosotros trabajamos en proyectos que, por unas circusntancias u otras utilizan sistemas de control de versiones centralizados.

En mi caso, en la Facultad de Informática de A Coruña tenemos montado un repositorio svn para algunas asignaturas.

SVN “está bien” (según sus defensores), pero según mi humilde opinión, Git lo supera por mucho en bastantes cosas. La primera, que es descentralizado.
He comenzado utilizando Git y por tanto no sé cómo podría hacerse lo que voy a decir con Mercurial o Bazaar; pero esto va a ser, a partir de aquí, un pequeño tutorial de como utilizar git, y como utilizar git con un repositorio svn. Esto está enfocado a sistemas POSIX, aunque la mayor parte es aplicable a la instalación de Git para Windows.

Aviso: Todos los comandos de git tienen entrada en el Manual, y muy buena; a diferencia de los comandos de Subversion, que solo te dicen que si quieres algo vayas a su web.

Para ver la documentación de un comando de git, se pueden hacer dos cosas:

  • o bien preguntárselo elegantemente a git: git init --help
  • o bien acceder directamente al manual, así: man git-init (con un guión en el medio)

La documentación de Git se encuentra en la sección 1 del manual.

Update: Vistas ciertas visitas desde Google, añado lo siguiente aquí como referencia rápida

En git es muy común estar haciendo commits continuamente. Porque como son locales, así se puede tener un control más fino de lo que se está cambiando.
Pero normalmente uno no quiere subir todos esos commits como tales a SVN, sino en su lugar, subir uno con el contenido ya hecho y funcional.

Esto puede lograrse del siguiente modo:

git branch miRamaDesarrollo
# Hacemos cambios al código..
git commit -m “Cambios triviales”
# Más cambios..
git commit -m “Mi gato me ha dado una idea genial para esto”
# Más cambios..
git commit -m “Seguro que ahora ya funciona”

Y cuando todo esté finalizado, para subirlo a SVN, cambiar a la rama master (o a donde lleves tus commits de SVN) y hacer:

git checkout master
git merge –squash miRamaDesarrollo

Esto crea un estado en el INDEX equivalente a hacer un merge de miRamaDesarrollo en master, pero sin hacer el merge, ni actualizar master. En este momento, se puede hacer un git commit para realmente generar un único commit con todos los cambios conjuntos de miRamaDesarrollo.
Luego, un git svn dcommit soluciona la tarea de enviar ese único commit.

Recordad, antes de volver a trabajar en la rama de desarrollo, hacer un git rebase master, para no generar un octopus.

Comandos básicos de Git

git init [-q] [--bare] [--shared=[<permissions>]] [directory]
Crea un repositorio vacío o reinicializa uno que ya exista. Lista de parámetros:

–bare
Crea un repositorio desnudo. Es decir, sin working tree.

Con SVN no vamos a utilizar este comando.

git add [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p] [--edit | -e] [--all | [--update | -u ]] [--intent-to-add | -N] [--refresh] [--ignore-erors] [--ignore-missing] [--] [<filepattern>...]
Este comando, con la cantidad de flags opcionales que tiene, actualiza el index utilizando el contenido actual del working tree para preparar el contenido en fase de ser versionado.Podeis ver todo lo que se añade y cómo funciona en la págian de manual (puede estar en inglés).

Generalmente se utilizará como git add <files>

git commit [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run] [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<author>] [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o]<file>…]

Envía los contenidos del index a un nuevo commit, junto con un mensaje de log con el que el usuario describe los cambios.

El contenido a enviar puede especificarse de los siguientes modos:

  1. utilizando git add para añadir incrementalmente cambios al index antes de utilizar el comando commit (Nota: los archivos modificados deben ser añadidos explícitamente)
  2. utilizando git rm para eliminar archivos del working tree y del index, de nuevo, antes de utilizar el comando commit
  3. listando ficheros como argumentos al comando commit, en cuyo caso el commit ignorará los cambios del index y en su lugar grabará como contenido únicamente los cambios que ocurriesen en los ficheros pasados por parámetro y que ya deben ser conocidos para git (es decir, existían en el commit anterior)
  4. utilizando el switch -a con el comando commit para añadir automáticamente todos los cambios de los archivos ya conocidos (i.e., todos los archivos que están listados en el index) y para borrar automáticamente en el index todos los ficheros que hayan sido borrados del working tree, realizando inmediatamente el commit. (Este es el funcionamiento más parecido a svn commit)
  5. utilizando el switch --interactive con el comando commit para decidir uno a uno, qué archivos deberían ser parte del próximo commit, antes de finalizar la operación. Actualmente esto se implementa llamando primero a git add --interactive.

Si haces un commit y encuentras un error en lo que hiciste inmediatamente después, puedes recuperarlo utilizando git reset.

Podeis ver la lista de opciones en el manual, pero yo querría destacar --amend que nos permite editar el mensaje de log del último commit. Esto no debe hacerse jamás con un commit que haya sido subido (y posiblemente descargado por otra persona), o subido a un svn; pero mientras sean tus cambios privados, git te permite cambiar el log sin problema ninguno. Nota: Esto cambia el CommitID (un registro interno de Git que dice qué commit es padre de cuál).

git mv; git rm
Permiten mover y borrar ficheros. Lo mejor de utilizar esto en lugar de los comandos de las Coreutils, mv y rm es que el cambio se incluye automáticamente en el index. Además git rm permite opciones como [-f | --force] [-n] [-r] [--cached] [--ignore-unmatched] [--quiet]
git fetch
Probablemente no tengais que utilizar esta opción directamente. Se usa para bajarse objetos de un repositorio Git. Pero suele ser más útil que Git lo utilice dentro de comandos como git merge y git rebase
git rebase [-i | --interactive] [options] [--onto <newbase>] &lt:upstream> [<branch>]
git rebase –continue | –skip | –abort

git rebase <base> cambia el commit padre del conjunto de commits nuevos para que sea <base>. Se ve mejor en el ejemplo del manual; digamos que sirve para mantener la “raíz” de tu conjunto de cambios actualizada, si alguien hace un cambio por el medio.

Si la nueva base incluye cambios en ficheros que tú también has modificado habrá que resolver los conflictos antes de terminar. Hay un ejemplo de cómo en el manual. Cuando se haya resuelto un conflicto, git rebase --continue permite seguir con el proceso de rebase. Si uno no quiere tener que resolver conflictos, puede abortar el proceso con git rebase --abort

git merge [-n] [--stat] [--no-commit] [--squash] [-s &t;strategy>] [-X <strategy-option>] [--[no-]-rererere-autoupdate] [-m <msg>] <commit>…
git merge <msg> HAD <commit>…
Incorpora los cambios de un commit con nombre (generalmente una rama) en la rama actual. Se puede crear lo que se llama un “metacommit de mezcla” (merge commit) indicando cuáles eran los padres del commit mezclado
Son intersantes las siguientes opciones:

–commit, –no-commit
Hacer o no, directamente el commit cuando acabe de mezclar las ramas.
–ff, –no-ff
No genera un commit de mezcla si esta puede resolverse como un fast-forward (avance simple en la historia), solo actualiza el puntero de rama para que apunte al último commit. Este es el comportamiento por defecto.
Con –no–ff se genera un commit de mezcla aunque se pudiese resolver como un fast-forward.
–squash
Recrea el working tree y el estado del index como si hubiese ocurrido un merge real, pero no hace el commit, ni mueve HEAD, ni hace que el siguiente comando de git commit cree un commit de mezcla. Esto permite crear un único commit sobre la rama actual cuyo efecto es equivalente a mezclar la otra rama.
–ff-only
Evita mezclas a menos que HEAD esté actualizado o el merge se pueda resolver como un fast-forward.

Comprobaciones anteriores a la mezcla

Antes de aplicar cambios externios, deberías de comprobar que tu trabajo es correcto y se le ha hecho un commit, para que así no ocurran cosas extrañas si hay conflictos.

git log [<options>] [<since>..<until>] [[--] <path>…]
Muestra los logs de uno o más commits. Por ejemplo, git log HEAD~4 muestra todos los cambios desde hace cuatro commits hasta los cambios locales que aún no se han enviado. git log HEAD~4..HEAD muestra los cambios desde hace cuatro commits hasta el último, desechando lo que haya ocurrido ahora en el working tree.
git status [<options>...] [--] [<pathspec>...]
Muestra las rutas que tengan cambios entr el index y el HEAD, rutas que tengan cambios entre el working tree y el index, y rutas en el working tree que no están siendo seguidas por git y tampoco siendo ignoradas por gitignore.
git checkout
Actualiza los ficheros del working tree para que coincidan con la versión del index o del árbol especificado. Típicamente, git checkout actualizará HEAD para poner la rama especificada como rama actual. Tip: Utilizar git checkout -b <rama> crea una rama nueva y la especifica como rama actual. Es equivalente a hacer git branch <rama> && git checkout <rama>
git branch
Lista, crea y borra ramas.
Sin argumentos, lista las ramas del repositorio, siendo la actual la que tiene un asterisco.
Especificando un nombre de rama (que no exista) creará la rama pero no la pondrá como rama actual. Para ello hay que utilizar git checkout.
-m y -M sirven para modificar el nombre de una rama, y -d para borrarla (si ha sido integrada completamente en la rama de la que se creó, o si no hay rama upstream).
-D permite borrar una rama que no haya sido integrada (úsese con precaución!)

Comandos básicos, más o menos ya están. Ahora faltan aquellos que permiten interactuar con SVN.
Si ya habeis utilizado Git en un pasado, no podreis utilizar git push y git pull, pues estos trabajan con repositorios Git, y no está recomendado pasar datos entre repositorios git descentralizadamente, según el manual. El modo recomendado de trabajar es o bien enviar los cambios al svn centralizado o bien utilizando git format-patch y git am.

Comandos para la integración con svn

git svn init [--stdlayout] [--trunk=<trunk_subdir>] [--tags=<tags_subdir>] [--branches=<branches-subdir>] <svn-repo>
Inicializa un repositorio Git a partir de un svn remoto. –stdlayout indica que el repositorio está estructurado con la estructura típica (branches/, tags/, trunk/). Se pueden especificar varias –branches y git las seguirá a todas.
git svn fetch [--localtime] [--parent]
Se baja revisiones nuevas del Subversion remoto que estemos siguiendo.
–localtime guarda los tiempos de los commits de Git en la timezone local en lugar de UTC. Esto hace que git log muestre las mismas fechas que haría svn log para la timezone actual. Esto no interfiere con el repositorio del que has clonado, pero si quieres que tu repositorio pueda interactuar con otro repositorio Git, no deberías utilizar esta opción, o estar ambos en la misma timezone.
git svn rebase
Esto coge revisiones contra el SVN que corresponda con el HEAD actual y hace rebase sobre el contenido del trabajo actual (que aún no se haya subido al SVN) contra las revisiones nuevas.

Esto funciona como svn update o como git pull, si ya has usado git, a excepción de que preserva el historial lineal con git rebase en lugar de git merge para que sea más fácil hacer dcommit con git svn.
al igual que git rebase esto requirere que el working tree esté limpio y no haya cambios sin subir
git svn dcommit
Envía cada cambio directamente al repositorio SVN, y luego hace rebase o reset (según haya un diff entre SVN y la cabeza o no). Esto crea efectivamente una revisión en SVN por cada commit en git. Se puede especificar una revisión o rama, y esto hará que se realice el trabajo como si la cabeza fuese el argumento especificado, en lugar de HEAD.
git reset -r <n> || –revision=<n> [-p | --parent]
Deshace los efectos de fetch hasta la revisión que se especifique. Esto permite volver a hacer fetch de una revisión SVN. Generalmente los contenidos de una revisión de SVN no cambian jamás, y reset no debería ser necesario. Pero si por alguna razón es necesario reparar tu repositorio, el único modo es usar reset.

Todavía tengo que probarlo en profundidad, pero la forma de trabajar debería de ser algo así:

mkdir proyecto
cd proyecto && git svn init https://svn.fic.udc.es/… –stdlayout # tenemos una estructura tags/, branches/, trunk/
git svn fetch –all # cogemos todas las versiones para que git las conozca
git svn rebase # ponemos ‘master’ a la última revisión del svn

git checkout -b mitrabajo # creamos una rama distinta para trabajar en ella
### Trabajamos…
# hacemos incluso algún git commit en la rama mitrabajo para ir versionando cosas…

git checkout master # volvemos a la rama ‘master’ (que por defecto contiene el trunk/)
git svn rebase # comprobamos que no haya más cambios
# mezclamos los nuestros en master

git merge –ff-only –squash mitrabajo # squash mezcla todo el trabajo que hayamos hecho en un único commit
git commit # actualizamos nuestro ‘master’
git svn dcommit # subir los cambios de master al svn

#opcionalmente,
# o bien:

git branch -d mitrabajo # borramos la rama
# o bien la actualizamos con lo que tiene master
git checkout mitrabajo && git merge master
# o bien le hacemos rebase, así
git checkout mitrabajo
git reset –hard master # reseteamos la rama mitrabajo al último commit que hay en master

# Actualizamos el Trac del proyecto
bash sync.sh

LudusParty 2010

30 de nov de 2010

Con una página web que mea sobre la de la Arroutada, por ejemplo (y probablemente muchas más), y con una gente que son mucho más genial que la Asociación AMIGA; la LudusParty 2010 es un evento cultural y de ocio a una escala… en otro orden de magnitud respecto a eventos como la Arroutada (de la que hablo en el post anterior).

Después de un año sabático, por falta de presupuesto por parte del Concello de Lugo (en cuyo blog hubo censurados muchos comentarios), vuelve la LudusParty a hacerse realidad. Este año en la Casa do Deporte, un lugar algo más pequeño, y con una organización un poco diferente.
Por motivos que este bloguero solo sabe en parte, está la Asociación AMIGA (los de la Arroutada) manteniendo la Red, supervisados en todo momento por los organizadores reales del asunto: la compañía Inteligencia Visual.
Estos últimos son unos chicos que trabajan muy bien, aunque si estuviesen mejor rodeados podría dar todavía más de si la Party (véase hace dos años, cuando fueron los de la Euskal los que se contrataron).

Hubo un par de cosas que tal vez habría que mejorar, como que hubiese siempre una máquina de café con café cargado y cafeinado, pero un evento destacable.

La red la proporcionó Telefónica, no se cayó nunca, la LAN tampoco, no llovió, hizo una temperatura bastante agradable (la primera noche 17ºC en el interior, y desde que los cañones de calor caldearon el ambiente siempre entre 20 y 21ºC) (cosa que en la Arroutada no pasó: y que además estaba la puerta abierta para que hiciese frío).

Conocí a Sahib en persona, a quien ya seguía en Twitter, y vi a mucha gente que apenas veo habitualmente…

En resumen, fue una experiencia grata de nuevo, casi como en 2008 que, para mi, hasta ahora fue la mejor edición.

Os dejo un enlace al hilo del foro oficial de “Opinión de la Ludus 2010″, lo mejor y peor, y a la foto de familia:

Arroutada

10 de nov de 2010

Dícese de la segunda LAN party más antigua de España (dicen ellos) [Cita requerida].

Ha sido un completo desastre. Es decir, teníamos mesas, con corriente, un cable de red por persona… lo normal.

Del lado técnico, estábamos todos conectados a unos CISCO Core que repartían la salida entre (según me dijeron) “un par” de direcciones IP, sobre dos canales de Fibra Óptica proporcionada por R Cable y Telecomunicaciones Galicia. Sin backup de ningún otro proveedor.

El caso es que cuando nos empezamos a conectar todos, el nodo que alimentaba la zona del Coliseo nos detectó como si fuésemos un DDoS, y se apagó por autoprotección, no dejándonos a nosotros, sino también a toda la zona circundante sin conexión a Internet.

La organización intentó arreglarlo. Pero después de ver que era un problema externo y llamar a R, deberían de haber dejado de tocar cosas. No lo hicieron, y claro.. se cayó la LAN.

Inciso: si no habeis estado en una LAN party, es normal que el primer día pueda caerse Internet (excepto en la Campus Party, porque Telefonica es patrocinador oficial, pero eso es otro asunto); pero la LAN, la Red Local, no puede caerse nunca.

En realidad lo que ocurrió es que se cayeron los servidores que nos daban las IP locales (se llaman Servidores DHCP) y los DNS.

Tardó más de 1h30 en volver la LAN a configurarse y ponerse bien; sin embargo, se había restablecido la conexión a Internet después de tan solo unos 20 minutos (fue hablar con R y ellos reconfiguraron su nodo para que nos admitiese).

Lo sé porque aunque nadie podía conectarse a nada ni jugar ni ver nada, yo sí. Solo había que configurar el adaptador de red de una forma que lo permitiese (estaba caído todo, así que supuse que estábamos conectados más o menos de forma directa, y no había restricción por MAC/IP, porque quien generaba IPs se había caído).

Fue peor el hecho de que se fuese la luz varias veces, en mayor o menor medida (parones que podían variar entre momentáneos y de unos 20 minutos); pues aunque yo solo llevé el portátil (por motivos de transporte) y un par de discos duros externos, mucha gente no; y a un ordenador no le gusta que se le apague sin avisarle.
Del mismo modo, a un disco duro tampoco, y yo perdí más de 10GB por culpa de unos datos que se corrompieron a causa de los problemas eléctricos.

Pero lo peor ya, fue cuando empieza a granizar fuera del Coliseo, cuyo techo había sido reparado el año pasado muy rápidamente para un concierto de Shakira, y empieza a llover dentro, como si fuese fuera, encima de los ordenadores y de los cables de electricidad, de red, y de los servidores (que fueron los mismos que una semana después se utilizaron para retransmitir en Santiago al Papa.

Hubo que cortar la electricidad, pero fueron tan lentos haciéndolo que después de que amainara el temporal (y después de la supervisión del techo por parte de los bomberos) se montó una zona de prueba de equipos a donde había que llevar el ordenador antes de volver a enchufarlo, por si se hubiese cortocircuitado algo.

Volvió a llover fuera (y dentro) otra vez, pero en mucha menor medida (aunque asusta mucho), a mediodía, cuando además mucha gente se había marchado para comer.

A la altura de la lluvia en el Coliseo (en cuestión de mal, quiero decir) estaba la mala organización de la Party en general.
Había torneos oficiales de varios videojuegos, y concursos de programación (Bash Scripting, Demo de fractales y Real Time Battle), y de Hacking: Asalto al Servidor.

En los torneos, vimos el de Pro Evolution Soccer a pantalla gigante, y poco más.
El Asalto al Servidor, los que lo consiguieron no dijeron cómo lo habían hecho; el RealTimeBattle, que es algo visual: es un torneo en el que robots programados pelean entre sí en una arena, y era un concurso oficial no se emitió. Las puntuaciones aparecieron un día en la web interna, porque sí, sin explicación ninguna.

El de Bash Scripting, no se enseñó el código, ni qué hace, ninguno de los códigos.
Huele a algo muy fácil de amañar. Y no es transparente.
No me gustó nada.

Me alegro por @danielkmb2, compañero de facultad, que ganó el de RealTimeBattle, pero no aplaudo a nadie.
Y nadie debería de haberlo hecho.

Conclusiones: cuando organices un concurso, emítelo. Cuando contrates internet para un evento de esta envergadura, contrata un backup con otro proveedor. Simplemente para no quedarte sin nada si falla por algún motivo. Si eres de un sitio, y sabes que el techo de donde tenías pensado quedarte está mal, no lo hagas (lo del Coliseo, lo sabía media Coruña).
Ah y, por favor, no pongas un bar con alcohol y hora feliz como único lugar en el que conseguir un café dentro del recinto.

Porque luego la organización se emborracha, y pasan cosas que no deben.

Yo lo dejo ahí.

Si la organización no cambia, habrá un sitio libre más en la edición del año que viene. Si la hay.

Saludos!

Avances

9 de nov de 2010

Ahora lo pienso, y digo.. qué desperdicio el carrete
Montones de película con nitrato de plata y similares fotosensibles, revelada en tres partes…
Ríos de revelador, fijador y agua, que llevarán siendo vertidos desde los inicios de la fotografía
Cada vez más secos, observando en la penumbra de una luz roja, a un pequeño integrado
De nombre por siglas, como ahora está de moda, CCD o CMOS
Que les contempla, desde la oscuridad
Oliendo a electrónica
y novedad

Carrete sin revelar

Imagen sacada de Wikimedia Commons, liberada con Licencia Creative Commons By-NC-SA

Mi generación

9 de oct de 2010

En respuesta (extremadamente tardía) a RaveN en su Blog.

Yo soy de ‘la generación futura’ entonces.
La remesa de la década de los ’90, del año en que dos días antes de nacer yo, Tim Berners-Lee distribuye por EEUU documentos acerca de una futura red mundial.
El año en el que nació Sonic, mascota de SEGA; el año en el que sale a la venta el prmer ejemplar de Hobby Consolas. El año en el que se estrenó Terminator 2: Judgement Day de James Cameron. Cuando Queen publica Innuendo.

Todo estaba lleno de contenido en 1991, y nostros nos lo estábamos perdiendo, naciendo todavía.

Pero crecimos (unos más, otros un poco menos)

No he tenido la suerte, digamos así, de poder haber programado en una pantalla de fósforo verde (con lo que me habría gustado), pero fui de las primeras generaciones (y creo que de los pocos “niños”) que programó un VTech (aquellos portátiles de juguete con pantalla LCD monocromo) en BASIC.
Pero cuando nací todavía no estábamos conectados a Internet, sino a un servicio nacional que ya nadie recuerda, de nombre Infovía, con un módem de 28.8kbaud/s que hacía un ruido infernal y característico.
Comparto tiempo contigo al ver llegar la tarifa plana de datos (que ahora quieren tarificar por consumo, ¡qué retroceso!).

Con el fracaso escolar, estoy de acuerdo. Se están echando a perder muy mucho la mayor parte de las nuevas generaciones.
Todo esto comenzó con la LOGSE (esto requiere más debate), pero es que desde hace unos años, ocurrió algo antes impensable ¡se empezaban a quejar los profesores universitarios de que llegaban alumnos con faltas gravísimas de ortografía!
Y estos son los mismos que ahora generan contenido online.
Porque lo bueno de la red es que es anárquica, es libre y falta de moderación; y esto es lo que permite también que todo este contenido, que no es filtrado de ninguna forma, acabe siendo visto, lleno de errores que pasan a verse como “normales” (entrecomillado: normales no son, pero tan excesivamente comunes que acaban en mente de cualquiera como algo por lo que no alarmarse).

De todos modos, lo de que la gente lee mucho más..
Hay quien lee, y hay quien no. Quien practica lo suficiente, sabe distinguir entre algo bien escrito y algo que no, y quien no, es porque no lee lo suficiente.

Pero estos que no han distinguido entre bien y mal generarán más contenido, propenso a estar mal formado (aún con buenas ideas), con lo que es imprescindible que de una vez la Administración Pública inste a los políticos, y estos se dignen, a servir al pueblo, a ganarse el sueldo vitalicio del que disfrutan una vez se sientan en una silla del congreso, y a realizar una reforma de la Ley de Educación para mejor.. No para que ellos sigan ganando más veces, comiendo el coco a quienes no les dejan pensar, porque es algo que no se enseña. Sino para llegar al bienestar real.

En serio

9 de oct de 2010

En serio, llegará un día en el que haré una página principal. Y otro día en el que cambiaré de dominio.
Pero por ahora, estoy agusto. Pero sí, estoy convencido de que esta todavía no será mi casa definitiva en Internet.

Pero por ahora, aquí estoy; quemaisda

Interrupción constante.

22 de ago de 2010

Ir al cine con alguien es una buena excusa para ir al cine; para ver una peli, para comprar palomitas y para beber cocacola de barril si quereis. Pero generalmente, no lo es para quedar, charlar, estar con nadie. Sí lo es, no obstante, el tomar algo antes o después de la peli. Y por eso no debería de perderse esta costumbre.

Paseando nunca hay camino suficiente por el que hablar.
Antes o después se debe estacionar,
y si el lugar es propicio
no viene mal vitaminarse y repostar.

Es la una y media de la mañana y lo de arriba es lo primero que se me ha ocurrido. Sorry for the inconvenience : )

Si me siento con ánimos escribiré un día de estos porqué Salt, que he visto hoy, no me ha gustado.

Día de Galicia

25 de jul de 2010

Hola.

Hoxe é o Día de Galiza. O día da Patria Galega. Incluso o día de Santiago Apóstol (segundo o santoral cristián polo que, pese ao laicismo do Estado, se seguen a maior parte de festividades a relacionar).

Hoxe por tanto é o día do ‘meu santo’.
Pero non deixa de ser un día coma outro calquera.

Un non ten porqué sentirse orgulloso de ser galego, ou español. A un simplemente lle tocou nacer onde lle tocou. Un pode estar agradecido por haber tido nacido nun bo lugar e non morto de fame, mais non é algo do que enorgullecerse; é algo que toca.

Un pode sentirse orgulloso do que fai, o que lle toca non ten nada que ver con él, senón co azar.

Pero non me malinterpretedes: a min tócame estar en Galiza neste 25 de Xullo, e celebro o día da Patria na que me encontro. Gústame Galicia. E desfruto do día, mais non dunha maneira notablemente distinta ao que podería ser calquera outro día.

E tampouco é que me importe demasiado chamarme coma un home que foi testigo -din- de como outro home chamado Xesús vivía, hai arredor de 2000 anos. Mais do que sí me sinto orgulloso é de seguir coma o ano anterior, coa saúde que se pode, con ganas de aprender coma sempre, e tamén coas mesmas ganas de cambiar o mundo.

Comida en Nazaré

19 de jul de 2010

Como mis amigos sabrán, este que escribe ha estado de vacaciones en Burinhosa, un pueblecito portugués. Hoy, día 19 hemos ido a comer a Nazaré, a la plaza central, donde están la mayor parte de marisquerías turísticas de la ciudad.
Y, porque queríamos comer ya y en terraza escogimos el establecimiento desde el que me está dando tiempo a escribir este post, por la ineptitud del camarero que sirve nuestra mesa.
Afortunadamente ahora nos está atendiendo otro señor que parece ser algo más espabilado. Además parece empeñado el primero en hacernos pagar unos entrantes que no tenemos pensado tomar. Ya ha mirado unas 7 veces para la mesa y sigue sin llevarlos.
En fin, como consejo sincero, sí venís aquí, yo, personalmente os recomendaría que comieseis en otra parte.

Aunque ahora de la comida puedo decir, que he acabado de comer, de sabor estaba buena así que, si os confundís tampoco es que vayais a moriros de hambre : )

Nota al pie: Este post ha sido creado el 19 de Julio a través de un HTC Legend, pero por falta de conectividad a la red no ha podido ser subido hasta el 25 de Julio de este mismo año 2010

Con dedicatoria

5 de jul de 2010

Este promete ser uno de esos posts largos (y esto lo digo antes de empezar a escribir) y que pueden acabar aburriéndoos a todos los que me leais.

Pero este será el primero de esos posts que no va a ser leído antes por nadie en particular. Porque hasta ahora, en las sombras, todos los posts un poquito largos y que pretendían tener algo de sentido fuera de mi cabeza eran publicados después de la aprobación de alguien muy cercano, cuya crítica me anima siempre a redondearlo y pulirlo todo.
Alguien a quien quiero dedicar la entrada de hoy.

Y por ello, todo el contenido aquí escrito no ha pasado por sus ojos todavía. Puede que ni siquiera yo relea mis palabras al terminar el texto. Y si hay errores en lo que he dicho, simplemente lo siento.

Porque siempre, tener a alguien con criterio, con buenas ideas, y con una forma de pensar que pueda comprender la tuya, es algo simplemente maravilloso y afortunado.

Lo prometido. El texto.

Porque cuánta gente hay por el mundo sin criterio, que se junta con más gente sin criterio y acaban siendo tantos que pueda incluso parecer que tienen personalidad. Porque así es, hay gente que sin su ‘pandilla’ no saben qué pueden hacer o qué escoger, porque de su elección depende el que siga siendo aceptada en su grupo de amigos. Menuda amistad, debería decirse. Pero eso es otro tema.

El kernel es el hecho de que la sociedad, en general, anda muy falta de criterio. Nadie vota ya por intenciones políticas, por programas electorales ni por el bien de la sociedad, de ellos mismos. Hoy se vota por el color, por lo bien que habla la persona o por lo bien que a ti, individuo (pero no a todos, sociedad para la que se gobernará) te han besado el culo.

Por supuesto, quedan reductos de gente que no, que a pesar de los esfuerzos de los circundantes por destruír la cultura, todavía se esfuerzan (nos esforzamos, con humildad me incluyo si se me permite) en mantener viva una forma de pensar propia, del individuo.
Porque a mi puede gustarme más una cosa, y a ti otra; y en lugar de persuadirnos para que uno acabe aceptando que una es mejor que otra, después de una amistosa conversación podemos, simplemente, llegar a comprender porqué nos gusta cada cosa, sin intentar cambiar a nadie.

Futuros ingenieros, licenciados, arquitectos, diplomados, y demás graduados de educación superior, cada vez entran en el sistema con peores expectativas, con formas de ser mucho más laxas, mucho menos personales. Soy estudiante de primero de Ingeniería, y no pretendo que la educación superior sea elitista; pretendo que las personas sean cada uno mismo. Y no puedo creerme que pueda haber tanta gente que esté matriculada en carreras por tanto tiempo y que no asistan a mitad de las clases de las asignaturas que se han matriculado. ¡Que son los cursos más baratos de sus vidas por hora!
Por supuesto, depende del plano docente, pero excluyendo este, todavía quedan muchas clases vacías.

Y hay demasiados niños (lo ideal serían 0, por eso 1 ya serían demasiados) que se ven arrastrados al fracaso educativo en los niveles más elementales de esta, en sus pequeñas vidas, por causas no siempre justificadas, y que raras veces tienen que ver con la capacidad de pensar que tenga el chavalín.

Porque la tele es un aparato que emite lo que a unos señores les interesa. Y tienen muy buen criterio… pero no para con las personas que, activa o pasivamente, están siendo educadas por esta; sino para con ellos mismos, con su rendimiento económico. Y por alguna razón, en la sociedad actual, se vende mucho y demasiado bien lo gamberro y gandul.

Cada vez me gusta más apegarme a la gente con aprecio a lo que tiene valor cultural.

Porque cada vez hace más falta tener bien presente lo que es un buen criterio.

Porque cuando me faltan palabras, tú* siempre tienes una forma de describir en la que dibujas con ingenio en las palabras exactamente aquello a lo que me refiero. Me encanta.

Porque hacemos falta muchos, aunque yo… te tengo a ti.