• Usar el cgi que viene en la distribución de mnogosearch. Para la mayoría la mejor opción.
• Usar la API PHP de mnogosearch y hacer tu propia página de búsqueda. Para quienes necesitan flexibilidad, la única opción.

La documentación de la API PHP es un cacao tremendo, mezcla cosas de versión a versión, y por lo general es bastante difcil de leer. Si quieres llegar a algo con la API, lo mejor que puedes hacer es cogerte el ejemplo que viene y empezar a estudiarlo concienzudamente o bien ver como lo han hecho otros, de esto hay muy poco por la itnernet así que aqui va como lo hemos implementado nosotros.

Lo que cuento a continuación funciona con la versión de la API 30308, es muy probable que si tienes una disntinta esto no funcione, cuento sólo la chicha, nada de como ser haría la interfaz ni cosas bonitas…

// Definimos la conexión del buscador, hay que definir el modo y es interesante usar la QCache, hace que todo vaya mucho más rápido.
$url_udm="mysql://usuario:contraseña@servidor/base_de_datos/?dbmode=blob&QCache=yes";
$encuentros_por_pagina=10;
if(!isset($desde))
 $desde = 0;

//nos creamos una conexión a la API
$udm = Udm_Alloc_Agent($url_udm);

/*
Con la siguiente variable se puede limitar la búsqueda a unas url, algo parecido al inurl: de google
*/
udm_add_search_limit($udm, UDM_LIMIT_URL, $sitio);
Udm_Set_Agent_Param($udm,UDM_PARAM_PAGE_SIZE,$encuentros_por_pagina); // encuentros por pagina

/*
para la paginacion,
mnogosearch pagina automaticamente, pero a diferencia de otros usa la
paginación como si fuera un libro, por lo que hay que pasarle la página
a la que quieres saltar y no el primer resultado de esa página.
*/
Udm_Set_Agent_Param($udm,UDM_PARAM_PAGE_NUM,$desde/$encuentros_por_pagina);
Udm_Set_Agent_Param($udm,UDM_PARAM_QUERY,$q); // lo que estamos buscando
Udm_Set_Agent_Param($udm,UDM_PARAM_CHARSET,'iso-8859-1'); // Aseguramos la codificación de la BD
udm_set_agent_param($udm,UDM_PARAM_BROWSER_CHARSET, 'iso-8859-1'); //la codificación del html resultante
udm_set_agent_param($udm,UDM_PARAM_STOPFILE, '/usr/local/mnogosearch/etc/stopwords/es.sl'); // las palabras que no dicen nada

$mResult = udm_find($udm,$words); //lanzamos la búsqueda

// La interfaz que vamos a devolver va a ser muy simple, a modo de ejemplo.
echo "Se encontraron". udm_get_res_param ($mResult,UDM_PARAM_FOUND) ."\n";
echo "Estamos en la conicidencia ". udm_get_res_param ($mResult,UDM_PARAM_FIRST_DOC) ." de".\
  udm_get_res_param ($mResult,UDM_PARAM_LAST_DOC)."\n";

/* Para la última página hay que hacer un bucle más corto */
if ($result["estimatedTotalResultsCount"] > $desde+$encuentros_por_pagina) //no es la última página
 $fin_bucle=$encuentros_por_pagina;
else
 $fin_bucle=$result["estimatedTotalResultsCount"] - $desde; //es la última página

for ($i=0;$i<$fin_bucle;$i++) { // recorremos las página encontradas
 // titulo de la página con su enlace
 echo "<a href=\"". htmlspecialChars(udm_get_res_field ($mResult,$i,UDM_FIELD_URL)) ."\">"\
 ParseDocText(udm_get_res_field ($mResult, $i,UDM_FIELD_TITLE))."</a>\n";
 // resumen
 echo ParseDocText(udm_get_res_field ($mResult, $i,UDM_FIELD_DESC) . udm_get_res_field ($mResult, $i,UDM_FIELD_TEXT));
 // Tamaño
 echo "tamaño: ".udm_get_res_field ($mResult, $i,UDM_FIELD_SIZE)."\n\n\n";
 }

udm_free_res($mResult); //liberamos las conexiones y la memoria
udm_free_agent($udm);

Todo era tan bonito, que resultó ser mentira

Motivación

Hemos estado usando la api soap de google para hacer las búsquedas dentro de gloobal.net, pero Google ha decidido dejar de dar soporte a esto desde Agosto de 2009, así que hemos tenido que buscarnos para seguir dando el servicio de otra forma. Como después de la experiencia nos hemos dejado de fiar de google un poco, por lo que hemos decidido usar mnogosearch para hacer esto, por aquello de apropiarnos de la tecnología.

Instalación

Partimos de una Debian Etch limpia recien sacada de la caja.

La versión de mnogosearch que viene con debian (etch) está obsoleta, por lo que se ha tenido que instalar desde los fuentes.

Compilando mnogosearch

Son unos pasos bastante sencillos los que hay que seguir,

ssh root@buscador
root@buscador's password:
buscador:~# # de aqui en adelante quitaré esto para que sea más fácil copiar y pegar 
apt-get update
apt-get upgrade
apt-get install make gcc less vim mysql-server libmysql++-dev
cd /usr/src/
wget http://www.mnogosearch.org/Download/mnogosearch-3.3.8.tar.gz # pudes buscar algo más moderno
tar xzvf mnogosearch-3.3.8.tar.gz
cd mnogosearch-3.3.8
perl install.pl # a las preguntas, todas por defecto menos Build shared libraries? (yes/no) [no]: yes
make
make install

Aqui ya estaría instalado el mnogosearch.

Compilando el módulo PHP en debian

Es importante hacer este paso después de haber instalado mnogosearch desde los fuentes.

cd /usr/src
apt-get install libapache2-mod-php5
apt-get build-dep php5
apt-get source php5
cd php5-5.2.6.dfsg.1/ # puede cambiar dependiendo de la versión de php
./debian/rules patch
cp  -a ../mnogosearch-3.3.8/php ext/mnogosearc
vim debian/rules # busca donde estan todos los --with y en medio pon --with-mnogosearch=shared,/usr/local/mnogosearch \
echo mnogosearch mnoGoSearch >> debian/modulelist
mkdir -p debian/php5-mnogosearch/usr/share/doc/php5-mnogosearch
./debian/rules binary #espera sentao
cp apache2-build/modules/mnogosearch.so /usr/lib/php5/20060613/
echo extension=mnogosearch.so > /etc/php5/conf.d/mnogosearch.ini
/etc/init.d/apache2 restart

Con esto ya está instalado todo el software necesario, ahora hay que configurarlo y echarlo a rodar.

Configuración

indexer.conf

La idea es ver la documentación sobre el fichero para saber lo que se está haciendo, pero aqui va lo más importante (cambiado) ojo este fichero no sería funcional:

DBAddr mysql://buscador:buscando@localhost/buscador/?dbmode=blob&Deflate=yes&zint4=yes
LocalCharset ISO-8859-1
StopwordFile stopwords/es.sl
HTTPHeader "User-Agent: Gloobal Crawler 0.3"
Disallow *html=1
Disallow *printview*
DefaultLang es
DetectClones yes
Server skip http://miweb/zonaoscura
Period 7d
Server http://miweb/
Period 1y
Server http://miweb/que_no_seactualiza/
Period 1h
Server HrefOnly http://miweb/novedades

La base de datos

Espero que hayas puesto contraseña a la base de datos en la instalación

mysql -u root -p
create database buscador DEFAULT CHARACTER SET latin1 COLLATE latin1_spanish_ci;
grant all privileges on buscador.* to "buscador"@"localhost" IDENTIFIED by "buscando";
\q
/usr/local/mnogosearch/sbin/indexer -Ecreate

Con esto la base de datos está creada y compuesta, solo le falta ser rellenada.

El sistema

Para que la base de datos se rellene hay que correr períodicamente el indexer, en nuestro caso hemos estado haciendo pruebas para ver la frecuencia con la que cambia la información de nuestras páginas y hemos determinado que cada media hora hay cambios suficientes como para que venga bien buscar enlaces nuevos, por lo que cada 30 minutos lanzamos el indexador con 1 hilo para que recoja 1000 páginas. Cada día a las 21h lanzamos dos hilos para que indexen todo lo viejo que esté caducado o nuevo que no esté indexado.

Cada dos horas lanzamos el proceso para convertir a blob la base de datos. Esto es necesario y bastante largo, afinarlo y tened en cuenta que las páginas indexadas no empiezan a aparecer hasta que esto no se ha lanzado.

Simplemente añadimos al /etc/crontab lo siguiente:

30 * * * * root /usr/local/mnogosearch/sbin/indexer -N 1 -n 1000 > /dev/null 2>/dev/null
00 21 * * * root /usr/local/mnogosearch/sbin/indexer -N 2  > /dev/null 2>/dev/null
20 */2 * * * root (/usr/local/mnogosearch/sbin/indexer -Eblob ; /bin/rm -f /usr/local/mnoGoSearch/var/cache/*) > /dev/null 2>/dev/null

y casi siempre hay que cambiar esto en el /etc/php5/apache2/php.ini

register_globals = On

Con esto ya tendríamos el indexador recogiendo información, Nos falta hacer algo en php con lo que hacer las búsquedas… En el próximo número.

Es tarde y todo se ha hecho en un par de días, las primeras gotas de rocio aparecen sobre la ventana y mis ojos enrojecidos se abren lentamente ante la aparición ¡Theodora!

Hemos preparado la retransmisión en vivo y en directo del Seminario internacional Colombia: Conflicto y derecho internacional humanitario, lo hemos montado en muy poco tiempo pero el resultado es bastante funcional.

La petición era transmitir por internet las jornadas ya que en el primer día se habían agotado las plazas. Mucha gente se había quedado sin poder asistir, además por la temática era interesante que mucha gente de otros lugares del mundo pudieran asistir virtualmente.

Antes de empezar hay que tener claros varios conceptos y los voy a explicar tal cual los he entendido (o me los he inventado).

Fuente: es lo que da el video y el audio al servidor de streaming.

Servidor de streaming: Es lo que recoge como entrada lo que da la fuente y se lo da a los clientes que se quieran enganchar.

Clientes: Son los que ven y escuchan lo que la fuente quiere transmitir.

Ningún concepto raro, ¿no? a mi me costó pillarlos, pero una vez claros continuamos, empezamos por el medio.

El servidor de streaming que hemos usado es icecast2, por qué icecast2 y no otro:

• Ya había usado icecast hace años para radio
• Es software libre
• apt-get install icecast2 #

La parte del servidor en sí no requiere mucho, simplemente instalarlo, y cambiar las contraseñas por defecto:

apt-get install icecast2

vim /etc/icecast2/icecast.xml

Unas tareas sencillas:

• Buscar hackme y reemplazar por tu contraseña favorita
• Configurar el hostname
• Cambiar el bind-address para que te puedas enganchar desde internet.

Luego hay que editar el fichero /etc/default/icecas2 y habilitarlo para que funcione… esto es para que cambiemos las contraseñas, así que no seas gañán o gañana y cambiala antes de hacer este paso.

Si ahora reinicias el icecast2 deberías tener un servidor funcionando

Icecast tiene un interfaz web de administración y estadísticas bastante sencillote ve a http://tuserver:8000 y entra con admin y su contraseña y verás sus funciones… esto te dejo que lo averigues tu.

Servidor funcionando… ahora deberíamos enchufarle algo para transmitir

Este paso fue un auténtico dolor de cabeza. En el primer momento pensabamos usar vlc para coger la entrada de firewire, convertirlo a ogg y enviarlo al servidor y… hubo problemas. No conseguí que el vlc cogiera el firewire (no hubo manera), ni que cogiera la entrada estandar para que enchufarsela al servidor ni que la vida sonriera, así que lo que decidí hacer es coger la entrada del firewire, pasarla a mpeg a un fichero local y enchufar el vlc a leer el fichero local y reenviarlo ya en ogg al servidor de streaming.

Todo lo siguiente requiere que tengas cargados los módulos de firewire

Asi que ejecutaba por un lado la conversión al vuelo de lo que entra por el firewire

dvgrab -format dv1 – | ffmpeg -deinterlace -f dv -i – -vcodec mpeg1video \

-s 352×288 -qscale 3.5 -acodec mp2 -ab 32k -ar 22050 de_la_camara.mpg

y por otro el envío al servidor de lo que se iba guardando (también lo muestra en local):

vlc -vv de_la_camara.mpg –sout\

‘#transcode{vcodec=theo,vb=800,scale=1,acodec=vorb,ab=128,channels=2}\

:duplicate{dst=display,dst=std{access=shout,mux=ogg,\

dst=source:micontraseñafavoritita@miservidorpreferido:8000/mievento.ogg}}’

Puedes hacer prueba de que funciona con el vlc:

vlc http://miservidorpreferido:8000/mievento.ogg

Esto mete un poco más de retraso pero, si lanzas las dos cosas separadas con un  & sleep 5; no será mucho . De todas formas el streaming ya hace bastante cache lo que hace que se vea con bastante retardo.

Ahora ya estamos emitiendo para toda la galaxia conocida nuestro evento, lo que pasa es que nadie nos conoce, pero seguro que tenemos una web que si conocen, así que vamos a embeber nuestro stream en la web. Para ello vamos a usar un script que hace que la etiqueta video de html5 funcione en navegadores que no lo soportan (o por lo menos lo intenta). Hay que aclarar que esto necesita que el cliente tenga instalado algo que le permita ver video ogg en el equipo y el plugin para el navegador (vlc, mplayer) o firefox 3.1 que ya soporta ogg nativamente

la cosa en cuestión es Mv Embed es bastante sencillo basta bajar el js ponerlo en el servidor y meter el siguiente código html en la web:

<script type=”text/javascript” src=”/PATH_AL_mv_embed/mv_embed.js”></script>

<video src=”http://miservidorpreferido:8000/mievento.ogg” thumbnail=”PONTE_UnA_FOTO_CHULA.png”></video>

Le puedes pasar opciones interesante como “autoplay=true” para que cargue el video automáticamente.

Tachan! ya tienes todo funcionando para restransmitir tu evento

Muchas gracias a Santiago Ramos de Ikusnet por la orientación y el apoyo moral

Bueno pero este post es para presentar una definición de requisitos para la memoria. Eso, dicho asi, con ese peso, no lo voy a poder llevar palante. Así es que lo que voy a hacer es presentar algunas ideas de lo que tendría que ser la aplicación (que quizá son también parte del análisis).

La idea general de la aplicación es que los diferentes trabajadores de iepala, entren periódicamente al sistema y reflejen información sobre las actividades que están desarrollando. Con esto se va elaborando colectivamente la memoria de la organización, que puede ser accesible online (con todos los temas de transparencia que esto conlleva) y que podría tener una salida “por atrás” en forma de documento unificado (para presentar a patronatos y cosas de esas).

Echarle un ojo a la web y os haréis una idea: http://www.memoria.iepala.es

Pongo una especie de modelo de datos simplificado con lo primero que se me ha ocurrido:

La idea central del mismo es que todo se podría resolver con simples (o complejas “etiquetas”, pero la realidad de IEPALA demuestra que gustan de las jerarquías. Entonces en vez de crear una campos para cada tema vamos a categorizar las etiquetas. Por otro lado esas categorías deberían tener 2 características basicas:

• Poder bloquear el editar o añadir etiquetas en una determinada categoría.
• Poder clasificar esas categorías en algo asi como “descriptivas” (serian las que tenemos en la barra de navegación derecha) o “contenidos” (medios de comunicación, organizaciones,… etc)

Lo bueno de dejar este modelo de etiquetas y categorías es que puede crecer conforme se les vaya ocurriendo. Y además refleja una jerarquía que le aporta control a la gente. Finalmente añada una batería de fechar que se pueden asociar con una actividad y el tema de vincular adjuntos (esto es para que empecéis a utilizar plugins). Por supuesto cualquier idea en en el modelo de datos sera bienvenida.

Por otro lado aqui os pongo el diagrama de casos de uso

Rápidamente describo:

• Evidentemente hay dos tipos de usuarios registrados: El editor y el administrador (no hace falta mas complejidad para nuestro sistema).
• El administrador gestiona usuarios y categorías. (NOTA: Y además tiene permisos para modificar cualquier “post”)
• Un editor puede crear, modificar y eliminar sus actividades.
• El visitante vera el sistema como un blog (aunque por defecto las actividades aparecerán en orden de realización de la misma y no de creación en el sistema) y podrá hacer filtrados por las etiquetas (algunas le aparecerán a la izquierda) y búsquedas mas complejas.

Evidentemente un tema clave para esta aplicacion lo tendremos en el tema de la impresion de informes. Pero eso no sera para esta proxima clase.

Vale pues con esto nos juntaremos en otra clase presencial y unificaremos en un solo código.

Salud.

—————-

Como nota final dejar constancia de que lo mas importante aun no lo hemos abordado: ¿Por que estamos migrando esta aplicación? ¿Por que a Rails?.

¿Para que desaprovechar otro curso haciendo pruebecitas que no sirven para nada?

En este no vamos a hacer tontadicas, y dado que nuestra madre IEPALA tiene necesidades nos vamos a remangar y a hacer faena. Hay dos proyectazos:

1.- Memoria de IEPALA.

http://www.memoria.iepala.es/

Existe un blog con wordpress en el que se han ido volcando las actividades de IEPALA para que se puedan ver, y para que sirvan como memoria de la organización. No entraremos a analizar su uso real (eso nos llevaría a procesos internos), pero lo que esta claro es que a medida que de una u otra forma se vaya utilizando, necesitamos “algo mas”, o “algo mas especifico”, o “algo que podamos tocar”,… etc.

Vaya, ideas en el aire, pero que son las que nos ponen en esta situación. Esas “ideas en el aire” son varias cosas que deberíamos analizar. Y al que no se si lanzarme en este post. Ahora me lo voy pensando.

2.- BBDD institucional.

La base de datos institucional básicamente es una aplicación solo de uso interno, que funciona por decirlo mal y rápido como una aplicación de e-mailing. Spam del nuestro. Como en el anterior caso no entraremos a analizar su uso, aunque aquí cabe destacar que es una aplicación mucho mas necesaria de lo que parece, y que tiene un uso sostenido en el tiempo. Está en PHP (para vergüenza mía es un hijo de un servidor de ustedes).

¿Cual es el problema de esta aplicación? Usabilidad. Ese fantástico termino que en esta caso nos viene que ni pintado. La idea es simplificarlo (desde el punto de vista del usuario), quizá unificar algo el modelo de datos, y sobretodo hacer transparente una serie de funciones y chequeos básicos que ayuden a limpiar y ordenar la información.

————-

Este es el ejercicio que tendremos que resolver en este curso. Nos centraremos en el 1. Pero según las fuerzas con las que nos encontremos quizá merezca la pena pensar en el 2.

Pero como siempre he tenido complejo de maestro espiritual vamos a ir a las cuestiones de “fondo” o por el contrario a las cuestiones de “altos vuelos”:

¿Por que?… ¿Por que migrar? ¿Por que en RoR?

Los tags ahora serian cosas como: análisis, adecuación soluciones, procesos, gestión información, cultura RoR, usabilidad,… etc. Osea las que cuestiones que molan. Hoy de momento no me meto con estas cuestiones. Estos post no corren mucha prisa, podemos ir hablándolos poco a poco.

Bueno vamos allá. Primero la referencia Ruby. La web de Ruby-Docs:

http://www.ruby-doc.org/docs

Aqui una Ruby User’s Guide muy “desde el comienzo”. Además tendréis la imprescindible documentación de la API.

Desde ella (aunque  se puede encontrar en muchos otros sitios) al clásico de  Programming Ruby (Pragmatic Programmer’s Guide):

http://www.ruby-doc.org/docs/ProgrammingRuby/

Este libro es: directo, elegante, complejo. Vaya mu bueno.

Evidentemente y poniéndome protocolario, todo el tiempo que se le dedique al núcleo del asunto, el propio lenguaje Ruby, no es tiempo perdido (os lo digo por experiencia por que soy de los que ha aprendido muy mal). Venga y para acabar en español:

http://www.ruby-lang.org/es

En esta web tienen referencias a guías y cosas por el estilo. Tiene un apartado de documentación con varias cosas. (NOTA: en documentación no he visto la traducción del libro Programming Ruby, pero se que en su día si que la hubo osea que sera cuestión de rastrear un poquito)

Vale pues con esto se acabo lo relacionado con Ruby. Ahora pasamos a Rails . Por una lado la web de rails:

http://www.rubyonrails.org

No es que tenga gran cosa, pero bueno, es la web “oficial” ¿No?. Desde puedes llegar a la documentación de la API. Por cierto esa misma documentación también esta accesible con lo que esta en el post anterior (gem server)… O incluso en vuestro propio proyecto generándolo con la tarea Rake correspondiente (ver rake -T).

Pero bueno vamos a libros de calidad. Primero el clásico:

http://www.pragprog.com/titles/rails3/agile-web-development-with-rails-third-edition

Esta ya en su versión para Rails2 (que es la que utilizareis vosotros). Nada que no sea fácilmente conseguible en las fantástiscas redes P2P para compartir (sed legales por favor… canalla el puto Molina). Este libro esta muy bien para enterarte de todo. Es un recorrido de la leche por el framework.

Y finalmente para cosas mas complicadillas, os dejo los libros de recetas de rails. Son recetillas que aunque tu no las necesites de momento es muy recomendable echarles un ojo e ir enterándose

http://www.pragprog.com/titles/fr_rr/rails-recipes
http://www.pragprog.com/titles/fr_arr/advanced-rails-recipes

Además de esto todo lo comentado, y como en cualquier comunidad que se precie de tal, tendréis una serie de listas en castellano.

Salud, gracias por asistir a esta clase, y en fotocopiadora podréis recoger los apuntes…

——————-

PD: existen dos blogs de gente en castellano, que por ser majetes y conocidos os los pongo aquí para que tengáis referencias:

El de la compañera de proyectos Amaia: http://apuntesderails.amaiac.net/
El de Jaime Iniesta: http://www.jaimeiniesta.com/

Pues la clase primera evidentemente es la de instalar RoR. En realidad no habrá muchas mas clases de estas. En realidad no creo que haya muchas mas clases. No voy a ponerlo todo fácil, asi es que dare solo las ideas generales.

Por cierto y antes de empezar que todas estas cosas se encuentran fácilmente por todas partes, por ejemplo aquí:

http://agileweb.wordpress.com/2008/07/18/how-to-install-rails-21-on-ubuntu-in-5-steps/

Adelante. Primero las cosas con apt. Mas o menos supongo que todos tenemos Ubuntu.

(apt-get) Instalar ruby. Pero cuidado: nada de la ruby1.9, si no el ruby1.8. (hace poco que me comentaron esta gracia)

apt-get install ruby

(apt-get) Instalar rubygem. Y claro: que sea coherente con lo anterior, por que hay dos paquetes de el 1.8 y el 1.9. DETALLE: este 1.8 y 1.9 no son la versiones del paquete rubygem si no la versión de ruby que utiliza ese gestor de gemas.

apt-get install rubygems

NOTA (deprimente para los buenos programadores): En Ruby, pero especialmente en Rails, no hay mucho respeto por el tema de mantener integridad (no recuerdo el termino informatico) entre las versiones. Suena chapuzas, pero es asi.

Bueno, y se acabo volver a utilizar el apt-get, a partir de ahora usaremos las gemas.

Pero la cosa graciosa es que ahora que la versión que tenéis de las gemas (que posiblemente será la 1.2.0) querréis actualizarla (a la 1.3.0). ¿Por que? según las webs es “recomendable” (Mmmm… que misterioso… en realidad mi conclusión es que hay mucha ignorancia, pero como yo tampoco me libro de eso, me callo). Asi es que intentar un:

gem update –system

Pues resulta que casca verdad. Algo de que:

“gem update –system is disabled on Debian….”

Pues vaya catxondos. Si queréis actualizarla probad esto:

http://apuntesderails.amaiac.net/archives/2008/12/2/actualizar_rubygems_a_la_versi%C3%B3n/

Es de amaia que tiene muchas cosas de rails.

Sigamos. Con esto tenemos el gestor de gemas actualizado. Si queréis probad a ver el gem –help y esas cosas. De todas formas a lo importante:

gem install rails

Podríais especificar la versión de la gema añadiéndole -v version

Y ahi os instalara las 4 cositas básicas. Quizá algo os va lento, o quizá algo falla, repetirlo, o intentar instalar alguna gema por separado. Es un consejo poco riguroso, pero mas de una vez me ha funcionado. En cualquier caso y en esencia tendréis varios paquetes importantes, y que componen el núcleo del framework. Hacer un:

gem dependency rails

Y veréis:

Gem rails-2.0.2
rake (>= 0.7.2, runtime)
activesupport (= 2.0.2, runtime)
activerecord (= 2.0.2, runtime)
actionpack (= 2.0.2, runtime)
actionmailer (= 2.0.2, runtime)
activeresource (= 2.0.2, runtime)

En mi caso tengo la 2.0.2 por que es en la que esta mi desarrollo. De todas formas hoy no voy a explicar conceptos (aunque es lo que mas me gusta) así es que si queréis buscaros una guía. Por otro lado si queréis ver las nuevas cosas que tiene cada actualización de Rails acabo de ver a un brasileño que se ha impuesto la penitencia de que cada vez que hay una nueva versión de rails hace un nuevo libro de “Whats new on Rails x.x.x”.

http://www.nomedojogo.com/

Bueno con esto esta casi todo, para tener una aplicación os colocáis donde consideréis de vuestro sistema de ficheros y hacéis un:

rails mi_aplicacion

Una vez tenéis hecho solo detallo que por defecto rails quiere utilizar una base de datos sqlite por detrás así es que para utilizar mysql tendréis que configurar el fichero config/database.yml adecuadamente. Esto os lo dejo a vosotros (tanto la instalacion de mysql como sqlite, como su configuracion en rails).

Pero para ello en la clase 2 os dejare una serie de referencias para que podáis ir leyendo.

——————–

Apéndice 1

Si quieres ver la documentación disponible de cada una de las gemas que has instalado solamente:

gem server

Esto levanta en el 8808 un índice con toda la documentación RDoc de las gemas instaladas en tu sistema.

———————

Apendice 2

Este es una cosa nueva bien fardona. En vuestro primer proyecto de prueba hacer:

rake doc:guides

Os creara en la carpeta doc/guides de vuestro proyecto una serie de guías de documentación para empezar con rails. Pijadas de esta gente. Por cierto si queréis ver todas las tareas rake que tenéis por defecto en vuestro proyecto creado con rails hacer:

rake -T

Será sin ritmo, con un profesor un tanto novato, pero creo que interesante para todos. Confirmar vuestra presencia (se admiten comentarios).

El plan es tener un par de sesiones presenciales preparadas, y luego ir viendo posibles quedadas, mientras avanzamos por comunicación diversa (correo, y este blog).

OBJETIVO GENERAL: Que os lancéis a poder hacer cosas en RoR.

OBJETIVOS ESPECÍFICOS:
* Manejarse en Ruby.
* Entender el framework Rails.
* Debatir la cultura Rails.
* Que podáis empezar a desarrollar o tocar cosas en RoR.
* Debatir RoR en el marco de problemas/soluciones concretas.

OBJETIVO TANGENCIAL:
Definición conjunta de buenas practicas en el desarrollo. SVN, TRAC,
Testing.

METODOLOGÍA:
* Guiada por el desarrollo de una aplicación.
* Encuentros presenciales para unificar ritmo.
* Correos o posts sobre referencias y pasos básicos.
* Solucionar por correo problemas o dudas (al ritmo que se pueda).

Tiempo total del curso: Pendiente de negociación, pero asi de arranque un par de meses (Febrero y Marzo).

Bueno, en definitiva, este primer post era para crear el tag: “curso RoR 09”

Hemos quedado gratamente satisfechos con las pruebas y muy posiblemente lo empecemos a implantar en algunos servicios que empiezan a tener mucho tráfico. Esto es más o menos lo que hemos hecho.

Nuestro esquema actual sería algo parecido a esto:

Bueno vamos al lío de cómo se haría esto, lo primero sería saber que servicios vamos a tener que tocar para poner esto en marcha, en nuestro caso serían:

• Apache, no mucho para decirle que ahora también escuche por real.example.com
• Bind9, para decirle que www.example.com es la máquina de cache
• Squid, el que va a hacer el trabajo sucio

En nuestro esquema cada servicio corre en una máquina distinta, así que empezaremos por apache y bind, que es donde menos hay que tocar…

En apache simplemente añadimos esta línea por cada dominio que queramos que sea resuelto por el cache:

/etc/apache/sites-enabled/example.com

[...]

ServerAlias real.example.com

[..]

Esto únicamente nos sirve para cuando queramos acceder al servidor sin pasar por la cache.

En la parte de bind, también es bastante sencillo, en el archivo de definición de la zona cambiamos la entrada del www

/etc/bind/db.example.com

[...]

www  IN  CNAME  cache

[...]

Ahora llega la parte importante instalar el squid y modificar la configuración para que haga de cache inverso.

Lo primero sería instalar squid con su orden favorita, apt-get install squid, urpmi squid, “instalame el squid becario”. En nuestro caso la configuración está hecha sobre una debian 4.0, pero no debería haber mucha diferencia entre nuestros unixes. Vamos a configurar squid

/etc/squid/squid.conf

http_port 80 vhost # Si vamos a escuchar en el puerto 80 haciendo la vhost (proxy inverso, esto sería todo

hierarchy_stoplist cgi-bin ?

acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY

cache_mem 600 MB # tenemos 750MB y esta máquina sólo va a hacer esto…

maximum_object_size 30 MB # nos interesa cachear también archivos mas o menos grandes

maximum_object_size_in_memory 128 KB
access_log /var/log/squid/access.log squid

hosts_file /etc/hosts # esto es importante, por que aqui es donde resolvemos a la máquina que realmente tiene el apache

refresh_pattern .        0    20%    4320

collapsed_forwarding on
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8

acl Safe_ports port 80        # http

acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny to_localhost
acl dominios dstdomain “/etc/squid/dominios” all # esto es importante en este fichero le decimos a squid los dominios que vamos a cachear
http_access allow dominios
always_direct allow dominios
http_access allow localhost
http_access deny all
http_reply_access allow all

icp_access allow all

cache_effective_group proxy
visible_hostname cache-001.example.com # podemos tener muchos

coredump_dir /var/spool/squid

Tachan! ya casi lo tenemos, ahora hemos dejado dos ficheros más que debemos tocar

/etc/squid/dominios

www.example.com

example.com

coreapp.example.com

/etc/hosts

[...]

192.168.0.2 www.example.com example.com

192.168.0.3 copreapp.example.com

[...]

y ya releemos las configuraciones de todos los servicios y a ver como el dns va llevando poco a poco el tráfico al caché.

Es interesante que se instalen siempre algunas estadísticas… pero eso ya será otro artículo rápido como este.