Agile Web Developer & Thinker

Mi primera aportación, pese que aún tiene margen de mejora, es will_static_generator: Plugin que genera la lógica que gestiona las páginas estáticas de un proyecto y con algunos steroides:

1. Poder elegir entre ERB o HAML como lenguaje de marcado para las páginas que generemos.
2. Disponer de un subnivel: /mi-empresa/quienes-somos, /mi-empresa/servicios,…
3. O de i18n.

En estos dos últimos puntos es donde considero el margen de mejora, los subniveles deberían poder ser indefinidos y en cuanto al i18n pensar, tal vez, en otras estrategias más potentes que la integrada en Rails.

Podéis ver más aquí: http://github.com/nickel/will_static_generator/tree/master

Es empezar con un nuevo lenguaje, framework,… cualquier cuestión vale y una super “L” de novato aparece en nuestra cara, en todo lo que escribimos o preguntamos. Pero durante este aprendizaje tenemos la suerte de poder tomar prestados shorcuts que nos ofrece la desinteresada comunidad y que han hecho nuestros novicios desarrollos bastante más llevaderos.

Por ello, ahora que la experiencia empieza a ser un grado, me he propuesto devolver dicho préstamo con la misma moneda: con tutoriales, screencasts y plugins. Esperemos estar a la altura, el reto no es sencillo =)

No sé ahora mismo de donde saqué este snippet para volver a disponer de esta pequeña funcionalidad: conocer si existe una vista. La he vuelto a recuperar de un proyecto y dado que mi blog en mi poco extenso blog es más facil de encontrar, me lo apunto por aquí:

  # Define template_exists? for Rails 2.3 (cause it's deprecated)
  unless ActionController::Base.private_instance_methods.include? 'template_exists?'
    def template_exists?(path)
      self.view_paths.find_template(path, response.template.template_format)
    rescue ActionView::MissingTemplate
      false
    end
  end

Poco rato después…

Googleando un poco he dado con la fuente: Drachenkind. Thx!

Ligero apunte para los que arrancado autotest, en Leopard, y no hacen más que ver test/unit y no sus preciados test conrSpec, esto tienen que añadir a sus .bashrc o .bash_profile:

export RSPEC=true
export AUTOTEST=true

Después de muchos proyectos y aplicar muchas formas para resolver el asunto del Breadcrumb (las “migas de pan” que suele aparecer en la parte superior para facilitar la navegación), me decidí en busca de alguna alma gemela – no voy muy sobrado de tiempo – que hubiese dado una solución óptima.

Y vaya que si lo encontre: http://szeryf.wordpress.com/2008/06/13/easy-and-flexible-breadcrumbs-for-rails/

Aún no la he llevado al límite pero me está pareciendo de lo más práctico y sencillo. Gracias szery.

Desde hace bastante me han ido llegando al Reader™ los cambios que se van incluyendo a lo último de Rails, cambios aún no “tangibles” y que si no lo trabajas día a día, no le vas echando caso alguno..

Así que nada, aunque el asunto ya lleva bastante tiempo (va por la entrada #20), poco importa, ya que de momento todo son cosas que no están en la calle de manera oficial. Me uno a los amigos franceses aunque no pretendo hacer una traducción ni literal ni completa (ojala tuviese el tiempo).

En fin, empezemos: Cambios del 17-12-2007 al 30-12-2007.

Manejador nativo mongrel

Rails llevará un Mongrel interno de manera nativa e independiente al desarrollo del Mongrel original. Dicho manejador de peticiones interno contará con la ventaja de no tratar las peticiones a nivel del Dispatcher sino de aplicación, con lo que estaríamos cerca de tener algo threadsafe en nuestras aplicaciones Rails.

Hacia la compatibilidad con Ruby 1.9..

El trabajo hacia la compatibilidad de Rails con la 1.9 sigue viento en popa, gracias a los incodicionales que están detras del framework aportando sus contribuciones a la causa. Con esta nueva versión de Ruby podremos olvidarnos de problemas con el encoding, nuevas sintaxis,.. pero que de momento de poco sirven mientras Mongrel no sea el primero que del el paso hacia la 1.9.

Optimizaciones

Muy interesesante para dos Flowers:

La mejora de decodificación JSON tanto para ActiveRecord (placechannel.com) como para ActiveResource.

Hace no mucho llegaría a vuestros feeds el consejo de Josh Susser sobre como hacer sencillo lo que normalmente nos tiene un rato dubitativos. ¿Donde meter/asociar las dichosas páginas estáticas?

Pese a que la solución de Josh es elegante, di con otra que me pareció bastante más dinámica y que con pequeños ajustes, se convierte, de manera oficial y por vía de apremio, en la solución de aquí en adelante.

Tan sencillo como crearte el controlador Pages..

Copialo

.. y añadir lo siguiente al routes.rb

map.page '/page/:name', :controller => 'pages', :action => 'show', :name => nil

Luego podrás añadir tantos páginas como quieras a la carpeta app/views/pages y enlazarlas es tan sencillo como..

# Con el fichero ayuda.html.erb en app/views/pages
link_to "Ayuda", page_path('ayuda')

Desde hace un tiempo, en la comunidad Rails, parece que no se habla de otra cosa que no sea Git: un control de versiones que, diseñado por Linus Torvald (se ve que tenía algún que otro rato libre), trae consigo una serie mejoras con respecto a los SMCs ya existente y sobre los que ya corren proyectos como: el propio fuente de Linux, Capistrano, Prototype o Scriptaculous.

Hace un par de días David Heinemeier anunció que ahora sería el core de Rails el que tomaría el mismo camino. Estoy en que se debe haber enterado de que en Flowers In Space no usamos otra ya otra cosa y no ha querido ser menos ;-P

Toda esta historía era porque quería completar la entrada de La Capitana con el método que seguimos para crear un repositorio para cualquiera de nuestros nuevos proyectos. Vamos allá.

Situados en local y dentro del proyecto que quiero gestionar con Git, realizamos lo siguiente:

1. $ git init
Si la carpeta contiene ficheros que versionar pasamos al paso 3.
2. $ touch fichero-borrame
3. $ git add .
4. $ git commit -a -m "Commit inicial"

5. $ git repack -d
6. $ git clone --bare -l . /tmp/your-proj.git
7. $ git --bare --git-dir=/tmp/your-proj.git update-server-info

Ya con el proyecto empaquetado nos dispodremos a subirlo. Para ello tendré en mi servidor instalado el git-core (al igual que lo tenía en local) y el usuario git, aunque esto ya es a gusto del consumidor (los temas de sysadmin no es que me apasionen demasiado).

8. $ scp -r /tmp/your-proj.git mi_usuario@miservidor:~/
9. $ ssh miservidor
10. $ sudo cp -r your-proj.git /var/git     # El usuario git debe ser
el owner de /var/git para el clone
11. $ sudo chown -R git:git your-proj.git/

Y ya por último nos clonamos el repositorio al local.

Si nos la vamos a traer a la misma carpeta donde está el "original",
no olvidar cambiarle el nombre al original o darle uno nuevo la nueva copia.
12. $ git clone ~/carpeta_desarrollo git@miservidor:/var/git/your-proj.git
nuevo-nombre-proyecto

Nada más. Suerte!

Con esta tarea me ví envuelto una mañana y que, gracias a la buena documentación internauta, fue menos doloroso de lo que en un principio pensé. No he hecho un paso a paso porque me parece tan simple que es mejor verlo, probarlo uno mismo y sacar tus propias conclusiones en local con todo montadito. Eso sí, os dejo algunas indicaciones de algunos detalles que hay que configurar.

El tema del PDF lo solucioné gracias a la ayuda de Dagi3d y Flying Saucer: Un generador de PDFs a través de XHTML y CSS la mar de sencillo hecho en JAVA.

A configurar solo tendreis que, en config/initializers/gmail_conf.rb, indicar las credenciales de la cuenta de gmail desde donde se enviarán los emails (:user_name y :password). Y en config/initializers/java_conf.rb deberemos indicar el path hasta nuestro directorio java.

Como me molesta mucho que las aplicaciones perezcan en el tiempo por colgarlo en hostings personales y demás, la cuelgo en Google Code que seguro que perdurá por los siglos de los siglos, ¿verdad n3uro5i5? :P

Descárgatelo en Google Code

Lo que empezó como una curiosidad se ha convertido en mi día a día. Eso sí, tirando de una opción de “alto nivel” en este mundo del Web Scraping: scRUBYt!

Esta herramienta nos da muchisimas posibilidades. Ya sea obtener resultados a través de terceras páginas (resultados Google, la temperatura de una localidad a través de Instituto Nacional de Meteorología,…) y crearnos un bonito mashup. Acceder al deep web, la información de sus bases de datos, de las aplicaciones web que nos interesen. Imaginación al poder.

Todo esto lo podremos hacer con las dos funciones fundamentales de scRUBYt!: navegar: traerse la página, clickar enlaces, rellenar inputs, traerse resultados paginados,… y hacer scraping sobre la información obtenida.

La primera de ellas lo consigue con WWW::Mechanize, el motor de navegación, el cuál tiene un buen problema a expensas de ser pronto solucionado: no interpreta el código Javascript. Hasta que esto cambie tenemos una alternativa: FirescRUBYt! (scRUBYt! y Firewatir), que suplirá dicha deficiencia usando Firefox para navegar (con JS, claro) y traerse la información (prometo escribir sobre como hacer funcionar toda historia).

Por otro lado, aunque el resultado del scraping lo podemos obtener en diferentes formatos, el más común es XML que, tratado con HPricot, hacen que trabajar con los resultados sea muy sencillo.

La verdad es que esta herramienta me ha permitido llegar de manera rápida y sencilla a toda la información que he necesitado de las aplicaciones web, aunque durante el desarrollo he echado bastante en falta que el metodo next_page funcionase (espero que en una pronta versión lo venga haciendo :-).

Os dejo mi ejemplillo de traductor con scRUBYt!

Copialo

Enlaces de interés:
Web – Wiki – Foro
http://www.rubyrailways.com/data-extraction-for-web-20-screen-scraping-in-rubyrails-episode1/