Nos alegra mucho poder anunciar que uno de los proyectos más interesantes en los que hemos trabajado sale en beta pública. Worodu es un producto web para confeccionar, estudiar y compartir listas de vocabulario (o de cualquier otro tema). Además de realizar software y diseño también participamos como socios en esta joint venture.

Desde la beta privada que lanzamos el año pasado hemos añadido funcionalidades básicas para el producto como son compartir listas, perfiles de usuario y listas de temas genéricos, amén de solucionar muchos bugs y mejorar la usabilidad gracias a las aportaciones  de nuestro primer y selecto conjunto de usuarios.

Worodu está desarrollado con nuestro stack de herramientas favoritas: Ruby On Rails, jQuery, HAML, Less y RSpec, y para hosting y sistemas contamos con los servicios de Iukanet. Aun queda mucho que mejorar así que no nos detendremos en esta beta pública, pero esperemos que os sea útil la próxima vez que tengais que estudiar!

Hoy queremos hablar de uno de los proyectos más interesantes en los que hemos trabajado durante los últimos meses: Cadena de Cambios.

Cadena de Cambios es la iniciativa de tres emprendedores valencianos para construir un negocio 2.0 con el objetivo de facilitar el trueque de objetos o servicios entre personas.

Partiendo de un algoritmo basado en grafos desarrollado por el equipo emprendedor, desde Nectio hemos ayudado a desarrollar un MVP (Minimum Viable Product o Minimo Producto Viable) que permita a los usuarios de Cadena de Cambios registrarse desde facebook, dar de alta objetos y servicios, realizar búsquedas geolocalizadas y obtener y gestionar “cadenas de cambios”.  Además hemos colaborado en mejorar la experiencia de usuario a partir del diseño inicial. En el proyecto se han usado una interesante selección de tecnologías open-source, como puede ser JRuby, Sinatra, Neo4J, Ruby On Rails, Sphinx y Aspell.

Cadena de Cambios se encuentra actualmente en fase de beta privada y desde aquí deseamos lo mejor para este proyecto.

Renovamos nuestra web con un nuevo enfoque, que en realidad no es nuevo sino es el que ha ido tomando por sí solo el negocio desde hace ya tiempo.

Como podréis ver por el tipo de proyectos que hemos ido acometiendo, nos hemos especializado en convertir en realidad proyectos de emprendedores que tienen una idea para un negocio en Internet, aportando tanto diseño gráfico y de interacción como software back-end y front-end.

Convergiendo hacia este modelo de servicios full-stack, para acompañar al emprendedor en toda su andadura hemos decidido también ofrecer asesoría financiera y de empresa. De este modo no sólo nos encargamos de convertir la idea de negocio en un producto real sino que también apoyamos en tareas de planificación estratégica, búsqueda de financiación e inversores, contabilidad, etc.

Dentro de muy poco comenzaremos a hablar de los proyectos que tenemos entre manos ahora mismo y algunos otros que estamos a punto de comenzar, de momento gracias por visitarnos!

Llevo ya tiempo queriendo dedicar un post a hablar un poco sobre el patrón de diseño de Inyección de Dependencias y de cómo podemos beneficiarnos de él, en este caso con uno de los frameworks de desarrollo web con el que estoy trabajando últimamente: ASP.NET MVC.

Según la wikipedia: “Inyección de Dependencias (en inglés Dependency Injection, DI) es un patrón de diseño orientado a objetos, en el que se suministran objetos a una clase en lugar de ser la propia clase quien cree el objeto”. Es decir, típicamente tendremos reunidos en una clase ciertos métodos que nos son útiles en varios sitios de nuestra aplicación (por ejemplo un sistema de Logging, o de acceso a base de datos) que para aclararnos vamos a llamar clase servicio.

Pero con los mecanismos que nos ofrece cualquier lenguaje orientado a objetos, si queremos usar esta clase nos tocará instanciar un objeto de esta clase servicio dentro de otra clase para usarla. Esto tiene un efecto no muy deseable, y es que estamos haciendo totalmente dependientes nuestras clases de la clase servicio. Si en vez de la clase servicio que usaba hasta ahora para el sistema de logging quiero usar otra, en todas las clases que accedan a ella tendré que cambiar el tipo que se instancia y volver a compilarlas (en caso de que no estemos usando un lenguaje interpretado).

¿No podríamos mejorar esto haciendo que los componentes de nuestra aplicación no sean tan dependientes entre ellos?. La solución es el patrón de Inyección de dependencias. La idea es que en los componentes de nuestra aplicación simplemente especifiquen los servicios que necesitamos y por detrás haya un framework que provea estos servicios. En el mundo Java la opción clásica para este framework sería Spring, y para .NET/Mono nosotros vamos a usar otra opción también open source que es Castle Windsor.

Vamos a ver un pequeño ejemplo de cómo podriamos configurar un servicio que consumirán nuestros controladores. Vamos a usar una forma bastante sencilla de hacer esto, aunque Castle nos ofrece otras muchas. En el Global.asax de nuestra aplicación ASP.NET MVC normalmente tendremos lo siguiente:

protected void Application_Start() {
    AreaRegistration.RegisterAllAreas();
    RegisterRoutes(RouteTable.Routes);
}

Nosotros vamos a añadir un método BuildContainer en el que simplemente inicializaremos el contenedor de Castle Windsor y le añadiremos un componente que podrán recibir las clases de nuestra aplicación en el constructor. Además debemos añadir una variable estática y privada que contenga el contenedor de nuestra aplicación:

private static IWindsorContainer Container;
 
protected void Application_Start() {
    BuildContainer();
    AreaRegistration.RegisterAllAreas();
    RegisterRoutes(RouteTable.Routes);
}
 
private void BuildContainer() {
    Container = new WindsorContainer();
    Container.RegisterControllers(typeof(HomeController).Assembly);
    ControllerBuilder.Current.SetControllerFactory(new WindsorControllerFactory(Container));
    Container.Kernel.AddComponent(
        "MvcApplication.Services.MyService", 
        typeof(IService), typeof(MyService), 
        LifestyleType.Transient);
}

Además de usar Castle Windsor, hemos hecho uso de la libreria open source MvcContrib.Castle, que extiende Windsor para proporcionarnos algunos métodos utiles para registrar nuestros controladores en el contenedor e indicar a Castle que consumirán servicios (son las llamadas que vemos a Container.RegistrerControllers y WindsorControllerFactory). Por último hemos registrado un componente indicando la clase a la que corresponde y el interfaz que implementa.

Ahora simplemente incluiremos el servicio en el constructor de nuestro controlador, Windsor se encargará de inyectar esa dependencia y ya lo podremos usar tranquilamente desde nuestras acciones:

public class HomeController : Controller {
        private IService _myService;
 
        public HomeController(IService myService) {
            _myService = myService;
        }
 
        public ActionResult Index() {
            _myService.DoSomething(); 
            return View();
        } 
}

La ventaja de trabajar con interfaces es que cuando queramos podemos cambiar MyService por otra clase que implemente este interfaz, sin afectar al código de las clases que consumen dicho servicio. Además, típicamente configuraremos los componentes del contenedor mediante un fichero de configuración xml y no por código como hemos hecho en este ejemplo, con lo que nuestra aplicación será todavia más flexible.