Archivo de Etiquetas de 'rails'

Más información sobre tog, nuestra plataforma para redes sociales

alberto
1 August 2008 in Empresa.
7 Comentarios

Como ya saben los habituales, llevamos unos meses trabajando junto con IBCmass en una plataforma libre para crear redes sociales escrita con Ruby on Rails llamada tog. El lanzamiento oficial se acerca (fecha objetivo: 1 de Septiembre), y aprovechando que ayer se publicó algo más de información del proyecto (presentación en español del proyecto) aprovechamos para dar un poco más de información en este blog.

No es como ning en el sentido de que no es un servicio online, si no que es una aplicación descargable, instalable, configurable, modificable, etc. Aunque más que una aplicación o un framework, es una plataforma. Tog es una aplicación Rails que soporta toda la funcionalidad básica de una red social (registro, perfiles, amigos, tags) a la que puedes ir añadiendo extensiones existentes o desarrollar las tuyas propias, que es quizás su mayor diferencia respecto a Lovbyless o Insoshi. Lo cierto es que el feedback que estamos recibiendo, de usuarios finales, técnicos de pequeñas y grandes (muy grandes) empresas, nos está dando aún más ánimos.

Aunque no es una presentación técnica, la presentación publicada ayer os puede ayudar a haceros mejor la idea (lo que hay, lo que habrá, como trabajamos, casos de éxito, como te puede ayudar a tí o como trabajar con nosotros, etc.). Y si quereis saber más, apuntaros a la lista de interesados que aparece en la web de tog, tened un poco de paciencia hasta el 1 de Septiembre, e id haciendo hueco en vuestras agendas para el evento que organizaremos a mediados de Septiembre.

Share This

Migración a Rails: certificacionpm

alberto
18 April 2008 in Empresa.
3 Comentarios

Hace un par de semanas pusimos online la versión 2.0 de certificacionpm, un simulador de exámenes para sacarse la certificación de Project Management Professional del PMI® que hemos desarrollado para con la empresa Lanarvi.

No lo publico aquí para hacerle publicidad (no creo que, por lo general, el público de este blog sea público objetivo de certificacionpm) pero puesto que la versión anterior estaba desarrollada en Java (JSF + JDO) y esta lo está en Rails, dos personas me han pedido que de forma poco sectarista explique las diferencias/mejoras/razones. Y lo voy a intentar.

Primero, a modo de disclaimer, decir que esta comparación es un tanto injusta, puesto que una migración siempre es más sencilla que hacer algo desde cero, puesto que ya llevas mucho aprendido. Aún así, una migración siempre hace también que acabes metiendo cosas nuevas. También podría ser que con otras herramientas Java el resultado hubiera sido distinto o ahora no hemos tenido que dedicarle excesivo tiempo a cuestiones de diseño/CSS. Digo esto porque no es tan sencillo como partir desde cero con el mismo conocimiento y realizar la aplicación. He intentado tener esto en cuenta y reducirlo a la parte de la lógica de la aplicación.

Diría que el tiempo empleado en el desarrollo en los aspectos comparables en la versión Rails ha sido aproximadamente el 40% del empleado en Java, quizás un poco menos. Las razones principalmente las siguientes:

  • Active Record: nunca trabajar con la base de datos fué taaaaaaaan fácil. En serio, es para probarlo. Me quedo con la espinita de JPA, pero ni SpringDAO, ni Hibernate, ni JDO lo hacen tan sencillo.
  • CSV: el soporte que trae Rails de serie para tratar ficheros CSV es increible. En Lanarvi gestionaban inicialmente el banco de preguntas en una Excel gigante, y lo cierto es que lo que con Java era un cierto sufrimiento, con Rails se solucionó en una tarde.
  • Lenguaje no tipado. Mucho tiempo pensé que la compilación y los lenguajes tipados eran necesarios (?) para prevenir errores, que eran una ayuda. Lo cierto es que sobre todo para proyectos pequeños he dejado de creerlo. Tienen un coste que no compensa. El tiempo de compilar, probar, etc. es demasiado alto para el beneficio obtenido en este proyecto.
  • Rails es (o puede ser) un todo. No sólo el framework de desarrollo, sino también el despliegue en remoto (caspistrano), la gestión de actualizaciones de la base de datos (migrations), etc. Reduce el tiempo destinado a estas cosas accesorias.
  • El entorno de desarrollo. Reconozco que mi pobre Powerbook con 1,2GB de memoria ha pasado ya los 3 años, pero ha rejuvenecido un par de años en rendimiento al cambiar Eclipse+Java+Tomcat por Textmate+Ruby+Mongrel.

En todo caso, como nota final. En Lanarvi están contentos, pero os puedo asegurar que lo que menos les importa a ellos es la tecnología, sino simplemente que ahora tienen una mejor aplicación.

Por cierto, que espero que próximamente liberemos el código de la aplicación (que no las preguntas) como software libre. Es bastante genérico y se puede reutilizar para hacer más simuladores. Estamos que lo tiramos XD.

Share This

Socios: ni con ellos ni matarlos.

admin
17 October 2006 in Empresa.
2 Comentarios

Quizás nos de miedo el mundo del emprendedor, muy solitario, por lo que podemos optar por trabajar con un socio. Un socio nos puede ayudar mucho en tiempos difíciles, porque pasar según que tragos solos es muy complicado. Además, el socio nos podrá dar ánimos cuando estemos flaqueando, porque este no es una camino fácil.

¿Pero es todo tan fácil y bonito?. Lamentablemente no. Os tocará pasar muchas horas juntos, más que con vuestras parejas, compartir dudas y problemas, eso puede hacer que la relación se tambalee lo mismo que puede hacerla más fuerte. Por muy amigos que seáis antes de comenzar esta aventura.

Lo que en un principio puede ser amistad, buen rollo y alegría, se puede convertir en malos modos, desconfianza o algo peor de un día para otro. ¿Razones?…. muchas y variadas. Algunas de ellas pudieran ser (dejamos de lado las personales, que también pueden salir):


  • que uno de los socios piense que trabaja más que el otro, por las razones que sea (por ejemplo, que uno de los dos tenga familia y el otro trabaje todo el fin de semana).

  • que uno de los socios piense que el otro le menosprecia o no valora sus opiniones.

  • que uno de los socios piense que el otro no se implica en determinadas tareas menos gratificantes (a no demasiados les gusta ser contable, administrador, o secretaria).

  • que cada uno vea el negocio de una forma distinta, discrepando que tareas debe hacer la empresa y cuales no.



Esto es casi inevitable. Cada persona tiene su propia realidad, y con ello tenemos que vivir. Pero si hemos optado por trabajar con un socio, con sus ventajas y sus inconvenientes, sólo hay un consejo de obligado cumplimiento:


  • diferenciar cuando se es socio, y cuando se es trabajador de la empresa


Cada uno de vosotros deberíais ser socios sólo en los momentos en los que toca ser socio (juntas, reuniones varias, etc.), dónde tomareis decisiones que afecten al futuro de la empresa. El resto del tiempo tenéis que ser trabajadores, con derechos y deberes como tales.

Antes de empezar a trabajar deberíais definir las funciones de cada uno, y poder exigiros según esas funciones. Deberías tener claro cuales son las responsabilidades de cada uno (no todo tiene que ser al 50%), si es posible incluso por escrito, y actuar durante la jornada laboral en función de esas responsabilidades. Esto no quiere decir que cada uno haga una función el otro se quede mirando, pero siempre tiene que haber un responsable último de las cosas, de cada una de las cosas, porque si no se quedarán por hacer. Y asignar parte de vuestro tiempo a realizar estas labores.

Por ejemplo, determinar quién será el encargado (con el poder de tomar decisiones) de los temas de administración, de los temas de finanzas, comerciales, marketing, o de los asuntos de sistemas (¡de todos!). Determinar quién tendrá la última palabra incluso de la propia empresa (aunque suene un poco raro en una empresa de este tamaño, quién es el CEO), y su palabra debería ir a misa durante la jornada laboral, para tomar decisiones y para exigir al otro si no lo ha realizado las suyas. En las juntas de socios podéis decidir si cambiáis esa forma de trabajar, o si cambiáis de puestos cada X tiempo o incluso sueldos (que es competencia de la junta también lo podéis decidir), pero en el día a día cada uno tenéis otras funciones.

¿Radical o exagerado?. No lo creo, yo tuve un socio.

Share This

Alianzas creativas (1)

admin
23 August 2006 in Empresa.
3 Comentarios

En el capítulo de ayer dijimos que la mayoría de los productos que tienen éxito últimamente nacen siempre de una necesidad, y que observando bien de qué se queja la gente podemos encontrar buenas ideas para desarrollar nuestros productos.

¿Pero que sucede si es de un ámbito en el que no tenemos ni idea?. Aunque nos cueste mucho creerlo, los informáticos sabemos mucho de lo nuestro pero no demasiado de los demás. Pongamos el caso de una consulta médica. Podemos tener más o menos claro que hay clientes/pacientes, citas/visitas, enfermedades y medicamentos. ¿Lo tenemos todo para desarrollar nuestra aplicación?.

Obviamente no. ¿Sabemos si realmente el problema de la consulta es gestionar las citas? (eso lo hace el Outlook), ¿o será el acceder rápidamente al historial?. ¿O será agrupar sencillamente los documentos físicos que genera cada paciente?. ¿Y si el visitador médico le incluye de regalo un programa de gestión que es justamente lo que busca de regalo con otros servicios?. Y lo mismo es aplicable para cualquier otro área de actividad, incluso el desarrollo.

¿Entonces que hacemos?: aprender. Alguien te tiene que dejar aprender de su negocio para que el resultado sea óptimo. Si no lo hacemos así, puede que todo el tiempo que le dediquemos a nuestro producto no tenga sentido.

Supongamos que tienes un amigo médico, aunque realmente vale cualquier tipo de profesión: carpintero metálico, antenista o camionero, simplemente cada uno tiene su propio problema. Cada vez que os reunís, aprovechando que eres informático te cuenta sus problemas con la informática, y tu ves claramente un hueco ahí. Bingo! :-D. Si tu amigo es el jefe, lo tendrás más fácil, aunque corres el riesgo de que te explote.

Si no es el jefe (o si lo es pero además de amigo es justo), o si es un tercero que aporta otro servicio (como el visitador que comentábamos anteriormente), podéis crear algún tipo de alianza que sea buena para los dos. Por ejemplo:


  • Desarrollo a un precio reducido. Ya que te está permitiendo aprender sobre su sector, puedes cobrarle un precio reducido (digamos un fijo mensual suficiente para vivir). Él obtiene un producto mejor, y a ti te están pagando por algo que normalmente no harían (si estamos desarrollando un producto propio), además de conseguir un mejor producto.

  • Lo ideal sería que este socio se implicase en las ventas. Si él habla de tu producto a sus colegas (en reuniones, foros o boletines), tendrás mucho hecho del primer paso del marketing, es más, lo están haciendo por ti. Para asegurarte de que se implica, ofrécele un % de cada licencia/instalación/xxxx que vendas.

  • Combina las anteriores a vuestro gusto, y añade ideas de tu propia cosecha.


Estas alianzas no siempre son posibles o fáciles, por eso hay que incentivarlas, para asegurarnos de que todos tenemos interés en que creemos un producto con posibilidades de venta. No es una garantía de éxito, pero todo ayuda.

Share This

Lo que salió del RailsDay06

admin
21 June 2006 in Empresa.
(0 Comentarios)

Si hace unos días contaba que había tomado parte del Rails Day 06, hoy puedo contar que Aitor ha puesto online el resultado. Obviamente no está terminado ni de lejos, pero teniendo en cuenta las circunstancias no está mal.


Más detalles en el post de Aitor al respecto.

Share This

Rails Day 2006

admin
18 June 2006 in Empresa.
5 Comentarios

Ayer participé en el Rails Day 2006 junto con Aitor. Creo que éramos los únicos españoles entre los 180+ equipos. Unos portugueses, un par de alemanes, algún canadiense, australiano…. y mucho americano. Nosotros sólo usamos 8 de las 24 horas disponibles, por lo que tampoco espero que ganemos nada, pero bueno, pasamos un muy buen rato, eso sí :-D.

Nuestra aplicación… la veréis online pronto, pero la experiencia ha sido mi primer escarceo serio con el famoso Ruby On Rails.

Ya que Ibon está preocupado, un pequeño resumen sobre este contacto con RoR:


  • El fácil: puede ser que sea más rápido programar en RoR. El mero hecho de ser más pequeño y convencional ya es un plus (en java hay demasiadas posibilidades demasiadas veces), y el que la mayoría de la gente que llega a RoR provenga de Java (u otras plataformas) también hace que no se parta de cero. El problema puede venir (si viniera!) para una aplicación de uso intensivo, a veces los logs asustan.

  • El hecho: hacer cualquier aplicación de cara al gran público con un acabado final profesional cuesta se haga como se haga ;-).

  • El truco: si estas con alguien que ya sabe se aprende más fácil y rápido ;-). No estoy seguro de que Aitor no este tan contento con mis interrupciones, pero bueno.

  • El bonus: aprender algo nuevo. RoR no es la solución a los problemas del mundo (no hoy, no ahora), pero siempre es divertido hacer algo nuevo.


Se usará RoR en Linking?. ¿Por qué no?, hay sitio para todo.
PS: Estuve buscando un Rails for Java Developers, pero no lo encontré, algún día quizás lo escriba.
UPDATED 19/06/06, 11:25: Aitor da su opinión y muestra nuestro trabajo.

Share This

Close
E-mail It