Conclusiones que no voy a publicar

12 de abr de 2011

Saco dos cosas en claro de estos últimos días en el blog:

  1. Al menos cuatro personas distintas leen mi blog
  2. A ninguna de estas les ha gustado que les dijesen las verdades de una organización que parecen representar.

¡Pero si en ningún caso he mentido en lo que he dicho!

UPDATE (Via Analytics): Y que todo esto ha salido de foro.amiga.arroutada.info, el foro privado de la Asociación AMIGA. Ocho visitas de ahí me han llegado ayer, de un tema que no puedo ver porque no formo parte de la asociación. Pero vamos, supongo que se habrán tomado de forma destructiva mi crítica y se habrán enfadado en lugar de afrontar la realidad. Osea, el infantilismo de algunos.

Y que Odín nosequé, dice un tío que no sabe hablar.

Sin título

1 de mar de 2011

A veces me da la impresión de que tengo que escribir más a menudo en el blog.

Pero entre #trabajoSC e ideas sueltas sobre proyectos que se me ocurren, no sé qué poner…

Copiar versos “incopiables” (BASH + Perl)

20 de feb de 2011

¿Alguna vez habeis intentado copiar algo de un PDF y se os han comido “mágicamente” los saltos de línea?

Yo me he bajado la música de El Reno Renardo, y sus letras, e intenté poner las letras a sus canciones en iTunes.

Y cuando estaba copiando y pegando, ¡sorpresa, los saltos de línea no se copiaban!

Si teneis un Mac y teneis la suerte, como yo, de que en cada línea las frases empiezan por mayúscula (y no hay muchas más mayúsculas por el texto), pocos retoques tendreis que hacer a lo que aquí os dejo.

cat - | perl -pe 's/([A-Z][^A-Z]+,? [a-z]+)/\n$1/g' | pbcopy

Cómo funciona:

Pegais el texto en la consola después de teclear el comando y pulsar enter.
Para finalizar la entrada de texto pulsais Ctrl.+D y el texto se guardará en el portapapeles.

Explicado: cat - lee lo que introduces por la entrada estándar, y el | (pipe) lo introduce como entrada del siguiente comando.

El siguiente comando es una sustitución por expresiones regulares con Perl. La expresión dice: Sustituir [LetraMayúscula]+[Algo que no es una letra mayúscula] [opcionalmente una coma] [más de una minúscula] y poner antes de todo eso un salto de línea.

pbcopy es un comando de Mac OS para copiar al portapapeles.

Esto es fácilmente adaptable a cualquier otro Unix, cualquier Linux: simplemente cambiando el último | pbcopy por un > output , el script generará un fichero ‘output’ con la salida deseada.

Tal vez tenga un par de errores en cuanto a cosas raras o texto en mayúsculas a mayores que pueda haber. Si a alguien le sirve, por favor, hacédmelo saber ;)

No les votes.

15 de feb de 2011

El próximo 22 de mayo, los ciudadanos españoles están convocados a las urnas para votar a sus representantes públicos en todos los ayuntamientos y en algunos parlamentos autonómicos. Los representantes elegidos tendrán a su cargo la gestión de miles de millones de euros durante un periodo de cuatro años, razón más que suficiente para extremar las precauciones de los votantes: a lo largo de los últimos años, el nivel de corrupción en la política española se ha disparado de manera alarmante en todo el arco parlamentario.

PSOE, PP y CiU son las tres formaciones políticas que han pactado para resucitar la ley Sinde en el Senado, una ley que permite censurar Internet por vía administrativa, sin una intervención judicial que garantice la tutela efectiva de los ciudadanos. Al juez que deba validar el cierre le estará vedado analizar el fondo del asunto, esto es, la vulneración de derechos de propiedad intelectual o la posibilidad de producir un perjuicio patrimonial por parte de la página web cuya clausura se solicite. La ley Sinde crea un “agujero libre de jueces” donde la decisión la toma una comisión administrativa nombrada por el gobierno, para evitar lo que hasta el momento venía ocurriendo: que los jueces no daban la razón a las reclamaciones de la industria de los contenidos.

La ley Sinde es ineficaz. No aborda una reforma integral de la legislación de propiedad intelectual, único camino para favorecer la justa retribución de los creadores y artistas en el marco de unasociedad de cultura digital. Aún así, y a pesar de la oposición de una parte importante de la sociedad incluyendo creadores y artistasPSOE, PP y CiU votaron a favor de ella. Pesaron más las presiones de gobiernos extranjeros y de grupos minoritarios que el interés social. Pero no todo es culpa de nuestros representantes: nosotros les hemos elegido, por acción u omisión.

Desde Nolesvotes.com consideramos que PSOE, PP y CiU han faltado a su principal obligación con la ciudadanía: defender la Constitución que juraron o prometieron acatar. La ley Sinde somete Internet a una legislación excepcional, con grave merma de los derechos a la libertad de expresión e información y a la tutela judicial efectiva, posibilitando un mayor control político de la red.

Tu decisión es importante. No te pedimos el voto para ningún partido concreto, ni que votes en blanco, ni que te abstengas, sino que te informes para comprobar que existen alternativas contrarias a la ley Sinde en todo el espectro ideológico. Te pedimos que defiendas la libertad en la red con tu voto, no apoyando a aquellos que con sus actos se han hecho claramente merecedores de un voto de castigo.

El próximo 22 de mayo, NO LES VOTES.

(Texto extraído de http://www.nolesvotes.com/)

Cambios de línea

6 de feb de 2011

He cambiado el estilo de la web.

Para ello he tenido que hacer magia con el CSS, y hasta donde he probado, funciona bien en Firefox 4 y en WebKit (Chromium, Google Chrome, Safari…).

Como veis, ahora en la página principal del blog aparecen las entradas cortadas si son largas, y se muestran en su plenitud, como si fuesen páginas de entrada completas, al pinchar sobre ellas.

¿Qué os parece?

3,141592 6535897 9323846 264338 3279…

5 de feb de 2011

Visto originalmente en Microsiervos Música: 3,141592 6535897 9323846 264338 3279 5028 841971 6939937510 582097 494459 23078164 06286 20899… | Microsiervos Música.

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