Hace unos días me invitaron de Packt Publishing a hacer la reseña de un libro y aún sin tener experiencia previa acepté.
Sin embargo, después de leer varias reseñas en sitios como Amazon y similares no quise seguir el mismo formato: leer de inicio a fin el libro y publicar mis comentarios.
En lugar de eso quiero hacerlo como un reporte de avance, cada capítulo leído compartir mis opiniones sobre el tema, como presentó la idea el autor, qué me parecieron los ejemplos del texto.
Así que a partir de hoy inicio la lectura de “Learning Mongoid” de Gautam Rege.
Espero me acompañen en esta lectura.
Finito.
Anotaciones de diversos temas relacionados con código abierto, metodologías de desarrollo y programación con Ruby on Rails
Mostrando las entradas con la etiqueta programming. Mostrar todas las entradas
Mostrando las entradas con la etiqueta programming. Mostrar todas las entradas
jueves, febrero 06, 2014
Reseña del libro "Learning Mongoid"
Etiquetas:
book-review,
development,
español,
opinion,
programming,
rails,
ruby
Book Review: Learning Mongoid
A few days ago I was invited by Packt Publishing to publish a book review and even without prior experience I do accepted.
But after reading many book reviews in sites like Amazon I don't want to use the same format: read the book from beginning to end and then publish my comments.
What I want to do is to publish an advance report for each chapter I read and share my opinions about the subject, the way the author presented the idea, how much I liked the explanations or the code.
So, I’m beginning to read “Learning Mongoid” by Guatam Rege.
Hope you join me in this reading.
Finito.
But after reading many book reviews in sites like Amazon I don't want to use the same format: read the book from beginning to end and then publish my comments.
What I want to do is to publish an advance report for each chapter I read and share my opinions about the subject, the way the author presented the idea, how much I liked the explanations or the code.
So, I’m beginning to read “Learning Mongoid” by Guatam Rege.
Hope you join me in this reading.
Finito.
Etiquetas:
book-review,
development,
english,
opinion,
programming,
rails,
ruby
martes, diciembre 28, 2010
Poor's Man Ruby Performance
Ya sé que existen muchos, tal vez cientos de evaluaciones y comparaciones del performance de las diferentes versiones e implementaciones de Ruby.
Muchas de ellas aplicadas con el mayor rigor científico que se pudiera exigir a algo tan trivial pero que al final siempre apantallan con sus gráficas y análisis.
En esta tarde de vacuidad, se me ocurrió hacer mi "Poor's Man Ruby Performace" chart solo pa'salir de dudas y jugar un poco con Rubinius, una implementación de Ruby que recientemente llegó a su versión 1.2.
En la gráfica comparo las siguientes versiones de Ruby:
- Rubinius 1.2 via RVM
- Ruby MRI 1.8.7-head via RVM
- Ruby MRI 1.9.2-head via RVM
- Ruby 1.9.2p136 via Brew
Todo esto corriendo en una MacBook Pro con 4GB de RAM y un Intel Core 2 Duo @ 2.2 GHz.
En la gráfica es obvio el interesante (y excelente) desempeño de Rubinius pero tiene el 'pero' de que la versión actual sigue implementando MRI 1.8.7. Yo ando de curioso ya con la versión 1.9.2 pero hasta el siguiente release se van a emparejar.
Antes de cerrar, les dejo la gráfica:
Y no, no es una inocentada.
Finito.
Etiquetas:
development,
fun,
ideas,
macosx,
opinion,
programming,
ruby
domingo, octubre 10, 2010
(Not So) Pragmmatic Programmer
Hace un par de semanas me involucré en un proyecto para desarrollar una aplicación para una agencia de cinematografía. La "prueba de concepto" (como dicen los grandes consultores) la hice en Rails 3 con alguna de las nuevas gemas de la corona. Incluso así se mostró el proyecto al prospecto a cliente. Sobra decir que le gustó la aplicación pero dejó en claro que no estaba dentro de sus prioridades inmediatas. No problema por eso, pero parte de la reunión también fue revisar su actual servicio de hosting para validar el soporte a Rails.
El servicio de USD$8.00 al mes no da para mucho. Claro que no para soportar Rails. ¿Qué hacer entonces? ¿Qué hacer con un hosting debajo de básico que solamente soporta cpanel? Aparecía soporte para Python ¡Oh si! No es Ruby pero no se puede caer más bajo ¿o si? Deficiente soporte. Mis habilidades cpanel'istas no dieron para arrancar web2py en el servidor.
Y ahí, debajo de la manta del 'te lo dije' apareció PHP. OMG! Sí, tendría que usar PHP. ¿Cómo podría hacer menos traumática la experiencia? Una breve búsqueda en Google me arrojó la referencia a Symfony, un framework MVC muy interesante y no tan lejano del modo Rails. Lo descargué en mi máquina, seguí el tuto y conseguí arrancar un módulo completo (controlador, vistas y modelo).
En ese momento decidí hacer la prueba de fuego. Subirlo al servidor y echarlo a andar. FAIL!. Symfony también funciona a base de 'generators' y como tal requiere el acceso a la línea de comandos. USD$24.00 al mes me darían acceso pero no hubo respuesta favorable del cliente. El tan interesante y correcto framework tuvo así que ser descartado.
¿Qué queda a estas alturas? ¿Qué queda después de buscar opciones correctas? ¿Qué queda después de buscar las mejores tecnologías? Usar tecnologías crudas, simplistas y mezclarlas con scripts de internet. Hacer un pequeño Frankestein. Y finalmente es más fácil hacerlo con PHP que con otra selección.
¿Es esa la explicación del bajo nivel que generalmente se asocia a PHP? Al no tener más opción que trabajar con lo menos (hosting de USD$8.00) hay que hacer lo peor. Hacer lo menos. Hacer lo que funcione como sea.
Symfony es una muy buena muestra de un buen nivel de desarrollo con PHP. Encontré otros frameworks minimalistas al estilo de Sinatra (Frank.php) y similares pero la limitante del hosting no permitió aprovecharlos. Solo queda hacer el trabajo sucio con código sucio. Y será en PHP. Don't take it that hard.
Finito.
El servicio de USD$8.00 al mes no da para mucho. Claro que no para soportar Rails. ¿Qué hacer entonces? ¿Qué hacer con un hosting debajo de básico que solamente soporta cpanel? Aparecía soporte para Python ¡Oh si! No es Ruby pero no se puede caer más bajo ¿o si? Deficiente soporte. Mis habilidades cpanel'istas no dieron para arrancar web2py en el servidor.
Y ahí, debajo de la manta del 'te lo dije' apareció PHP. OMG! Sí, tendría que usar PHP. ¿Cómo podría hacer menos traumática la experiencia? Una breve búsqueda en Google me arrojó la referencia a Symfony, un framework MVC muy interesante y no tan lejano del modo Rails. Lo descargué en mi máquina, seguí el tuto y conseguí arrancar un módulo completo (controlador, vistas y modelo).
En ese momento decidí hacer la prueba de fuego. Subirlo al servidor y echarlo a andar. FAIL!. Symfony también funciona a base de 'generators' y como tal requiere el acceso a la línea de comandos. USD$24.00 al mes me darían acceso pero no hubo respuesta favorable del cliente. El tan interesante y correcto framework tuvo así que ser descartado.
¿Qué queda a estas alturas? ¿Qué queda después de buscar opciones correctas? ¿Qué queda después de buscar las mejores tecnologías? Usar tecnologías crudas, simplistas y mezclarlas con scripts de internet. Hacer un pequeño Frankestein. Y finalmente es más fácil hacerlo con PHP que con otra selección.
¿Es esa la explicación del bajo nivel que generalmente se asocia a PHP? Al no tener más opción que trabajar con lo menos (hosting de USD$8.00) hay que hacer lo peor. Hacer lo menos. Hacer lo que funcione como sea.
Symfony es una muy buena muestra de un buen nivel de desarrollo con PHP. Encontré otros frameworks minimalistas al estilo de Sinatra (Frank.php) y similares pero la limitante del hosting no permitió aprovecharlos. Solo queda hacer el trabajo sucio con código sucio. Y será en PHP. Don't take it that hard.
Finito.
Etiquetas:
architecture,
development,
minimalist,
mvc,
patterns,
programming,
web
Suscribirse a:
Entradas (Atom)