SG #36

Noticias

lasr21 — Mon, 09 Jul 2012 16:53:18 +0000

Noticias

lasr21 Mon, 07/09/2012 - 11:53

Publicado en

SG #36

Noticias

AppCircus Villahermosa

Con la colaboracion de Dotlìpen, CITI Tabasco y BlackBerry, se llevó a cabo el pasado 26 de abril el show de aplicaciones móviles que inicia la gira 2012 de Appcircus en Latinoamérica; se registraron 22 aplicaciones en el sitio web, de las cuales 10 estuvieron en vivo en el evento, sobrepasando las expectativas de los espectadores y el jurado que presenciaron las presentaciones de las aplicaciones y el trabajo de programadores locales, y de otras zonas como Merida, Chiapas y el Distrito Federal.

MozCamp LATAM 2012

El pasado 20 de abril se celebró en Buenos Aires, Argentina el MozCamp LATAM, evento donde la comunidad iberoamericana que colabora en la fundación Mozilla estuvo presente. “El Mozcamp fue algo especial, el poder conocer a fondo los diferentes proyectos de Mozilla y entender la forma en que la fundación trabaja, me permitió entendermejor proyectos como BrowserID, y conocerel evento Kilimanjaro, iniciativa para que todos los esfuerzos de mozilla (Firefox, Marketplace,Persona y B2G) se integren en una sola experiencia”, nos comenta Luis Sánchez (@lasr21), miembro de la comunidad Mozilla México.

Fotografía de Ariel Kanterewicz

IBM Industry and Trend Forum 2012

El pasado mes de marzo se llevó acabo en la Ciudad de México, la edición 2012 del IBM Industry and Trend Forum, con el objetivo de mostrar, enlazar y ofrecer un espacio innovador para las TI y el conocimiento, con lo último en tendencias del mercado orientadas a negocios de todo tipo. Durante el Forum, tuvimos la oportunidad de charlar con Alex Kramer, Socio IBM Global Business Services, quien destacó el concepto Agile como el que define no sólo la filosofía de IBM, sino que además da la pauta para lo que nos depara el futuro en unos cuantos años.

IX Encuentro Genexus México

Durante el evento, el más importante de GeneXus en México, realizado el pasado 15 de marzo, se lanzó la versión final del nuevo GeneXus X Evolution 2. Esta plataforma de desarrollo integra el generador de aplicaciones nativas para las plataformas Google Android, Blackberry OS e IOS (iPad, iPhone, iPod Touch), un nuevo generador HTML 5, la máxima seguridad para los sistemas desarrollados, y una completa integración con la nube.

Super Happy Dev House Mexico City

¡We Are Back, We Are Open Edition!, fue el tema elegido para esta edición número 24 del SHDHMC que tuvo lugar el pasado 28 de Abril. En esta ocasión reunió a desarrolladores, diseñadores, electrónicos y artistas. Recordemos que el SHDH es un evento cuyo objetivo es que durante 12 horas los asistentes programen, diseñen, solden, dibujen , etc. es decir hackear en su mas pura expresión. Si estas interesado en asistir al próximo dev house, ingresa a: http://shdhmexicocity.org

Startup Weekend DF

Emprendedores e inversionistas se dieron cita en la Ciudad de México para asesorar y conocer las propuestas de 12 equipos mexicanos que compitieron durante en la 3ra edición de Startup Weekend DF. La visita fue parte de la gira por Latinoamérica de la iniciativa Geeks on a Plane que organiza 500 Startups. El jurado contó con personalidades como: Dave McClure de 500 Startups, Allen Taylor de Endeavor Global, David Weekly de Mexican.VC y Hernán Fernández de Angel Ventures México. El equipo ganador de esta ocasión fue Encarguitos (http://encarguitos.herokuapp.com). Más información sobre próximas ediciones en: http://startupweekenddf.com

SXSW Interactive 2012

lasr21 — Mon, 09 Jul 2012 16:51:02 +0000

SXSW Interactive 2012 lasr21 Mon, 07/09/2012 - 11:51

Publicado en

SG #36

Autor

Pedro Galván

El festival South by Southwest® (SXSW) es un evento que ofrece la convergencia única entre creadores y emprendedores de cine, música y tecnología. Esta extraña combinación de temas genera el espacio perfecto para aprender, descubrir ideas y generar sinergias y por lo tanto se ha convertido en la plataforma ideal para el lanzamiento de apps y startups.

SXSW se realiza anualmente en la ciudad de Austin, Texas la cual provee el escenario perfecto para hacer networking global en medio de una relajada atmósfera. La edición 2012 del SXSW se llevó a cabo del 9 al 18 de marzo y SG estuvo ahí para cubrir los detalles. Específicamente estuvimos en el SXSW Interactive, que son los contenidos y actividades relacionados con startups y tecnologías emergentes.

En el último par de años, nos hemos dado cuenta que el énfasis de muchos contenidos y actividades de SXSW es hacia dar a conocer y conectar con lo que está sucediendo en los ecosistemas de emprendimiento tecnológico en distintas partes del mundo. En 2011 hubo varias contenidos dedicados a América Latina, y en este 2012 notamos que esto se amplió para incluir varias conferencias y páneles con emprendedores tecnológicos de Asia y Africa.

Es muy interesante ser testigo de cómo América Latina está lentamente, pero a paso firme, insertándose en el escenario global de startups basados en tecnología. Y aunque las principales noticias del SXSW Interactive tal vez no hayan sido sobre nuestra región, es un hecho que sí tuvimos una participación significativa en todo tipo de actividades.

Presencia en las Sesiones

En los años pasados, SXSW Interactive haincluido conferencias y paneles específicamente enfocados en Latinoamérica, y através de ellos hemos visto cómo la región ha madurado. Una de las sesiones de este año fué “Accelerating Killer LatAm Startups” con la participación de Bedy Yang (Brazil Innovators), David Weekly (Mexican.VC), Rodrigo Torres Picón (Quotidian Ventures) y Carolina Rossi (Startup Chile) en representación de Vanesa Kolodziej (BA Accelerator). Algunos de los puntos más relevantes tocados en este panel fueron:

En lugar de crear “otro Silicon Valley”, la estrategia de países como México y Brasil ha sido construir puentes entre el Valle y el ecosistema dentro de cada país.
Lograr que los startups locales en países como México y Brasil tengan una visión global ha sido un gran reto, a diferencia de países como Argentina, donde los startups nacen con una visión global.
Actualmente ya existen inversionistas interesados en Latinoamérica, pero todavía son precavidos. Están esperando un gran caso de éxito que valide a la región.

Startup Bus

Startup Bus es una competencia en la que jóvenes emprendedores de todo el mundo se van juntos en camión hacia el SXSW y durante el recorrido crean startups. Digamos que es como un Startup Weekend sobre ruedas. Lo interesante es que cuando llegan a Austin, los finalistas de cada camión compiten entre sí ante un panel de jurados formados por personajes importantes de firmas de aceleración e inversión en startups.

La primera noticia importante al respecto es que este año se abrió votación para recibir emprendedores fuera de Estados Unidos, y México aplastó en la votación (confesamos que SG tuvo que ver ahí difundiendo la votación), por lo que tuvimos Startup Bus México. La siguiente noticia importante es que un equipo de México llegó a la gran final con los mejores 8 equipos de todo el mundo.

Fue el equipo Spott, quienes crearon una app móvil con la que compartes archivos en base a geolocalización. Aunque no se llevaron el primer lugar, fueron uno de los contendientes más fuertes, dejando una gran impresión en el jurado, organizadores y colegas.

Lanzamientos

Algunos startups de Latinoamérica lanzaron o activaron aplicaciones móviles durante el SXSW. Uno de estos fué “Taco’s taco”, una red social de geolocalización usada para encontrar los mejores tacos en los alrededores. También conocimos Lifedots, un startup basado en Nueva York por fundadores mexicanos, y cuya tecnología es desarrollada en México. Muchos otras personas y startups, aunque no hicieron lanzamientos formales o estuvieron en la expo, y si aprovecharon el evento y networking para estar promoviendo y pitchando ante clientes e inversionistas potenciales, casos como estos fueron PikHub y Nuflick.

Networking

En las fiestas y meetups América Latina también tuvo lo suyo. Posiblemente el más simbólico fue el meetup “LatAm is Happening”, organizado por sus servidores Software Guru y Nearshore

Link, con el apoyo de la productora mexicana The Lift. El propósito de este meetup fue incrementar y fortalecer la relación entre empresas provenientes de Latinoamérica con el objetivo de compartir lecciones y generar negocio para todos los involucrados.

Lo impresionante del SXSW

Además de recibir a una cantidad impresionante de asistentes provenientes del mundo entero —tan solo el SXSW Interactive reune a 25 mil asistentes mientras que son cerca de 60 mil en el evento completo—, es importante destacar su impresionante capacidad de networking espontáneo, desde la oportunidad de conectar con la persona al lado tuyo en la fila del café, hasta la opción de asistir a reuniones formales. Este ambiente desemboca en una increíble generación de innovadoras ideas y nuevos negocios.

Estamos orgullosos de saber que Latinoamérica ya esta aprovechando esta gran oportunidad, y mucho más de saber que podemos destacar en el competido mercado de las tecnologías emergentes. ¡Vamos con todo!

Como llegué a competir con Ivar Jacobson

lasr21 — Mon, 09 Jul 2012 16:49:59 +0000

Como llegué a competir con Ivar Jacobson lasr21 Mon, 07/09/2012 - 11:49

Publicado en

SG #36

Columna

Al principio de los 80´s cumplí 30 años, estuve por terminar el doctorado en la Universidad de Varsovia, Polonia. El tema de mi tesis fue la formalización lógica del concepto de apuntador (referencia) en los lenguajes de programación de entonces: Simula-67 y C. Por cierto, para la información de las nuevas generaciones, Simula-67 fue el primer lenguaje que introdujo el concepto de clase, objeto, herencia, métodos virtuales y co-rutinas (concurrencia); definido por tres noruegos en 1967 – Dahl, Nygaard y Myrhaug. Como ven los lenguajes orientados a objetos ya están por cumplir 45 años.

En 1983 llegué a México y me dediqué a enseñar en la maestría en Ciencias de la Computación del IIMAS los conceptos de los lenguajes orientados a objetos, empezando por Simula 67 y luego C++. Las especificaciones algebraicas de los tipos de datos, como colas, pilas, árboles y los conceptos de concurrencia, paralelismo y distribución fueron también de mis temas favoritos. Al cumplir los 40 años, en la década de los 90´s, viví el auge de los lenguajes orientados a objetos. En la revista “Soluciones Avanzadas”, precursora del Software Gurú, editada por Carlos Vizcaíno, estuvimos difundiendo el conocimiento sobre este tipo de lenguajes comparándolos con los lenguajes funcionales (como LISP) y basados en la lógica (como Prolog). Sin embargo, para mí lo más importante de la década de los 90’s fue la publicación de los diferentes libros sobre los métodos de análisis y diseño de los sistemas implementados con los lenguajes orientados a objetos (OO).

En este entonces me percaté de que los lenguajes OO no son el todo del conocimiento que necesita un desarrollador de sistemas de software para hacer buen trabajo. Faltaba algo más, las fases conceptuales del análisis (entendimiento de lo que se requiere) y del diseño (propuesta abstracta de la solución computacional) eran las que hacían falta. En esta época, Grady Booch [1], James Rumbaugh [2] e Ivar Jacobson[3] habían publicado libros importantes sobre estas fases. Los libros ofrecían las primeras prácticas basadas en la experiencia. Gracias a sus libros estos tres señores se vuelven mis ídolos.

Cuando Booch logra juntar a Jacobson y a Rumbaugh en la empresa Rational y juntos en 1995 proponen ante el Object Management Group (OMG) a UML (Unified Modeling Language) como el estándar del lenguaje de modelado OO, la aceptación y el éxito fueron inmediatos. Posteriormente, juntos escriben tres libros [4,5,6] que marcaron la historia de los procesos de desarrollo de software basados en OO (Proceso Unificado) y el modelado de las vistas abstractas de los sistemas OO (UML).

A partir de este momento, los contenidos de los cursos de la Ingeniería de Software en la UNAM, que ofrecemos con Lupita Ibargüengoitia, obligan a nuestros alumnos de la licenciatura y de la maestría a aprender y usar en los proyectos a UML y los elementos del Proceso Unificado. Llega el milenio nuevo, y al cumplir los 50 años me atrevo a desafiar, sin proponérmelo conscientemente, a Software Engineering Institute (SEI). Su modelo de SW-CMM y posteriormente CMMI fueron los referentes obligados para la industria de software. Pero yo me atrevo a pensar que los consejos que ofrece CMMI se pueden expresar de manera más sencilla.

En 2002 comienza la iniciativa de PROSOFT para fortalecer a la industria mexicana de software. Como presidenta de la AMCIS (extinta Asociación Mexicana para la Calidad en Ingeniería de Software) propongo a la Secretaría de Economía desarrollar un modelo mexicano de procesos (basado en las versiones de los modelos y estándares existentes en ese entonces: CMMI, ISO/IEC 12207 e ISO 9000). El argumento fue el siguiente: estos modelos y estándares son muy buenos, pero… nuestra industria de software está conformada en 90% (¿o más?) por las MIPYMES. Primero hay que apoyarlas para que crezcan y se consoliden y luego que busquen a los modelos para más maduros, como es CMMI. Esta fue la idea principal que llevó a la creación de MoProSoft y su conversión en el estándar nacional.

El esfuerzo posterior de probar MoProSoft en Iberoamérica, a través del proyecto COMPETISOFT (2006-2008), y su aceptación inesperada como base para el estándar ISO/IEC JTC1 SC7 Software and System Engineering (2006-2011), que culminó en la publicación del ISO/IEC Basic Profile en 2011 [7], ya es otro cuento. En México, creo que hasta la fecha pocos han entendido el valor de MoProSoft y, sobre todo, el significado para el país de elevarlo a nivel del estándar internacional. Mientras que en México se dispute si apoyar o no con financiamiento este proyecto, Brasil ya convirtió a ISO/IEC 29110 Perfil Básico en el estándar nacional y seguro lo va aprovechar pronto.

Pero no me quejo, cumplí 60 años en 2011 y el destino me abrió nuevos horizontes. Primero, mi ídolo Ivar Jacobson convocó en 2010 a la comunidad de la Ingeniería de Software a refundar esta disciplina bajo la iniciativa de SEMAT (Software Engineering Method and Theory). En su momento les hice el reporte de esta rebeldía en mi columna de SG no. 32. El año pasado participé en la fundación del SEMAT Latino América, de lo que también les conté en el no. 34 de SG.

En este mismo año 2011 la iniciativa del SEMAT se convirtió en una convocatoria del ObjectManagement Group para recibir propuestas de “A Foundation for the Agile Creation and Enactment of Software Engineering Methods (FACESEM)”.

Justamente cuando salió la convocatoria de OMG, estuve reflexionando sobre el enfoque tradicional sobre los procesos. Los modelos existentes recogen muchas buenas prácticas, sea CMMI, MoProSoft, ISO/IEC 12207, ISO/IEC 29110. Entonces ¿por qué a las empresas les cuesta tanto trabajo de adoptarlos? Por otro lado, aparecieron métodos ágiles, que prometen “el mar y las estrellas con 13 meses sin intereses”, que son una tentación muy fuerte pero incierta. Algo no está funcionando. Empecé a vislumbrar otro enfoque. En vez de “vender” a las empresas los modelos que tienen que ponerse “a chaleco”, que tal si les damos las herramientas sencillas de documentar sus prácticas diarias y que ellos mismos las modifiquen en función de lo que vayan aprendiendo de la experiencia o del conocimiento traído del exterior.

Así que decidí lanzarme a la aventura de participar en la convocatoria de OMG. Aproveché que ya tengo dos manos de obra “barata”, que son mis alumnos de doctorado: Miguel Ehécatl Morales Trujillo y Magdalena Dávila Muñoz. Mi ingenuidad, consecuencia de trabajar tantos años en la academia, no me avisó que para participar en la OMG necesito dinero. Para ser miembro de la OMG con derecho de proponer nuevos estándares y votar, hay que pagar $5,500 USD anualmente. Por eso en su momento hice un llamado de apoyo económico a este proyecto de investigación a través del infalible Software Gurú, y lo volveré a repetir en esta columna.

En el noviembre del año pasado enviamos a OMG la carta de intención de participar en la convocatoria de FACESEM. El 22 de febrero 2012 mandamos la propuesta bajo el nombre de KUALI-BEH Software Project Common Concepts. KUALI en náhuatl significa “bueno” y BEH en maya significa “camino”. Estamos proponiendo un “buen camino“ para definir las prácticas y métodos para el desarrollo de software, que las propias organizaciones capturen, adapten y mejoren en función de su experiencia y maduración. Al día siguiente nos enteramos de que somos competidores de, ni más ni menos, Ivar Jacobson.

El marzo 21, en Reston cerca de Washington, nos tocó presentar KUALI-BEH ante la comunidad de OMG. Un día antes Jacobson intentó convencernos para que nos uniéramos a su propuesta llamada ESSENCE. Le dijimos que necesitamos tiempo para pensarlo, por lo tanto el 21 de marzo nos presentamos como propuestas competidoras. La nuestra recibió buenos comentarios, que nos alentaron mucho. El día siguiente Jacobson nos pidió que le hiciéramos la propuesta de unir ambos enfoques, la cual se la enviamos a finales de marzo. Ahora la pelota está de su lado (más bien de su grupo: Fujitsu, IBM, Model Driven Solutions y otros) En agosto hay que enviar a OMG una propuesta mejorada (o fusionada con la de Jacobson) y defenderla en la reunión de septiembre en Jacksonville. Mientras tanto estamos probando KUALI-BEH con la comunidad mexicana de desarrollo de software a través de un Taller Colaborativo en Métodos de Ingeniería de Software, que se realiza en modalidad virtual y presencial.

Para continuar necesitamos recursos. Les reitero la invitación para apoyar este proyecto de investigación aplicada. Las aportaciones pueden ser en efectivo (con recibo de la UNAM deduciblede impuestos) o en especie (inscripciones, boletos de avión, hoteles, libros, equipo de cómputo). Los interesados favor de comunicarse directamente conmigo hanna.oktaba@ciencias.unam.mx. Por lo pronto quiero agradecer públicamente a los primeros patrocinadores (empresas y personas físicas): Magnabyte, Software Guru, Ultrasist, JPEConsultores, Innevo, Hugo Rojas Martínez y Evaristo Fernández Perea. A los que piensan que al cumplir 30 años se les acaba la vida les puedo asegurar que “Más sabe el diablo por viejo…”. No se pierdan el siguiente capítulo.

Referencias

[1] G. Booch, “Object Oriented Design with Applications”, The Benjamin/Cummings, 1991.

[2] J. Rumbaugh at al., “Object-Oriented Modeling and Design”, Prentice Hall, 1991.

[3] I. Jacobson at al., “Object-Oriented Software Engineering, A Use Case Driven Approach”, Addison-Wesley, 1992.

[4] G. Booch, J. Rumbaugh y I. Jacobson, “The Unified Modeling Language, User Guide”, Addison-Wesley, 1999.

[5] I. Jacobson, G. Booch y J. Rumbaugh, “The Unified Software Development Process”, Addison-Wesley, 1999.

[6], J. Rumbaugh, I. Jacobson y G. Booch, “The Unified Modeling Language, Reference Manual”, Addison-Wesley, 1999.

[7] (http://standards.iso.org/ittf/PubliclyAvailableStandards/c051153_ISO_IEC_29110-5-1-2_2011.zip )

Bio

La Dra. Hanna Oktaba es profesora de la UNAM, miembro del IPRC, y directora técnica del proyecto COMPATISOFT. hanna.oktaba@ciencias.unam.mx

Sobre Administración del cambio y otras barbaridades

lasr21 — Mon, 09 Jul 2012 16:47:35 +0000

Sobre Administración del cambio y otras barbaridades lasr21 Mon, 07/09/2012 - 11:47

Publicado en

SG #36

Mejora continua

Autor

Luis Cuellar

"El Jeet Kune Do es como un dedo apuntando a la luna, no fijes tu vista en el dedo de tal manera que pierdas toda la gloria del milagro celestial". Bruce Lee

Esta semana tuve varias conversaciones sobre cambio organizacional y cada vez me desagrada más el concepto de administración del cambio, o al menos, la interpretación que escucho. Parece ser que para asegurar un cambio organizacional tranquilo y sin incidentes mayores es necesario utilizar las estructuras pertinentes, principalmente de comunicación, para controlar el esfuerzo. Esto incluye una definición clara de la visión de futuro, establecida y comunicada claramente por un directivo importante que apadrina el cambio, seguido por la participación de expertos que crean la solución adecuada a lo que se quiere lograr (muchas veces creemos que ese es nuestro rol como expertos de calidad y productividad) la cual es transmitida a las masas con planes de comunicación los cuales definen exactamente qué y cuándo se debe de comunicar, logrando así que el cambio sea aceptado, implementado y corroborado de acuerdo a tiempos claramente establecidos. No se a ustedes, pero en mi experiencia esto suena más bien a una dictadura que a una democracia.

Cambiar una organización no sehace a través de implantar mandamientos divinos. El cambio no se administra, organizaCión no se el cambio se lidera. Aunque comunicar es muy importante, el cambio es más sobre escuchar preocupaciones, impedimentos y motivaciones, el cambio se lleva a cabo paso a paso, sin estar casado con una forma única de actuar, normalmente se ejecuta en forma no lineal y discontinua.

Para establecer un cambio organizacional, lo primero y lo más importante, creo yo, es: entender ¿por qué?

Esta es la pregunta que motiva al líder, es una pregunta que surgirá continuamente y provendrá de toda la organización, inclusive de las personas que apoyan el cambio, ¿Por qué debemos cambiar si hasta ahora nos ha ido bien? ¿Por qué ahora? ¿Por qué nosotros?, Esta pregunta requiere de una respuesta clara y contundente, esta contundencia se obtiene al establecer una relación fuerte entre el cambio y los objetivos económicos de la empresa, respuestas como: “porque así lo pide CMMi”, “porque eso dice la auditoria”, “porque el jefe dijo”, “porque así lo establece las mejores prácticas de la industria”, no te llevarán muy lejos sobre todo en cambios importantes. Adicionalmente el enfoque de la comunicación es asegurar que las respuestas a esta pregunta sean las mismas sin importar quien la responda, ya sea el líder del cambio, el dueño del cambio o cualquier persona involucrada, esta comunicación es bidireccional no es una presentación sino una conversación continua, cada persona que no tenga clara la respuesta o que no esté de acuerdo con ella representa una posible falla a los planes de cambio y este se comporta como un arrollo queriendo regresar a su cause cuando llega al borde de una presa, demasiadas fallas en la pared de la presa y la presión la desmorona. Segundo punto: escuchar, escuchar y escuchar, ¿Por qué se resisten los diferentes individuos?, ¿A qué le tienen miedo?, ¿Les preocupa la falta de conocimiento?, ¿Les preocupa que no les conviene el cambio o que complicara otras actividades de las cuales son responsables?, ¿Ven como muy difícil el nuevo comportamiento?, ¿Están surgiendo nuevos problemas no previstos por el cambio? De acuerdo a la teoría de sistemas, las organizaciones son sistemas complejos que se encuentran en balance consigo mismos, esto quiere decir que la forma en la que se comportan los individuos de una organización depende en gran medida de su medio ambiente, piensa en cómo un individuo se comporta diferente al cambiar de empresa. Para poder llevar acabo un cambio grande es necesario no solo generar, entrenar y dar seguimiento a los nuevos comportamientos, sino modificar aquellos que mantienen fijo el comportamiento anterior, escuchar te da el medio de reconocer esa relación con la forma anterior de hacer las cosas, identificar su origen y establecer una estrategia para cambiarlas.

Finalmente el cambio se hace paso a paso, esto implica que el plan es sumamente dinámico y puede cambiar en base a la retroalimentación del día con día, repentinamente aparecen nuevas tareas y desaparecen tareas que ya no son importantes, aun cuando todos los directivos de una organización apoyen una propuesta, las presiones diarias del día con día llevan a modificar la dirección y hasta a retroceder en los que se busca. Esto implica que la persona que lidera el cambio tiene que tener una visión clara y fija de en dónde se encuentra (no en dónde debería encontrarse) hacia dónde va, y cómo el siguiente paso que da lo acerca a su objetivo. No se puede estar casado con un solución en particular ni una forma de resolver el problema, las soluciones cambian y lo único importante es cómo el siguiente paso te acerca al objetivo que buscas, es de vital importancia no dejar que un paso en una dirección diferente modifique tu objetivo sino el objetivo modifique cual será ahora el siguiente paso. El perder o ganar una batalla no puede distraerte de ganar la guerra.

Todo cambia continuamente, el cambio debe de ser bienvenido, pero desafortunadamente, no siempre lo es, en la industria de sistemas continuamente vemos proyectos de gran tamaño que se ven frustrados al tratar de implementar grandes cambios en organizaciones que no están listas para hacerlo, por más administrado que estos sean. El Líder debe de dirigir a una nueva forma de hacer las cosas, debe de involucrar y escuchar a todas las personas que participan y apoyarlas a lograr el objetivo, no es suficiente decirlo sin que se tenga que eliminar todas las posibilidades de no lograrlo, y como en el Jeet Kune Do, el foco no esta en cómo debe de hacerse sino en la majestuosidad que podemos obtener al lograr una nueva y mejor forma de hacer las cosas.

Bio

Luis R. Cuellar es director de calidad a nivel mundial de Softtek. Es reconocido por la ASQ como Certified Quality Manager, Certified Software Engineer y Six Sigma Black Belt. @lcuellar

Lo que viene

lasr21 — Mon, 09 Jul 2012 16:40:13 +0000

Lo que viene lasr21 Mon, 07/09/2012 - 11:40

Publicado en

SG #36

Lo que viene

RubyMotion

Construye apps para iOS en Ruby

RubyMotion permite construir aplicaciones nativas para iOS utilizando el lenguaje de programación Ruby. Está basado en MacRuby, una implementación de Ruby sobre Objective C, pero utiliza un nuevo compilador estático basado en LLVM que genera código altamente optimizado. Gracias a esto, las aplicaciones hechas con RubyMotion corren tan rápido como su equivalente en Objective C. Además, pueden acceder las APIs estándar de iOS, así que tienen acceso a las mismas capacidades que desde Objective C. RubyMotion no utiliza XCode, sino que provee herramientas de línea de comandos para soportar un workflow al estilo tradicional de Ruby, incluso usando Rake para hacer los builds.
Más información en http://rubymotion.com

Vert.x

La alternativa políglota a Node.js

El desarrollo de aplicaciones con I/O asíncrono ha tomado mucha fuerza en los últimos meses, y poco a poco se está convirtiendo en “la manera default” para construir nuevas aplicaciones server-side. La tecnología que ha abierto brecha en ese sentido y ha obtenido mayor atención es Node.js, sobre la que ya hemos publicado algunos artículos en SG. Ahora surge Vert.x, que utiliza un modelo de programación muy similar al de Node.js, pero funciona sobre la Java Virtual Machine y gracias a ello soporta un mayor espectro de lenguajes incluyendo Java, Groovy, Ruby y Javascript. Vert.x todavía es bastante nuevo, pero dada su naturaleza consideramos que ganará tracción rápidamente.
Más información en http://vertx.io

Cloud9 IDE

Un IDE pensado para la nube

En la categoría de ambientes de desarrollo integrado (IDE), uno de los productos al que le hemos estado siguiendo la pista los últimos meses y que parece que ya está despegando, es Cloud 9. Este es un IDE diseñado específicamente para el desarrollo de aplicaciones en la nube. Estas son algunas de sus características principales.

Es basado en web, es decir que se ejecuta en el navegador.
Está principalmente enfocado a programación en Javascript, NodeJS y HTML5, pero soporta otros lenguajes como Python y PHP.
Se integra de forma transparente con repositorios de código en línea como GitHub y BitBucket, entre otros.
Las aplicaciones fácilmente se despliegan a ambientes PaaS como Heroku, Joyent y Windows Azure.
Cuenta con una modalidad para editar usando comandos de vi.
Provee una línea de comando que soporta comandos Unix para el manejo de archivos, así como comandos de npm (node package manager).

Más información en http://c9.io

BigML

Machine learning al alcance de todos

Uno de los campos de nuestra profesión con mayor proyección hacia los próximos años es el denominado machine learning, al que en español se empieza a referir como “aprendizaje automático”. El aprendizaje automático es una rama de la inteligencia artificial enfocada al desarrollo de sistemas que aprenden a partir de datos empíricos y evolucionan su comportamiento de acuerdo a esto.
Hasta ahora, el grueso del trabajo hecho en este campo ha sido académico y de investigación, pero poco a poco comienzan a surgir los pioneros con una oferta comercial. Uno de ellos es BigML, quienes ofrecen un servicio de machine learning en el que tú subes fuentes de datos y en base a éstas BigML genera modelos predictivos que puedes incorporar directamente en tus aplicaciones por medio de una API tipo REST. Definitivamente este es un campo muy joven en el que iremos ir y venir muchas tecnologías y empresas en los próximos años, pero bien vale la pena ir conociendo qué están haciendo los pioneros.
Más información en http://bigml.com

La verdadera T.I. híbrida

lasr21 — Mon, 09 Jul 2012 16:38:18 +0000

La verdadera T.I. híbrida lasr21 Mon, 07/09/2012 - 11:38

Publicado en

SG #36

Tendencias en Software

Autor

Luis Daniel Soto Maldonado.

El “cómputo en la nube” se distingue de una plataforma altamente virtualizada por lo siguiente:

Todos los recursos – cómputo, almacenamiento y red – se comparten, habilitando el provisionar de forma dinámica de aplicaciones y servicios.
Autoservicio. Mediante un portal se pueden solicitar, configurar y administrar aplicaciones y recursos como servicios.
Elasticidad. Con base en los requerimientos de negocio los recursos se reducen o aumentan.
Ofrece costo basado en uso, pagando sólo por los recursos utilizados

Escenarios básicos

La “nube pública” puede ofrecer una plataforma de consolidación que permite ejecutar cargas de trabajo secundarias a un menor costo operativo y puede facilitar establecer ambientes de desarrollo y prueba para ser eventualmente desplegado a la nube o a un centro de datos tradicional.

Una “nube privada” puede ofrecer control adicional al que ofrece públicamente. Es claro que el futuro de la plataforma tecnológica es habilitar una “Tecnología de Información híbrida”:

La capacidad de trasladar máquinas virtuales en diversos hipervisores, con administración, identidad y modelo de programación en común entre nubes privadas y públicas.
Crear una campaña publicitaria en medios sociales almacenando la información en la nube pública pero manteniendo una copia en una base de datos en el interior de una empresa. La clave aquí es la existencia de una herramienta que permita hacer esto eficientemente.

Escenarios avanzados

Las posibilidades de combinar la nube privada y pública van mucho más allá de lo que a primera vista se ofrece. Exploremos algunos ejemplos:

Establecer una solución de recuperación en caso de desastres para base de datos. En este escenario, se utiliza un servidor primario físico o virtualizado dentro de la empresa y en una máquina virtual en la nube pública el secundario.
Verdadera aptitud de incrementar la capacidad de forma transparente cuando ésta se rebasa en la nube privada.
Aplicaciones que no sólo puedan ser implementadas en nubes públicas o privadas indistintamente sino en donde esto pueda ser seleccionado a nivel de sus distintos componentes. Por ejemplo utilizar indistintamente una base de datos tradicional o una ofrecida como servicio.
La capacidad de “entender” lo que está sucediendo dentro de las máquinas virtuales y cómo puede mejorarse el desempeño de los servicios que están operando internamente.

Una plataforma para TI híbrida deberá ofrecer un modelo de licenciamientos que permita reubicar licencias existentes para uso interno a una nube pública. Permitiendo realizar las ventajas de cada modelo como mejor le convengan a una empresa. Estableciendo los límites de costo y capacidad con facilidad y en muy pocos pasos.

El destino 2015

Creo que la mayor parte de las plataformas tardarán tres a cinco años en llegar a esta visión. La infraestructura será híbrida, elástica, de bajo consumo de energía, siempre disponible y auto-administrada. El tiempo de recuperación en el peor escenario, se reducirá dramáticamente de 0 a 30 minutos para casos muy graves.

Las aplicaciones se adaptarán al usuario, organización y grupos sociales. Contarán con inteligencia derivada del razonamiento de grandes volúmenes de datos y serán altamente adaptables (fáciles de extender y combinar con otras aplicaciones). Operarán eficientemente en cualquier geografía.

Tendremos que enfrentar retos existentes como la seguridad y nuevos retos, como lo es el fraude en el uso de capacidad de cómputo sin pagar por ella. Los requerimientos legales y fiscales de las distintas geografías continuarán siendo temas complejos. En el génesis de la informática, aun nos encontramos lejos del séptimo día.

Bio

Luis Daniel Soto Maldonado (@luisdans) es director of Technical Product Management for Microsoft SQL Server, Azure SQL Database & Big Data

Sinatra

lasr21 — Mon, 09 Jul 2012 16:35:20 +0000

Sinatra lasr21 Mon, 07/09/2012 - 11:35

Publicado en

SG #36

Tutorial

Autor

Salomón Rincón

Sinatra es un DSL (Domain Specific Language) para la creación rápida de aplicaciones web en Ruby con un mínimo esfuerzo. Sinatra se destaca por su simplicidad y ligereza, además de contar también con libertad de elección ya que no impone el uso de patrones ni librerías específicas.

En este tutorial veremos un ejemplo sencillo de cómo hacer una aplicación web con Sinatra tipo CRUD (create, read, update, delete). Utilizaremos Ruby 1.9.2, Datamapper como ORM y PostgreSQL como base de datos.

Modelo

Iniciamos creando un archivo llamado sinatra_test.rb. Este será el archivo que contenga la lógica de nuestra aplicación. Lo primero que vamos a incluir es el siguiente código:

require 'sinatra' require 'data_mapper' configure do DataMapper.setup(:default, 'postgres://localhost/development') DataMapper.setup(:default, { :adapter => 'postgres', :host => 'localhost', :username => 'sysdba' , :password => 's3cret', :database => 'development'}) end

Lo primero que hace el código es indicar que utilizaremos las “gemas” sinatra y data_mapper. Luego, configuramos DataMapper para conectarse a nuestra base de datos llamada ‘development’, con el username ‘sysdba’ y password ‘s3cret’.

A continuación definimos el modelo de nuestra aplicación.

class Linea include DataMapper::Resource property :cve_linea, String, :length => 4, :required => true, :key => true property :linea, String, :length => 30, :required => true end

Nuestro modelo consta tan sólo de una clase Linea, con dos propiedades: cve_linea y linea. Sinatra se encargará de crear la tabla correspondiente en la base de datos. Para pedir que Sinatra borre las tablas que existan en la base de datos (si es que existen) y cree nuevas a partir de nuestros modelos agregamos:

DataMapper.auto_migrate!

Si por el contrario, las tablas ya existen y no queremos borrarlas sino actualizarlas con la nueva definición de los modelos, usaríamos DataMapper.auto_upgrade!

Ruteo

Sinatra usa rutas (routes). Una ruta es un método HTTP (get, post, etc.) junto con un patrón que representa uno o más URLs. Cada ruta se asocia con un bloque.

Definamos la ruta para la página principal de nuestra aplicación.

get '/' do erb :index end

El código anterior indica que cuando el usuario entre al URL ‘/’ mediante el método get, queremos que se procese una vista llamada index utilizando el lenguaje de
plantillas erb. Vale la pena mencionar que Sinatra soporta diferentes lenguajes de plantillas como erb, haml y builder, entre otras.

De forma similar, al recibir una petición get en ‘/linea’ mandamos invocar la vista reg_linea.

get '/linea' do erb :reg_linea end

Ahora definimos un bloque que atiende la petición ‘/listalineas’ que, como se podrán imaginar, nos da un listado de líneas. Crearemos una variable @lineas donde pondremos todos los registros del modelo Linea (que se mapea a la tabla lineas en la BD) e invocamos la vista lista_lineas para que despliegue el listado.

get '/listalineas' do @lineas = Linea.all :order => :cve_linea erb :lista_lineas end

Para crear o actualizar una línea que tengamos almacenada, enviaremos peticiones tipo POST a ‘/linea’. El siguiente bloque se encarga de manejar estas peticiones.

post '/linea' do if !campo_vacio(params[:cve_linea]) and !campo_vacio(params[:linea]) @linea = Linea.new(:cve_linea => params[:cve_linea].upcase, :linea => params[:linea].upcase) if @linea.save redirect "/linea/#{@linea.cve_linea}" else redirect '/linea' end else redirect '/campo_vacio' end end

Lo primero que hacemos es validar que los parámetros cve_linea y linea no estén vacíos. Si la validación es exitosa creamos una nueva instancia de Linea, mapeando el valor de sus propiedades con los parámetros recibidos en la petición. Como se darán cuenta, estamos convirtiendo los valores a mayúsculas antes de asignarlos. Posteriormente intentamos guardar nuestro registro en la base de datos (save). Si tenemos éxito, redireccionamos a la ruta para consultar la línea en cuestión, y si no lo tenemos redireccionamos a la ruta ‘/linea’ (estas redirecciones se hacen con el método get).

El siguiente bloque de código atiende la ruta para mostrar el detalle de una línea específica.

get '/linea/:cve_linea' do @linea = Linea.get(params[:cve_linea]) if @linea erb :cons_linea else redirect '/linea' end end

En esta ruta lo único que hacemos es buscar el registro correspondiente a la clave de línea que recibimos como parámetro y lo guardamos en la variable @linea. Si el registro fue localizado,
llamamos a la vista cons_linea que se encarga de presentar el detalle.

Para mantener breve el tutorial, no se incluye aquí el código para definir las rutas para editar y borrar registros, pero imagino que a estas alturas ya tienen una buena idea de como sería. Al final del artículo puedes consultar como obtener el código fuente completo de esta aplicación, donde vienen todas las rutas.

Vistas

En el directorio en donde guardamos el archivo sinatra_test.rb crearemos un directorio llamado ‘views’ donde pondremos los archivos que definen las vistas de la aplicación. La primer vista que crearemos es la plantilla base en la que irán embedidas las otras vistas. El archivo de dicha vista se debe llamar layout.erb (la extensión .erb, es porque estamos utilizando el lenguaje de plantillas erb). El contenido de layout.erb es el siguiente:

<html> <head> <title>Ejemplo Sinatra</title> <meta httpequiv="ContentType" content="text/html; charset=utf8" /> </head> <body> <%= yield %> </body> </html>

Como se puede apreciar, es código HTML común y corriente, con una sola línea de código en Ruby (<%= yield %>). Cada que se manda a llamar a una vista con erb, se utiliza esta plantilla y el sistema sustituye la línea <%= yield %> por el código de la vista correspondiente.

Nuestra vista index puede ser algo tan sencillo como:

<h1>Menú Principal</h1> <p><a href="/linea">Registro de líneas</a></p> <p><a href="/listalineas">Listado de líneas</a></p>

La vista reg_linea con la forma de captura para registrar líneas sería:

<form action="/linea" method="post"> <label>Clave de línea </label> <input type="text" name="cve_linea" id="cve_linea"> <br/> <label>Línea </label> <input type="text" name="linea" id="linea"> <br/> <input type="submit" value="Guardar"/> </form>

A continuación definimos la vista cons_linea que muestra el detalle de una línea. Para ello recurrimos a la variable @linea que declaramos al definir la ruta get '/linea/:cve_linea'. Dicha variable contiene el registro correspondiente a la clave de línea que se recibió en el parámetro :cve_linea

<label>Clave: </label><%= @linea.cve_linea %><br/> <label>Línea: </label><%= @linea.linea %> <p><a href="/linea">Registrar una línea</a></p> <p><a href="/">Menú Principal</a></p>

Ahora veamos el código de la vista que muestra el listado de líneas. Recordemos que al recibir las peticiones a esta ruta generamos una variable @lineas con el contenido de todas las lineas en la base de datos.

<p>Líneas registradas: <%= @lineas.length %></p> <table> <% @lineas.each do |linea| %> <tr> <td><%= linea.cve_linea %></td><td><%= linea.linea %></td> <td><a href="/editlinea/<%= linea.cve_linea %>">[editar]</a></td> <td><a href="/borralinea/<%= linea.cve_linea %>">[borrar]</a></td> </tr> <% end %> </table> <p><a href="/">Menú Principal</a></p>

Por razones de espacio, no incluyo aquí el código del resto de las vistas, pero el código completo incluyendo las rutas y funcionalidad para editar y borrar, así como el uso de una hoja de estilos personalizable, se puede descargar en: http://salomonrt.wordpress.com/2011/09/28/instalar-sinatra-postgresql-datamapper-en-debian-squeeze/

Ejecutar la aplicación

Para ejecutar nuestra aplicación, vamos al directorio en donde tenemos el archivo sinatra_test.rb y en la línea de comando tecleamos:

ruby sinatra_test.rb

Una vez que este corriendo nuestra aplicación, podremos accederla con un navegador en la dirección: http://localhost:4567 (por default Sinatra escucha en el puerto 4567).

Bio

Salomón Rincón es Director General de Top Systems y catedrático en la Universidad Popular Autónoma del Estado de Puebla (UPAEP). srincon@topsystems.com.mx

Logra Pitches Épicos

lasr21 — Mon, 09 Jul 2012 16:29:36 +0000

Logra Pitches Épicos lasr21 Mon, 07/09/2012 - 11:29

Publicado en

SG #36

Emprendiendo

Autor

Luis López

La palabra inglesa “pitch” es una presentación verbal (y visual a veces) concisa de una idea para una película o serie de televisión, generalmente hecha por un guionista o director a un productor o ejecutivo del estudio, con la esperanza de atraer financiamiento de desarrollo para financiar la escritura de un guión.

El concepto de pitch aplica de la misma forma para ideas de negocio como para guiones de películas. El fin es el mismo: obtener la credibilidad de tu idea y conseguir financiamiento.

Estos últimos meses he estado participando en eventos como Startup Weekend donde he conocido a gente increíble. En el camino he escuchado cientos de ideas y cientos de pitches. También he tenido oportunidad de ayudar a algunos a preparar su presentación (pitch + keynote) final, y hay un par de consejos que quiero compartir con ustedes, los cuales creo que pueden ser de interés para quien tenga que presentar una idea de negocio ante un panel y les serán útiles para presentaciones que tengan una duración alrededor de los 10 minutos, no son recomendables en pitches rápidos de 1 minuto o menos.

“Hola, mi nombre es...”

Empieza tu presentación diciendo quién eres. No necesitas recitar tu curriculum, una vez escuché a alguien decir en qué kinder había estudiado, nadie necesita escuchar eso. A nadie le importa si te dieron el premio al mejor estudiante o si haces el flan napolitano más rico del mundo (a menos de que vayas a vender flanes napolitanos). Sólo presentate rápido y di qué sabes hacer. También es importante que, si tu equipo no está presente, menciones rápidamente sus nombres y qué hace cada uno de ellos. Eso va a dar cierta seguridad de que no te sacaste la idea de la manga y que tanto tu equipo como tú tienen ciertos conocimientos para hacer de esa idea un éxito.

Después di qué haces ahí parado. Recuerdo que la primer diapositiva, del keynote con el que presentaba Bandtastic decía: “Amamos la música (bueno, Fabian no tanto)”. Di que te mueve, porqué estás ahí y que es lo que te apasiona. Este punto puede ser el más cursi y romántico de tu presentación pero créeme, es muy importante.

Haz que duela… mucho

Ya que dijiste qué te mueve, ahora cuenta el problema. Hazme sentir tanto dolor que quiera gritar:“¡¿Porqué nadie ha resuelto esto?!” Da números, fotos, gráficas de por qué está hecho un reverendo caos “equis” o “ye” y explica porqué necesita una solución. Si tu idea es muy compleja, este es el momento para definir términos complejos y explicarlos.
En este punto necesitas crear empatía con los que te estén escuchando: Haz que duela,. haz preguntas y expón al enemigo. Esto es como una buena obra de teatro o película porque toda buena película tiene un enemigo, personificado o no, siempre hay un enemigo. Crea ese enemigo, haz que todos lo detesten y quieran eliminarlo.

Presenta al héroe

Y claro, como toda buena película, siempre hay un héroe. Tú eres el héroe. Tu idea revolucionaria es el héroe que viene a rescatar al mundo de ese GRAN problema que presentaste antes. Haz que tu idea sea épica, heroica, caída del cielo. Haz un slide solo con el logo de tu idea (si no tienes un logo, es un buen momento de hacerlo o pagar porque alguien te lo haga, no presentes sin un logo).

En menos de un tweet

Ya que presentaste al héroe (y su logo), es hora de mencionar sus superpoderes y cómo estos van a salvar el mundo. Describe tu solución. Al hacer esto, muchos cometen el error de decir algo como lo siguiente:
“Plataforma multifuncional encargada de gestionar los contenidos específicos de la industria restaurantera de la ciudad, basada en la nube con servicios de notificaciones Push a teléfonos inteligentes, capaz de generar inteligencia de negocio, bla bla bla…”

No lo compliques, porque es muy probable que haya gente que no entienda de tecnología o en general de lo que estás diciendo, primero piensa en cómo lo dirías en un tweet (140 caractéres para definir tu solución), después piensa en cómo reducirías ese tweet a 5 palabras. Aprende de los grandes, cuando Steve Jobs presentó la MacBook Air, pudo haber citado cada una de las características de la misma. En cambio, solo dijo: “The world’s thinnest notebook”.

Haz una diapositiva (slide) con esta frase de 5 palabras. Hazla tan impactante que cuándo pregunten de qué trató tu pitch, todos respondan usándola.

Tres es el número mágico

Ahora, explica por favor cómo funciona. Ya dijiste qué hace, ahora dime cómo lo hace. Reduce las características que quieres explicar a tres, porque es un número mágico que hace más fácil de recordar las ideas. “Nuestra app hace esto, aquello y lo otro”.

Los comediantes saben que tres es más gracioso que dos. Los escritores saben que tres es más dramático que cuatro. Tres es más persuasivo que cinco. Toda gran película, libro u obra tiene una estructura de tres actos. Había tres mosqueteros, no cinco. Ricitos de oro encontró tres osos, no cuatro. Había tres chiflados, no dos. En la declaración de independencia de EUA dice que los americanos tienen derecho a “la vida, libertad y la búsqueda de la felicidad”, no solo a la libertad.

Tres es el número mágico. Toma unos minutos y ve este video en el que Steve Jobs presenta el primer iPhone. Busca “el villano, el héroe y la regla de tres”.

Núm3r0s

Una vez explicada la idea, da una razón para que te crean. Esta puede ser la parte más aburrida del pitch, es la parte en la que hablas de los usuarios, del mercado y de cómo vas a ganar dinero. Por favor, no exageres, he escuchado mil veces: “Si obtenemos 1% del mercado de equis o ye, significa que tendremos 1,000,000 de usuarios el primer mes”. No asumas nada, si has hecho algún tipo de validación de la idea, este es el momento de mostrarla con: encuestas, usuarios actuales, ventas, etc.

En lo personal, evito las proyecciones, creo que nunca sabrás cómo se comportará el mercado, sino hasta que lanzas tu producto; pero para algunos es importante que tu presentación las incluya. Aunque en realidad no muestren lo que va a suceder, refleja de cierta forma tu visión del negocio y a lo que aspiras. Recuerda: Todo se ve bien en el “Excel”, así que no te emociones si “Excel” dice que serás millonario en 2 meses.

“Cállate y toma mi dinero...”

Ahora, ya que has explicado todo, si estas hablando con un inversionista o eres parte de algún concurso, di para qué quieres el dinero. Muchos no saben contestar esta pregunta, prepárala. No significa que tengas que detallar cada una de las cosas en las que ocuparás el dinero, solo di algo como: “Necesitamos una inversión inicial para arrancar operaciones y crear un prototipo funcional”. Este es el momento en el que muestras tu avance.

Se llevan puntos extra, los que tengan un producto o un prototipo sin haber recibido inversión, significa que no estás esperando dinero para avanzar con tu solución, pero que necesitas un empujón para llevarla al siguiente nivel.

Una gran película, tiene un gran final

Ahora estás listo para dar las gracias. En vez de cerrar con una frase como: “Eso es todo gracias”, intenta algo como: “Muchas gracias por su atención, con gusto responderé las dudas que tengan sobre......” Así, matas dos pájaros de un tiro: estás en control de la situación, diciendo que ya “pueden” preguntar y además tienes la oportunidad de encaminar las preguntas a un tema específico, pudiendo evitar preguntas incómodas sobre algún punto en el que haya flaqueado tu presentación.
Usa la última diapositiva de tu presentación para tu logo, o cualquier cosa que quieres que recuerden los que te escucharon. Si hay tiempo para preguntas y respuestas, esta diapositiva se quedará detrás de ti mientras contestas. Aprovecha y deja una imágen de lo que quieres que recuerden.

Tips técnicos

Si tienes una Mac, no uses PowerPoint. Si tienes una PC, tampoco uses PowerPoint, por favor consigue una Mac y usa Keynote.
Aún si vas a usar Keynote, no uses las plantillas predeterminadas, empieza con una en blanco o negro. Elige un color, una fuente y una sola transición para todas tus diapositivas.
Últimamente Prezi se puso de moda, si vas a usar Prezi no hagas giros y movimientos muy bruscos porque marean.
Un último consejo, usa un control remoto. Pararte junto a tu computadora o peor aún, pedirle a alguien que le cambie a los slides cada vez que dices: “siguiente” es lo peor que le puede pasar a tu pitch. Compra un control remoto o usa tu iPhone o iPod touch conectado a la misma red Wifi como remoto. Si no tienes ninguna de las anteriores, usa un mouse bluetooth, agárralo con tu mano y dale clic para cambiar a la siguiente diapositiva.

Dejo un link a mi SpeakerDeck, donde he subido algunos de los keynotes que he hecho para presentar ideas: speakerdeck.com/u/lulo

Bio

Luis López Méndez, conocido como Lulo (@lulomx), es emprendedor, y cofundador de Bandtastic y es parte activa del ecosistema de emprendimiento en México. A sus 22 años ha sido mesero, baterista, vendedor, fotógrafo, instructor y hasta mentor. Hace unos meses ganó Wayra México, dejó la escuela, y ahora intenta ayudar a que la gente viva la música que ama, y de paso, cambiar la industria.

Juegos Casuales

lasr21 — Mon, 09 Jul 2012 16:26:30 +0000

Juegos Casuales lasr21 Mon, 07/09/2012 - 11:26

Publicado en

SG #36

Juegos

El término “juegos casuales” se utiliza para describir un segmento grande y creciente de la industria de videojuegos. Los juegos casuales tienden a ser aquellos con una dinámica de juego sencilla, diseño atractivo, y una curva de aprendizaje muy corta, por lo que en cuestión de minutos los usuarios pueden aprenderlos y disfrutarlos. El objetivo de los juegos casuales es llegar a la mayor audiencia más amplia posible, especialmente los consumidores que no cumplen el perfil del “gamer” tradicional.

Por qué crear juegos casuales

El segmento de juegos casuales ha tenido un crecimiento explosivo en los últimos años y crear juegos casuales se ha convertido en una opción atractiva y redituable para muchos. Estos son algunos de los principales factores que influyen en este crecimiento.

Bajos costos de producción. Para crear juegos casuales no es necesario licenciar costosos SDKs o motores de gráficas. Ciertamente facilita las cosas contar con algunas herramientas, y en el caso de algunas plataformas (ej. iOS) pagar una cuota anual para estar en su Developer Program y poder publicar juegos en su app store, pero estos costos son realmente bajos comparado al costo de herramientas y membresías requeridos para crear juegos para consola o computadora personal. Por otro lado, tampoco es necesario contar con equipos con gran cantidad de personas. La mayoría de los juegos casuales son creados por equipos pequeños, con 5 personas o menos. Para juegos sencillos, incluso es viable que una persona pueda crearlo por sí solo.

Facilidad de distribución. Hasta hace unos cuantos años, el canal de distribución era uno de los principales limitantes para los juegos casuales. El canal más común eran portales web donde se podían usar en linea o descargar, y esto limitaba las opciones de modelo de negocio. Pero hoy en día las cosas son muy distintas, y existen dos canales principales para juegos casuales: los app stores/marketplaces incluidos en las principales plataformas y sistemas operativos, y Facebook. Gracias a ellos, los desarrolladores pueden facilmente acceder a mercados con millones de usuarios, todo mediante un simple “submit”. Ciertamente hay muchos aspectos que tomar en cuenta para maximizar la visibilidad/impacto de tu juego en un app store o en Facebook, pero eso puede llevarse otro artículo completo así que no entraré en esos detalles —aunque creo que sería buena idea publicar un artículo sobre ese tema en SG.

Potencial de ingresos. Parece apenas ayer que el segmento de juegos casuales era el patito feo de la industria de videojuegos, eclipsado por el mercado multi-billonario de los juegos para consolas. Pero en poco más de dos años (considero 2009-2010 el punto de quiebre) el mercado de juegos casuales ha tenido un crecimiento fenomenal y ha captado gran atención, posiblemente más que el mercado de consolas. Comparto aquí algunos números para darnos idea del tamaño y potencial de este mercado:

El mercado global de juegos móviles y sociales suma cerca de 15 billones de dólares en ventas anuales y está creciendo a tasas cercanas al 20%. Se espera que para el 2016 este mercado sea mayor que el de juegos de consola (y con costos menores).

La empresa de juegos sociales Zynga, reportó ingresos por 311 millones de dólares tan solo en el último trimestre del 2011 (más de 100 millones de dólares al mes). Cerca del 60% de estos ingresos proviene tan solo de 3 juegos: FarmVille, CityVille y FrontierVille.
Rovio, el estudio que creó Angry Birds, fue valuado en agosto del 2011 en 1.2 billones de dólares, y en febrero de este año recibió una oferta por parte de Zynga para ser adquirido por 2.25 billones de dólares (oferta que rechazaron).

Variedad de modelos de negocio. Otra característica atractiva de los juegos casuales es que ofrecen distintos modelos de negocio, entre ellos:

Cobro por uso. Este es el modelo tradicional, donde el usuario paga cierta cantidad de dinero para descargar y utilizar un juego. Vale la pena notar que los juegos son la categoría de apps móviles en que los usuarios tienen mayor disponibilidad a pagar por su uso (comparado con lectores de noticias por ejemplo, donde pocos usuarios están dispuestos a pagar por usarlas).
Publicidad. Poner anuncios dentro de los juegos puede generar buenos ingresos. Por
ejemplo, Angry Birds genera mensualmente ingresos por 6 millones de dólares por concepto de ventas de publicidad. Debo mencionar, que al igual que en el caso de publicidad en sitios web, este tipo de modelo de negocio solo es viable para los juegos más populares, con millones de usuarios.
Freemium. El modelo freemium consiste en ofrecer una versión gratuita de un juego para “enganchar” a los usuarios, y ofrecer otra versión de paga con capacidades adicionales (más niveles, posibilidades de personalización, etcétera).
Bienes virtuales. Otra variante del modelo freemium es que los usuarios realicen compras dentro del juego (in-app purchase) para adquirir bienes virtuales que pueden utilizar dentro de un juego para mejorar su desempeño. FarmVille es posiblemente el juego más conocido de este tipo.

Tips para crear juegos casuales exitosos

Estos son algunos tips que comparte Tom Higgins, evangelista de la empresa Unity, en su artículo “The business of casual gaming” [3]. El artículo tiene ya varios años (es pre-app store) por lo que había algunos tips que ya no aplican respecto a la distribución de juegos, pero he dejado los demás:

Mantenlo sencillo. Asegúrate de que el juego sea relativamente sencillo de aprender a jugar, pero que también sea un reto convertirse en experto. Las instrucciones necesarias deben ser mínimas, tal vez unas cuantas oraciones a lo mucho.
Hazlo intuitivo. La interfaz de usuario y controles deben ser lo más estandarizadas posibles. No impongas una curva de aprendizaje a tus usuarios porque reduces las posibilidades de que lo disfruten.
Premia a tus jugadores. Mantén a tus jugadores interesados y envueltos en la experiencia de juego. Por ejemplo, en un juego de acción puedes ofrecer una nueva arma o poder especial cada 30 segundos durante los primeros minutos, y posteriormente reduce la frecuencia de esas ofertas.
Haz que sea interesante volverlo a jugar. Diseña tu juego de tal manera que sea divertido jugarlo en repetidas ocasiones, trata de mantener a los usuarios regresando por más. Puedes hacer esto ofreciendo caminos de juego alternos y armas/configuraciones distintas.
Enfoca tus esfuerzos. Evita gastar mucho tiempo y recursos en cosas que el usuario muy probablemente ignore después de haber visto una vez. Por ejemplo, no gastes mucho tiempo en una animación para la introducción, mejor dedícalo a mejorar los aspectos centrales del juego.
Prueba pronto y seguido. Consigue que tu juego sea probado por personas desconocidas que pertenecen a tu audiencia objetivo, y hazlo a distintos intervalos durante el desarrollo de tu juego. Es de gran ayuda poder observar a estas personas jugar el juego por primera vez, sin instrucciones. No estés hablando con ellos o explicándoles durante el juego, espera a que hayan terminado.

Conclusión

Crear juegos casuales es una posibilidad con pocas barreras de entrada y buenas oportunidades de negocio. Esto ha atraido a millones de desarrolladores de todo el mundo y ha llenado los app stores de juegos, lo cual puede hacer parecer que este segmento ya esté saturado y no haya espacio para competir. Sin embargo, el potencial todavía es muy grande, y si haces bien las cosas tendrás buenas oportunidades.

Siento que los juegos casuales es un espacio donde Latinoamérica tiene mucho que aportar. Si la industria de TI en Israel aprovechó la fortaleza de su gente en matemáticas y algoritmia para convertirse en líderes en aspectos de seguridad y encripción, mientras que India aprovechó sus decenas de millones de ingenieros que hablan inglés, ¿por qué no en Latinoamérica podríamos aprovechar nuestras ocurrencias y espontaneidad para convertirnos en líderes en el espacio de juegos casuales?

Referencias

[1] “Factbox: A look at the $65 billion video games industry”. Reuters, 06/2011. http://swgu.ru/sg36r1

[2] Z. Street. “How large is the Online and Mobile Game Market?” GamesBrief, 12/2011.http://swgu.ru/sg36r2

[3] T. Higgins. “Casual Games as a Business”. http://swgu.ru/sg36r3

[4] The Rise of the Mobile Gaming Industry (Infographic). Business degree, 04/2012. http://swgu.ru/sg36r4

Bio

Pedro Galván (@pedrogk) es cofundador y director de Software Guru.

Desarrollo de Videojuegos Sociales y Móviles

lasr21 — Mon, 09 Jul 2012 16:24:23 +0000

Desarrollo de Videojuegos Sociales y Móviles lasr21 Mon, 07/09/2012 - 11:24

Publicado en

SG #36

Juegos

En los últimos años, las redes sociales han propiciado un espacio para el desarrollo de los llamados “videojuegos sociales”. Estos juegos digitales tienen la particularidad de integrar las distintas capacidades de comunicación de la red social en que son ejecutados, como la mensajería a través de chats, envío de invitaciones y uso del contenido que los propios usuarios han generado en la red.
A su vez, la masificación del uso de dispositivos móviles ha permitido incorporar nuevos elementos que expanden aún más las características de sociabilización en este tipo de aplicaciones, tales como la geolocalización, el compartir información en tiempo real usando una cámara o micrófono, así como también la capacidad de estar conectado en todo momento a través de redes inalámbricas. Todos estos elementos permiten establecer una interacción más rica y síncrona entre los usuarios participantes.

Consideraciones

La creación de un videojuego social conlleva diferentes desafíos de carácter técnico, ya que se espera que este tipo de aplicaciones permitan que muchos usuarios puedan conectarse a ellas para interactuar entre sí, debiendo soportar diferentes configuraciones de software (sistemas operativos, browsers) y hardware (PC, dispositivos móviles).
Dado esto, el diseño de un videojuego social debe considerar aspectos relevantes como:

Escalabilidad: hacer que el juego pueda funcionar correctamente cuando aumenta o disminuye la cantidad de jugadores.
Concurrencia: soportar adecuadamente que varios usuarios interactúen simultáneamente en la aplicación.
Plataforma(s) de operación: construir el juego de modo que pueda funcionar en diversas plataformas y diferentes redes sociales.
Seguridad: proteger la integridad de la plataforma y los datos de los jugadores.
Monitoreo y registro de información: verificar la salud de la plataforma del juego y generar bitácoras con información relevante sobre las acciones de los jugadores y “logs” del sistema.

Arquitectura

Para cumplir con las consideraciones mencionadas, es deseable separar los componentes del juego en diversos módulos según su tipo de responsabilidades y acciones a realizar.
A continuación se presenta un ejemplo de arquitectura para un videojuego social:

Figura 1: Ejemplo de arquitectura
A continuación explico los distintos componentes:

Game Front-end. Es la capa de presentación del juego que se ejecuta dentro del contexto de una red social. Interactúa con el usuario, es responsable de manejar los elementos multimediales (gráficos, audio), los dispositivos de entrada de datos (teclado, mouse, pantalla táctil) y se comunica con los servicios del back-end.
Social network integration. Módulo encargado de interactuar con la API de una o más redes sociales. Permite que el front-end del juego pueda acceder a los datos y funcionalides sociales que provee cada red social (listas de amigos, envío de invitaciones, etc.) y acceder a los medios de pago integrados (ej: Facebook credits).
Game services. Corresponde a la capa de servicios del juego, es usada por el Front-end para validar, persistir y recuperar la información relacionada con la cuenta de cada jugador.
Storage. Capa encargada de proveer mecanismos para guardar y recuperar la información y estado de cada uno de los usuarios que participan en el juego.
Caching system. Corresponde a una capa de caché o almacenamiento volátil de datos, la cual permite reducir los accesos más costosos al storage y acelerar la recuperación de datos del juego que no cambian frecuentemente.
Tracking service (analytics). Se refiere a una capa de seguimiento de acciones, la cual permite registrar el comportamiento de los usuarios en base a eventos disparados durante el juego tales como el envío de invitaciones, compras de ítems virtuales, etc.

Front end.

Actualmente, la mayoría de los juegos sociales usa Adobe Flash en su front-end, lo que permite que éstos sean ejecutados principalmente en PCs y navegadores web a través de un plugin. Sin embargo, la gradual adopción en los últimos años de la especificación HTML5 por parte de grandes compañías como Google, Apple y Microsoft, ha permitido que tanto computadores de escritorios como smartphones y tablets puedan hacer uso de contenido multimedia usando un browser, sin necesidad de instalar un plugin adicional.
El desarrollar aplicaciones usando HTML5 consiste en usar el lenguaje Javascript para manipular los objetos provistos por esta especificación, en particular:

Canvas. Objeto que permite renderizar figuras geométricas, y desplegar elementos gráficos basados en bitmaps (ej: imágenes PNG, JPG).
Audio. Permite ejecutar sonidos. Los formatos permitidos varían según plataforma de ejecución (ej: browser).
WebSocket. Tecnología que permite establecer comunicación bidireccional continua de datos entre un cliente y un servidor usando un socket (protocolo TCP).

Actualmente existen diferentes motores de juegos que pueden ser usados para implementar un front-end usando HTML5, tales como ImpactJS y MelonJS. Éstos proveen herramientas de apoyo (ej: editor de niveles) y permiten abstraer en parte los problemas de compatibilidad entre los diversos navegadores.
Junto a esto, existen herramientas que optimizan la ejecución de aplicaciones HTML5 en dispositivos móviles (Android, iOS), proveyendo acceso a funcionalidades nativas de cada dispositivo (cámaras, acelerómetro, etc.). Algunas de éstas son PhoneGap, TriggerIO y AppMobi XDK, las cuales ofrecen funcionalidades gratis y pagadas para generar archivos distribuibles en mercados como Apple Store y Google Play.

Back-end

La capa de servicios del juego puede ser implementada usando lenguajes del lado del servidor (Java, PHP, C#) y pueden ser expuestos a través de protocolos binarios de comunicación (ej: AMF de Adobe Systems) o basados en HTTP (REST, SOAP).
En la actualidad, destaca el uso del servidor Node.js, el cual permite desarrollar aplicaciones altamente escalables usando Javascript, empleando una arquitectura orientada a eventos. Además, cuenta con la capacidad de extender su funcionalidad base mediante módulos que se le pueden ir incorporando.
Junto a esto, para permitir escalabilidad del back-end, alta disponibilidad y una gran capacidad de almacenamiento puede hacerse uso de tecnología basada en Cloud Computing. En la modalidad PaaS (Platform as a Service) puede usarse una plataforma que ya viene predeterminada con hardware, redes, sistema operativo y servidor de aplicaciones. Tal es el caso de Microsoft Windows Azure, el cual provee un sistema operativo Windows Server el cual ofrece almacenamiento de tipo relacional (SQL Azure) y no relacional (table storage, blobs, queues).
A su vez, en la modalidad IaaS (Infrastructure as a Service) pueden realizarse modificaciones al sistema operativo, servidor de aplicaciones y otras configuraciones de infraestructura. Un ejemplo de esto es la plataforma Amazon Web Services, la cual ofrece máquinas virtuales de Linux, Windows y permite establecer el servidor de aplicaciones a usar (ej: Tomcat, Jetty).
A nivel de persistencia, los grandes volúmenes a manipular por una aplicación social pueden ser controlados usando mecanismos de almacenamiento distribuido y no relacional, tales como MongoDB (base de datos de tipo NoSQL) y Table Storage de Windows Azure. A su vez, existen soluciones complementarias como Memcached, la cual permite agregar una capa de caché distribuida que almacena y recupera objetos serializados en memoria RAM, disminuyendo así el acceso a los repositorios persistentes cuyo acceso es generalmente más lento y caro.
Con respecto a la capa de integración a redes sociales, cada una de estas redes provee un conjunto de APIs en distintos lenguajes para poder interactuar desde aplicaciones hechas por terceros. Facebook provee una SDK oficial para programar en Javascript, PHP y dispositivos móviles (iOS y Android). Junto a esto, redes sociales como Orkut y Hi5 utilizan la API de la especificación OpenSocial para acceder a sus datos y funcionalidades mediante Javascript.
Finalmente, la capa de análisis de datos puede implementarse usando el servicio Google Analytics, el cual permite definir una serie de métricas y categorías que se van nutriendo de información a través de llamadas HTTP enviadas desde el front-end o back-end. En caso que se desee una solución más específica para capturar eventos de redes sociales existe el servicio ofrecido por Kontagent, el cual permite registrar invitaciones, publicaciones y datos demográficos entre otros.

Conclusión

En este artículo hemos echado un vistazo de alto nivel a las distintas consideraciones y aspectos técnicos que hay que tener en cuenta al construir un juego social. Espero que te sea de ayuda en la construcción de tu próximo juego.

Bio

Milko Madariaga es Ingeniero en Computación y Magíster en Ciencias de la Universidad de Chile. Actualmente se desempeña como CTO de Syrenaica Inc., empresa chilena desarrolladora de videojuegos sociales y móviles. mmadaria@syrenaica.com