Tag devel - Userlinux.net

No me quiero hacer pesado con este tema, pero hoy a uno de mis compañeros le ha petado el Eclipse y hemos tenido que configurar gedit para que molara, literalmente. No es que haya sido muy tedioso pero no recordaba ciertos pasos que me apetece documentar. Allá vamos.

Ha sido una de esas cosas que te divierte mientras la programas. Siempre me había interesado el funcionamiento de los widgets y esta vez me tocó pelearme para crear los de Moneting. Ha sido más sencillo de lo que imaginaba pero no por ello menos divertido.

Consiste en un pequeño script que se encarga de generar la imagen correspondiente con la librería GD y parsear la URL que se le pasa para traducirlo en una petición válida dentro del sistema. Como se puede adivinar, la respuesta es una imagen de tipo GIF.

Todavía no he implementado ciertas mejoras que tengo anotadas, pero me apetecía contar el micro-hito :P.

Los que en alguna etapa de nuestra vida nos hemos dedicado y/o dedicamos al desarrollo nos hemos cuestionado el entorno de desarrollo que utilizamos (¡no digáis que no!). Para gustos pintan colores y no pretendo llegar al corazoncito de los trolls convirtiendo estas lineas en una sangría de argumento "la mía es más larga".

He probado varios IDE distintos, cada uno con sus ventajas e inconvenientes y al final, después de muchos viajes de colores, extensiones y shortcuts, me he quedado con una herramienta que viene de serie en GNOME: gedit.

Es algo que todavía no llego a entender ni asimilar. He pasado la mayor parte de la tarde para configurar la nueva versión 2.0 de CodeIgniter-Reactor con varias librerías que, para mi forma de desarrollar, son indispensables en cualquier framework de programación orientado a web:

• HMVC: Gracias a la librería de Wiredesignz podemos ordenar nuestro código en módulos y simplificar la lógica de la aplicación.
• ModulesModule: Ahora que todo será un módulo, no vendría mal un módulo encargado de ejecutar las tareas más comunes de los módulos (instalar, desinstalar, actualizar...). Un módulo de módulos.
• SettingsModule: No me gusta cargar la configuración desde ficheros config/*, por comodidad y para que el usuario pueda cambiar cualquier parámetro ajustable de una aplicación, prefiero hacerlo en base de datos y cachearlo a disco si es necesario. Me quedo con la librería de PyroCMS.
• ThemesModule: Otra característica imprescindible sería tener una aplicación themeable y que desde un interfaz de administración se pueda cambiar tranquilamente el aspecto de la misma. Para ello podemos hacer uso de este módulo capaz de instalar y desinstalar themes.
• TemplateLibrary y TagsLibrary: Una vez hemos decidido hacer la aplicación modular y themeable siguiendo el patrón MVC, un buen lenguaje de template para que los diseñadores no se vuelvan locos con el lenguaje dinámico sería un punto más.
• MigrationsLibrary: Una vez lo pruebas se convierte en musthave. Se trata de una librería para hacer migraciones de versiones en base de datos. Gestiona los cambios entre versiones de forma sencilla.

Durante el último medio año, desde que CodeIgniter 2.0 ha visto publicada su versión de desarrollo en BitBucket la pregunta de "¿cuándo será estable?" ha rondado sobre los usuarios de este framework. La verdad es que CodeIgniter 2.0 es estable desde hace unos meses. Alguien desde EllisLab (la empresa que se encarga de su desarrollo) pudo haber congelado ya la versión 2.0 (hg tag v2.0; hg push) pero todavía no se han decidido.

CodeIgniter 2.0 es una nueva release, lo que significa una ocasión perfecta para EllisLab en lo que se refiere a cambios "mayores" que puedan afectar a la compatibilidad hacia atrás. Un ejemplo de esto son los nuevos Models, que ahora necesitan extender la clase CI_Model en vez de la antigua Model. Es un cambio más que aceptable para una nueva release y es normal que se piensen las cosas dos veces antes de lanzarse.

Me he dado cuenta de que no puedo utilizar Eclipse en el Macbook a no ser que tenga una fuente de alimentación cercana en cortos períodos de tiempo, la verdad es que Java hace resoplar los ventiladores del cacharro cosa fina.

Así que tocaba buscar alternativas más o menos cómodas que tuvieran al menos dos o tres características básicas: coloreado de código, integración total con Mercurial y posibilidad de edición remota (esta última todavía no la he probado). Leyendo y buscando por ahí me he decantado por Textmate. En principio me he bajado la versión trial válida para 30 días pero me está gustando tanto que hasta he pensado en aceptar donaciones :P. La verdad es que lo de los Bundles (Mercurial, CodeIgniter...) es una pasada, la elección de colores -entre los múltiples themes que trae- es exquisita y su sencillez es suprema.

De todas formas no todo iba a ser bueno, así que seguiré buscando e informando de las novedades que pueda aportarme este software.

Después de leer un poco y siguiendo -muy de refilón- la última entrada me gustaría recomendar algunas lecturas que pueden ayudar tanto a la organización de un equipo de desarrollo como a convertir tu aplicación web en un servicio masivo:

• Método Scrum.
• Tillate.com implementa scrum.
• Serie "Scaling Up" de Brandom Savage.

Espero que sea de ayuda y, como dije antes, toda experiencia previa, comentario, duda o mejora es bienvenida.

Cuando cuentas con una herramienta -para lo que sea- es interesante conocer todas sus posibilidades para emitir una valoración justa. Últimamente, como muchos de vosotros sabeis, en programación se están poniendo de moda los archifamosos frameworks de desarrollo.

Normalmente suele existir una guerra sana entre ellos, por sus características, configuraciones, optimización, posibilidades... y muchos otros factores que no vienen a cuento. Pero casi todos tienen inconvenientes.

Muchas veces me he planteado el uso de uno u otro, la verdad es que he probado varios y ninguno me ha convencido del todo. Quizás sea por el desconocimiento de la herramienta, -no saber cómo se mueven sus tripas o no querer saberlo (así somos los vagos)-.

Sin embargo estoy totalmente de acuerdo con Harrie Verveer y su opinión sobre la actualidad de los frameworks de desarrollo (para entendernos, básicamente éste enlace es el motivo del post).

Es posible que por eso -desconocimiento, falta de tiempo y/o ganas- no esté por la labor de escalar esa curva de aprendizaje que todos tienen y siga con mi mini-fw de toda la vida, el cual conozco como si lo pariera, ¡qué curioso! :D.