Archivo de la etiqueta: Ruby

Que funcione. El resto es secundario.

Hace poco hice un proyecto para manejar información de mis clientes. Empecé a hacerlo en Rails, pensando que de esta manera podía reutilizar el código mas adelante y hacer una página que pudiera servirle a otros, o al menos mostrar un código Rails como proyecto Open Source para tener algo nuevo en GitHub.

ERROR

Los proyectos propios tienen que tener un objetivo único. Y si es un proyecto personal, en la mayoría de los casos ese objetivo debe ser resolver un problema. La reutilización, la utilidad que pueda tener para otros, la limpieza de código para ser mostrado, todo eso es completamente secundario y sólo debería tenerse en cuenta luego de haber terminado el proyecto y haberlo usado un tiempo.

Como diría Torvalds, si no resuelve una necesidad inmediata entonces seguramente está sobre-diseñado.

Finalmente abandoné el proyecto en Rails (que ya cumplía con toda la funcionalidad, pero me daba vagancia hasta iniciar el daemon de Rails para usarlo), y terminé haciendo en Ruby una pequeña herramienta de consola que me permite administrar fácilmente esta información con una base de datos SQLite.

Ventajas

– Lo hice en menos de dos horas.

– Interfaz ultrasencilla por línea de comandos.

Simplemente escribo lo que quiero que pase (ej. client create “cliente”).

Interacción mínima – mouse = developer feliz.

– Casi no tiene dependencias. Funciona sin necesidad de ningún daemon prendido.

La aplicación de Rails necesitaba un servidor web y una base de datos MySQL corriendo.

– Código custom, sin convenciones.

El código custom, especialmente en proyectos pequeos, permite adaptarnos muchísimo mejor a las necesidades. Además, tener una estructura custom del proyecto favorece a la memoria del código. Supongo que tiene que ver con que al verse uno obligado a tomar decisiones sobre dónde poner los archivos, esto asienta en la memoria la estructura del proyecto.

– No me perdí nada de Rails

Usé la gema ActiveRecord así que manejé la base de datos sin tocar SQL.

– Performance

A veces cargar algunas gemas o no puede hacer que la aplicación de consola tarde algunos milisegundos mas en realizar alguna tarea. Al tener un código custom, podés hacer que sólo cargue las gemas cuando la aplicación lo requiere.

– Refactor fácil

Al no estar atado a una estructura de directorios fija como Rails, tenemos total libertad al hacer refactor. No tenemos que adaptarnos a las convenciones, sino al problema concreto con el que estamos lidiando.

Aprendizaje

– No hacer proyectos web en un principio, a menos que no quede otra.

Hacer algo que funcione para uno, bien rápido. Luego, ver de exportarlo a web si realmente tiene sentido, si realmente alguien mas va a usarlo. Las tecnologías web necesitan un servidor, son mas complicadas de desarrollar y mantener (entre otras razones, porque están pensadas para ser multiusuario) y pocas veces valen la pena.

– Objetivo único del proyecto: resolver un problema. Lo demás (subirlo a GitHub, etc.) es secundario y opcional.

– No añadir funcionalidad / convenciones / buenas prácticas sólo porque se supone que debemos hacerlo. La prioridad es resolver el problema. Si la buena práctica ayuda a resolverlo entonces implementarla. Sino, no.

Por ejemplo, podría haber usado Bundler para manejar las dependencias. Pero, en realidad, es sobreingeniería. Bundler debería usarse cuando hay que deployar aplicaciones complejas con muchas dependencias.

– Minimizar las dependencias (daemons y gems) y mantener la aplicación liviana.

Blogs ultralivianos y geeks con Nanoc

Hay varias cosas que me molestan de motores de blog como WordPress: su lentitud, el que haya que acceder a Internet para usarlos, el uso de base de datos, la inevitable forma en que los viejos post quedan en el olvido. Claro, un blog es, en realidad, algo muy relacionado al tiempo. No es un CMS estático. Obviemos esa crítica, pero tengo otras. El editor WYSIWYG es muy molesto, especialmente cuando se trata de agregar código. Además, de estar hecho con un lenguaje “feo” como PHP.

¿No estaría bueno editar nuestros artículos desde la línea de comando? ¿no estar limitados por la arbitrariedad de los WYSIWYG? ¿servir contenidos estáticos y de esta forma hacer que nuestro sitio sea super liviano? ¿no depender de una base de datos y de esta manera poder hacer backups mas fácilmente? ¿Y aún así, conservar muchas cosas que nos ofrece un CMS? Nanoc es para vos.

Backuper

Backuper es una herramienta para hacer backups en Linux y está programada en Ruby. Se ejecuta por consola. Consta de dos partes, una para el servidor local y otra para el cliente. Soporta:

1) Compresión de los archivos con tar.

2) Posibilidad de limitar el número de backups a un número configurable.

3) Backup de carpetas y bases de datos MySQL, pero extensible a cualquier otra cosa. Es fácil agregar una clase y permitir que, por ejemplo, haga también backups de MongoDB, Postgre o, incluso, que ejecute algunas acciones antes o después de hacer los backups.

4) Posibilidad de sincronizar la configuración desde el cliente.

¡A hacer backups que se acaba el mundo!