El metodo socrático resulta… pero hay que saber cuando dejar de preguntar y empezar a golpear…

Con Malguzt siempre nos vemos entre clases; normalmente él saliendo cuando yo estoy a punto de entrar (siendo atropellados por la masa que abandona el aula de Análisis Matemático, y aplastado por la que intenta entrar a Análisis de Sistemas), y nos quedamos en los pasillos a discutir posibles o actuales proyectos.

Como ya saben, me gustan los Juegos de Rol, y Malguzt es uno de mis compañeros ahí también. El campo de interés que nace de la unión de estos gustos es, en teoría, los MMORPG. El problema es que la mayoría de éstos apestan:

• De RPG no tienen nada. El término se usa para describir cualquier juego que involucre niveles y un personaje que se haga mejor con el tiempo.
• Matar a otro personaje es lo más interesante que se puede hacer.
• ¿Realismo? ¿Qué es eso?
• 1. Matar,
  2. Comprar cosas nuevas,
  3. goto 1;

Un juego que actúa de manera un poco más razonable es el Ultima Online. Algunos conceptos interesantes:

• No existe el “nivel”. Sólo subir las habilidades mientras se entrenan logran un personaje más orgánico; además se evita el personaje de nivel mucho que tiene 300 en todo.
• Comer importa. Y no es una cosa mágica; no cura. Para eso están los vendajes, los médicos, y demás.
• No hay “clases”. Similar al primer punto; ¿por qué un guerrero no podría aprender a usar un poco de magia, para mejorar su habilidad de combate? ¿O un mago aprender un poco de sigilo?
• Que las cosas tengan sentido. Si me paso la vida talando árboles, probablemente consiga algo de músculos; si me quedo sin tela para mis vendajes, ¿qué me impide romper mi capa para conseguir material?

El proyecto que pulula por la mente de Malguzt, basado, un poco, en estos puntos, es De Fierro, que alguna vez mencioné.

Es una idea algo ambiciosa, claro —pretende ser otro Ultima Online— pero nada nos evita soñar, ¿no?

Es divertido actuar como la voz de la razón, en parte: Un sistema que quiere implementar es que uno no vea el nombre de otro personaje, hasta que éste lo mencione (o alguna forma de averiguarlo)… pero esto haría que si 100 jugadores se conocen entre sí, necesito 100² entradas en una tabla… (Lo cual no lo hace imposible, sólo un poco feo.)

Lo molesto es hablar con él para entender el proyecto e intentar implementarlo, y ver la conversación interrumpida cada dos minutos con excusas.

No intento apoderarme del proyecto, ni matarlo con problemas antes de nacer; quiero verlo nacer, y aunque muera a la semana, saber que pasó.

Quiero que De Fierro nazca, Malguzt, así que ponete las pilas y escribí.

Al menos ya llegué a nivel 70.

Supongo, por la pregunta, que no puedo aplicar mis primeras ideas:

1. No hacerlo
2. Torturar a los herejes
3. Convencer al director que no vale la pena

Tengo que empezar por aclarar que no tengo ningún tipo de formación pedagógica. No tengo paciencia para enseñar. Mis ‘alumnos’ terminan con más moretones que conocimientos.

Como dije, la programación, en el mismo nivel que las artes, la arquitectura, la publicidad, y otros campos, tienen partes que se pueden enseñar—puedo enseñar la sintaxis de un lenguaje, las técnicas para mejorar la escritura, formas de mejorar los trazos, mostrar diseños y miles de ejemplos de ‘genios’ anteriores a nosotros—, pero hay una parte, igual de grande o más, que no se puede empezar a describir.

Es imposible meterle a alguien en la cabeza algo relativamente complejo, como la programación, si no le gusta programar. Desde el principio esperamos perder a muchos por el camino. Lo importante es empezar con suficientes para llegar al final.

Odio la Historia, la Geografía,  la Sociología y la Biología… todas las ciencias blandas; me encantan la Química, la Física y la Matemática. Por mi propia experiencia, a la gente que le gustan las últimas tiende a irle mejor en la programación. Eso no quiere decir que las primeras no puedan hacerlo; si fuera así, probablemente no habría programas como los de cura del SIDA o el cáncer.

Lo importante es conseguir interés, que los alumnos propongan proyectos que les gustaría hacer. No importa, ahora, la dificultad; es un momento de brainstorming. El profesor también puede tirar ideas de cosas que ya se hayan hecho o que quiera hacer, como ejemplo de qué puede hacerse.

Obviamente, 50 propuestas van a ser “un juego”. Otras tantas van a ser de inteligencias artificiales.

Walter, un amigo, me contó que en la facultad hay proyectos de investigación involucrando PIC y demás. Si podemos usar éstos (o, no sé, un Arduino) para la práctica, conseguimos un objeto físico para interactuar. Algo tan simple como hacer que un LED parpadee es más interesante que el “Hola, Mundo!”. Si tenemos los recursos, armar un robot tan simple como dos ruedas para movimiento y una de apoyo hará maravillas.

Es importante no obligar a nadie a un proyecto u otro, sino dejarlos que elijan, aunque al profesor correspondería seleccionar los que se puedan terminar.

Y ahora es donde se empieza a poner más complicado. La división de tareas, interfaces, funciones… todo lo que sea código. Y acá vamos a empezar a perder interés. Hay que encontrar la forma de rellenar las líneas que acabamos de dibujar, cubrir las bases que cualquier proyecto necesita (lógica, bucles, variables, estructuras de datos, parámetros, funciones…), y las partes específicas de los otros (APIs, heurística, búsqueda de caminos…).

Esto último se puede enseñar; casi cualquiera puede hacerlo. Lo que necesitamos es generar el interés, antes de empezar.

Los tres artículos discuten el mismo tema: Hay muchas cosas que ponemos en los diseños, que no tienen una verdadera razón para estar ahí. Y si agregamos que los navegadores modernos pueden ayudar a simplificar, y que esto ayuda con la SEO, no tenemos realmente razones para oponernos.

Citando a Ryan: “‘Mantengo que la simplicidad es el factor más importante del diseño’, es lo que digo. A lo que Tufte respondería, ‘No, no lo hacés.’”.

La simplicidad es el factor más importante del diseño, por eso mi blog tiene esa apariencia, pero el post de Tomayko me hace ver detalles importantes de cosas que son innecesarias en el blog.

Entre ellas:

• Cajas de búsqueda: Google hace un mejor trabajo que cualquier plugin.
• Links a Feeds RSS: Para eso esta el ícono en la barra de navegación.
• Links a posts anteriores y siguientes: Raramente tienen algo que ver, y además existen los tags link, con el atributo rel=prev/next
• Blogrolls, links a archivos: Igual que arriba.

Voy a ir sacando en grupos estas cosas, mientras que voy poniendo más cosas en el dominio base, como ser links a los 10 últimos posts, y algo sobre mis proyectos actuales, supongo.

Ah, eso sí, ningún argumento sobre simplicidad me va a convencer de remover mi header.

Es un cambio 0.1, así que no espero demasiado; la interfaz de instalación sigue igual, y la mayoría de los cambios son de compatibilidad y seguridad.

Al fin pude configurar SCIM como quería, así que puedo escribir en japonés directamente （やった！）(no sé demasiado, pero… bueno, ahora puedo. Los únicos que tienen problemas, hasta ahora, son Firefox y su hermano Thunderbird, que si GTK_IM_MODULE está puesto, mueren de golpe.

Estoy empezando a enamorarme de UTF-8…

slapt-get me malacostumbró, y hace mucho que no compilo nada; pero eso es bueno. Tengo kxdocker del repositorio para 12.0 instalado sin problemas, y Baghira (un estilo que clona al de OS-X, pero que tiene el mejor menú que conozca) no quería compilar al principio, por un conflicto entre una biblioteca de X y QT, pero por un poquito de toquetear lo que no debería, ahora tengo mi Baghira.

Sí, bueno, hoy no tengo demasiado para decir… excepto que Slack rules.

Yo adoro el IRC. Tuve muchas incursiones al mundo del Chat desde chico. Algunas malas (#chaco-corrientes), y algunas geniales (#rol, #la_guarida, #umbría, y tantas otras). Combinado con mi relativo desprecio con el MSN hace que esté casi constantemente evangelizando su uso.

El IRC es simplemente un protocolo, pero uno genial en lo que hace: Pasar mensajes de un lado a otro.

El problema principal por el que no logro convencer a demasiada gente de que entre, es que, en esta zona, el uso del chat iniciaba así:

1. Bajarse e instalar mIRC e IRcap;
2. Entrar en chat.clarin.com (ya muerto);
3. Entrar a #chaco-corrientes;
4. Ver dos segundos de líneas constantes, sin sentido, llenas de combinaciones de colores enceguecedoras, recibir mensajes privados de tres hombres (uno de los cuales sigue mandando, a pesar de explicarle que no esta buscando… algo de… ese estilo¹);
5. Odiar el IRC para siempre.

Está claro que tener esa primera impresión no es lo más conductivo a apreciar el IRC y darse cuenta de todo para lo que puede servir.

El momento en que aprendí a dejar de preocuparme y amar al IRC, fue cuando, después de un par de horas de jugar al Baldur’s Gate 2² entré a una página de soluciones, y había un documento con las reglas de AD&D 2da (el sistema en el que el BG2 estaba basado). Ahí conocí el Rol, y eventualmente entré en #rol, en el IRC-Hispano, y conocí a varias personas que lo jugaban. Entre ellas, Aixa, una chica de Corrientes, la primera que conocía de la zona.

De ahí puedo partir a dos historias: la del Rol, y la del IRC. La segunda es la más corta, y la relevante: Empecé a conocer gente en el canal, fundé uno (#rolvampiresco —es lo que nace de conocer como primer juego a Vampiro—), y empecé a entrar en muchos (entre ellos, #edad-media, #rol, #umbría, #la_guarida, #bajomontaña, #dnd-es, #linux, #c… y eso sólo en el Hispano).

Las comunidades son amplias, y con cerca de 100 personas por canal (entre los relativamente interesantes, al menos), no es difícil encontrar respuestas a cualquier pregunta que hagamos.

A cualquiera que tenga un rato para probarlo, le recomiendo encontrarse una red (el IRC-Hispano, EFnet, y Freenode —las dos últimas en inglés— son las mejores, en mi opinión), visitar un canal de un tema que nos interese, lurkear un rato (esperar en silencio, para aprender las costumbres del canal), leerse las reglas —si las hay—, y empezar a conversar. Puedo garantizar a todos los que se animen a entrar, que no se van a arrepentir.

Vim es un editor de texto modal. Esto quiere decir que, a diferencia del Block de Notas, o Emacs², apretar una tecla (de las normales) no necesariamente ingresa un caracter; todo depende del modo en el que estemos.

Esto tiene ventajas y desventajas. Una desventaja es que los nuevos tienen que acostumbrarse a los cambios de modo. Como el programa inicia en modo de edición, al ver que al apretar una tecla no pasa nada, muchos se desesperan.

La gran ventaja es que los comandos de edición del texto sólo necesitan que apretemos una tecla. (Aunque es posible incluir cosas como, digamos Ctrl+C y Ctrl+V, la forma normal en Vim es y, y p)

Hay tres modos principales:

• Edición (también conocido como normal): Presionar una tecla modifica de alguna manera el texto, o nos cambia a uno de los otros modos.
• Inserción: Cualquier caracter que ingresemos se insertará en el texto.
• Visual: Básicamente, selección.

Insertar

El modo de inserción es el mas sencillo: lo único que podemos hacer ahí es, como su nombre indica, insertar texto.

Hay muchas formas de entrar en el modo de inserción. La más común es simplemente i. Para salir, simplemente apretamos Escape.

Los comandos de inserción (únicamente inserción) son:

• i: Insertar bajo el cursor.
• a: Insertar después del cursor.
• I: Insertar al comienzo de la línea.
• A: Insertar al final de la línea.
• o: Insertar en una línea nueva, abajo de la actual.
• O: Insertar en una línea nueva, arriba de la actual.

…Sí, son muchos… pero al principio nos basta con i (y a veces a).

Editar

Algunos comandos útiles son (y esta lista está lejos de ser exhaustiva):

• d: borrar
• c: reemplazar
• y: “arrancar”. Es como “copiar”. Para pegar usamos p

Estos últimos comandos tienen una capacidad que es lo que da a vim su poder. Podemos combinar estos comandos con una cuenta, y un comando de movimiento.

Por ejemplo, c9w: desde la posición actual, hasta nueve palabras más adelante, reemplazar.

Moverse

Esto trae una nueva (y amplia) serie de comandos: los de movimiento. Los más comunes son, simplemente, las flechas; pero Vim (habiéndose originado en vi) hace que sus comandos requieran alejarse de la fila central lo menos posible. h, j, k y l, son, respectivamente, izquierda, abajo, arriba, y derecha.

w avanza hasta el comienzo de una palabra, y b retrocede, mientras que con e avanzamos al final de una palabra. Sus versiones en minúscula cuentan los signos de puntuación como palabras individuales, mientras que la mayúsculas las cuentan como parte de la palabra.

fletra avanza hasta la próxima letra, incluyéndola (la que presionamos después de f, claro), y con F se retrocede, mientras que t (y T) la excluyen.

Otros

Para guardar, apretamos : (para el último modo interesante, el de línea de comandos), y w, seguida de enter. Con :q salimos. (Y con :wq guardamos y salimos inmediatamente.)

Un poquito más fácil

Los comandos de edición que vimos arriba son algo incómodos porque nos obligan a apretar (al menos) dos teclas para hacer un cambio. Las versiones “con movimiento incluido (un caracter hacia adelante)” son x y s para borrar y reemplazar, respectivamente. Estos también aceptan una cuenta, así 3s modifica los próximos tres caracteres.

También podemos poner una cuenta antes de un comando de inserción, y esto insertará varias copias de lo que escribamos.

:q

Esta es apenas una primera mirada a todo el poder de Vim, pero el punto de esta explicación es emseñar apenas lo suficiente para empezar a usarlo.

Entre las cosas que no nombro, está la colorización de sintaxis, macros, la capacidad de mapear cualquier letra a cualquier cosa que queramos (podemos sobreescribir incluso las letras que están ocupadas, si no nos gusta la configuración), el .vimrc, y muchas, MUCHAS cosas más…

Selectores

Para que el navegador sepa a qué elementos aplicar un estilo, tiene que saber cómo encontrarlo.

Para hacer referencia los elementos mediante sus ids, usamos el prefijo #. Un elemento con id header recibe sus estilos de reglas con el nombre #header.

Si queremos hacer referencia a todos los tags de un cierto tipo (por ejemplo, todos los links), usamos simplemente su nombre (en este caso, a).

Y para hacer referencia a todos los descendientes¹ de un elemento, separamos los selectores correspondientes con un espacio. Para elegir a todos los links del menú, usaríamos #menu a.

Y ahora podemos aplicar…

Tamaños

Un elemento de bloque, como div, por defecto, es tan ancho como pueda para llenar su contenedor (su padre), y tan alto como para que todo su contenido quepa.

Para hacer que el cuerpo de nuestro diseño sea más angosto, aplicamos una regla como

#cuerpo {
    width: 500px;
}

Si quisieramos definir la altura de un elemento, usaríamos la propiedad height.

Ahora, si quisieramos que nuestra cabecera aparezca centrada, primero le definimos un ancho como antes (el alto no es necesario, por ahora), y para centrar usamos márgenes automáticos. Agregamos las reglas margin-left: auto; margin-right: auto; a las anteriores, y, magia —excepto en IE—, ahora tenemos un lindo div centrado.

Pero aunque el div está centrado, el texto en su interior, no. Si quisiéramos eso, bastaría con text-align: center;.

Si usaste un CSS reset, como recomendé, ahora verás que las cosas están muy pegadas. La solución es fácil: márgenes.

La propiedad margin puede tomar entre 1 y 4 argumentos, aunque para hacerlo fácil, vamos con los dos casos extremos: un argumento aplica el mismo margen a los cuatro bordes, y 4 argumentos permiten especificar un valor para cada uno. Igual que antes, simplemente ponemos el selector, seguido por las reglas encerradas entre llaves.

Un par de detalles, antes de dejarlos a la espera del próximo post:

CSS significa “Hojas de Estilo en Cascada”, y lo de Cascada significa que si dos reglas se aplican dos veces a un mismo elemento, la última sobreescribe a las anteriores.

Además, hay otras unidades que podemos usar: el em, que (en teoría) es igual al ancho de una M, y a la altura de la fuente es la más común (por ejemplo, para separar los párrafos, lo normal es agregarle un margin-bottom: 1em;). El problema del em es que este depende del tamaño del texto del elemento (que definimos con font-size). Es decir, si le damos un margen de 1em a un texto de 10px de alto, este medirá el doble que un margen de 1em en un texto de 5px de alto.

Y, finalmente, la separación entre cada línea del texto definimos line-height, que no necesita una unidad (si no la tiene, su valor se multiplica por el tamaño del texto). (Valores que quedan bien son entre 1.2 y 1.5 para fuentes sans-serif —como Verdana—, y entre 1.4 y 1.7 para fuentes serif —como Times New Roman—.)