Queremos dar la beinvenida a la red a un proyecto que acaba de nacer y en el que hemos paortado un granito de arena.
Ideas4all es…, bueno mejor que contarlo nosotros aquí lo teneís en un vídeo que hay en su página web:
Enhorabuena a los promotores del proyecto.
Hoy Javier anuncia el lanzamiento de Pymecrunch una iniciativa que apoyamos en ASPgems.
Por suerte hemos recibido mas de un mail de felicitación, y además algún otro para preguntarnos porque apoyamos esta iniciativa.
Esperamos que PymeCrunch sirva sobre todo para difundir el uso de la tecnología entre las PYMES españolas. Aunque la penetración de Pc’s y uso de internet son altas, el uso de aplicaciones en la PYMES es muy bajo. Nosotros queremos contribuir a que eso cambie.
En realidad lo que queremos como decia el CEO de Sun Jonathan Schwartz, es que primero suba la marea y luego ya competiremos cuando la marea haya subido. Por eso queremos que Pymecrunch hable de las iniciativas de que sean relevantes para las PYMES. Luego cuando una PYME haya decidido dar el salto hacia la tecnología, esperamos que cuente con nosotros.
Queremos aprovechar para dar las gracias a la gente de loogic, ellos si que saben de esto.
La semana pasada los de 37signasl tuvieron una caida que se puede leer en: 37signals System Status.
Cuando tienes tu infraestrcutura en un proveedor y este te falla es un serio problema. Los chicos de 37 signals hicieron todo lo que estaba en su mano, pero eso probablemente para algunos de sus clientes eso no sea suficiente. Han actuado rápido y han compartido la información que tenían con sus clientes.
El punto que me parece mas discutible es que ellos han pasado la responsabilidad a su proveedor. Y yo creo que eso es un error, el proveedor lo eligieron ellos, y han dimensionado el servicio.
En su caso además es la segunda vez que rackspace les falla.
Una cosa es contar lo que pasa, pero yo creo que la responsabilidad es del proveedor. El cliente de un ASP te paga entre otras cosas para no tener esos problemas.
Ya están publciados los contenidos de la conferencia Rails del 2.007.
Están e: Conferencia Rails Hispana
Pronto empezaremos con la del 2.008.
Poco a poco vamos haciendo pequeñas contribuciones de vuelta:
Ademas de soporte en listas, blogs personales, charlas, organización de la conferencia, etc.
Una compañia basada en open source no esta obligada a contribuir de vuelta, pero creemos que hacerlo está bien porque participas de aquello de lo que vives, y eso resuena. Son contribuciones humildes, pero estamos.
El pasado 6 de noviembre participé en una mesa redonda sobre frameworks en SIMO. Expertos en Drupal, Code Igniter, Zend Framework, .Net y Sun JSF expusieron su punto de vista sobre el estado del arte de los frameworks para desarrollo de aplicaciones web.
Yo por mi parte me encargué de explicar porqué hemos elegido Ruby on Rails como nuestra herramienta favorita para este tipo de proyectos. Podeis ver a continuación la explicación -más o menos fidedigna- que realicé en los 4 minutos de presentación que me correspondían.
Ruby on Rails es un framework para desarrollo de aplicaciones web escrito en el lenguaje de programación Ruby.
En ASPgems, donde todo el equipo tenemos experiencia en otros entornos sobre todo en proyectos grandes en el mundo corporativo, utilizamos Ruby on Rails porque nos permite desarrollar proyectos web de calidad en tiempos muy competitivos y usando metodologías de programación ágiles. Esto nos permite empezar a desarrollar un proyecto con un número mínimo de requisitos que sabemos que van a cambiar mucho durante la vida del proyecto, y que podemos aceptar cambios incluso en los días previos a la salida a producción sin que tengan un impacto significativo en la mayoría de los casos.
Encontramos varias ventajas en Rails sobre algunos otros frameworks. Por un lado, el lenguaje sobre el que se desarrolla, Ruby, es un lenguaje muy orientado a objetos, potente, y muy expresivo. Con pocas líneas de código puedo conseguir muchas cosas, con lo que la legibilidad del código es mayor y la probabilidad de errores se reduce.
Ruby on Rails, es un framework con opinión que se basa en el principio de “Convención sobre Configuración”, de forma que si yo utilizo las convenciones que el framework espera, Rails es capaz de hacer gran parte del trabajo por mí. En rails no hay que mantener ningún fichero XML para configuración de filtros, mapeos, validaciones o nada parecido. Además, al trabajar todo el mundo siguiendo las mismas convenciones, se puede incorporar gente a un proyecto en marcha o rotarla con un coste mínimo.
Otra gran ventaja de Rails, es la filosofía misma del framework. Rails está creado a partir de un proyecto real puesto en producción. Se desarrolló un proyecto web con Ruby siguiendo patrones de diseño estándar como MVC, Inversión de Control, Persistencia de Datos… y se vio que el proyecto funcionaba bien y que había varias partes reusables. Ese código reusable se extrajo para hacer un proyecto Open Source. Además, se le añadió un mecanismo de plugins para poder ampliar o modificar el comportamiento del framework de forma simple.
Como el código del framework es fácil de entender, y es sencillo crear un plugin, en seguida se consigue una comunidad de desarrolladores muy activa. Cuando un plugin se usa mucho dentro de la comunidad, se acaba incorporándo al núcleo del framework; y al contario, si una parte del framework no la usa casi nadie, se acaba sacando como plugin. Se puede seguir usando, pero no se mantiene dentro del framework, con lo que no se convierte en un framework monstruo donde cabe todo.
Debido a esto, tenemos un framework que está vivo y que se va modificando según los proyectos y las necesidades reales de la comunidad que lo usa en sus proyectos en producción.
El resultado es que, para una persona acostumbrada al desarrollo web, se puede desarrollar una aplicación completa con muy poco código. Te puedes centrar en la lógica de negocio y dejar muchos detalles de implementación al framework.
Esto choca con otros frameworks que están pensados en abstracto para cubrir cualquier caso posible, y acaban teniendo una arquitectura tan compleja que en muchos casos te da la impresión de que, más que desarrollar, estás luchando contra el framework.
Seguimos estudiando porque las PYMES usan tan poco las TI, ayer cenando con un amigo que ha montado ya varias emrpesas de éxito el me decia que:
Como resultado su estrategia es:
Yo creo que el problema que hay detrás es que la falta de información y formación hace que la toma de una decisión informada no sea posible. ¿Como lanzarse a poner en marcha un CRM con el coste que esto tiene y lo crítico que es para tu negocio sin tener buena información de cuales son las alternativas y cuales deben ser los parámetros de valoración?
Nuestra conversación de anoche me hace creer aún mas en que “menos es mas” es una de las claves para mejorar la penetración de las TI en las PYMES
Hoy hablaba con un potencial cliente, y tras compartir el contenido del Agile Manifesto me decía: “¿donde estabais hace 3 meses?”
Ha pasado tiempo desde que empezamos con ASPgems, y de hecho el primer documento que escribimos antes de nada era un “Manifesto” inspirado por el Agile Manifesto.
El tiempo ha pasado, pero cada vez estamos mas seguros de que es el camino a seguir. Ahora solo queda que los que tienen un proyecto y crean en los principios del Manifesto sean capaces de encontrarnos.
¿Tienes un proyecto que quieres hacer siguiendo estos principios? En info@aspgems.com te daremos nuestra respuesta ;-).
Offshore programming es una forma elegante de llamarle al arbitraje salarial.
Se trata de encargar un trabajo de desarrollo de software allí donde los desarrolladores son más baratos y con el precio como criterio principal en la elección del proveedor.
Está práctica es muy frecuente sobre todo en USA y también en el Reino Unido. En España es una práctica que no ha tenido demasiado éxito hasta ahora quizás porque las diferencias de coste no eran tan grandes. En España el “offshore development” ha sido tradicionalmente sustituido por las empresas de “body shopping”, no mencionaré ninguna porque igual se ofenden ;-), que venden muy barato horas de programación sin tener muy en cuenta ni la experiencia ni la calidad de los programadores.
Con la subida salarial y la demanda de profesionales cualificados en España subiendo, algunas empresas se han acercado a esta modalidad de desarrollo contratando desarrollos fuera de España (países del este, India, Argentina, etc.)
Pues bien nosotros llevamos ya 3 clientes que se acercan a nosotros después de no haber tenido éxito con sus proyectos de “offshoring” con aplicaciones Rails. y yo creo que la razón fundamental es que en proyectos cortos, con especificaciones poco definidas, y en los que la capacidad de adaptación es imprescindible, las distancias se hacen enormes, y las diferencias horarias mas todavía.
En nuestros proyectos el uso de SCRUMgem nos hace competir con las compañías de “offshoring” en aquello que ellos no pueden hacer que es la proximidad con el cliente, la flexibilidad en los cambios, y la capacidad de negociación cara a cara con el cliente.
Además todo esto es posible cuando cuentas con un equipo de gente muy cualificada, que en la mayoría de los casos a anticipado los cambios que vas a pedir, y con una tecnología de desarrollo como Rails.
Loogic.com
habla de nosotros con una reseña sobre FACTURAgem.