Diego's profileZonaDiegumPhotosBlogListsMore  |  Tools Help |
|
July 29 [Serie] Enterprise 2.0: Parte 4- Siempre "Casi Listo"Continuando con esta saga que inicié meses atrás sobre la Web reescribible y cómo las organizaciones pueden sacar tajada de ella, en esta entrega te voy a contar cómo son los ciclos de desarrollo de software dentro de este paradigma tecnológico. Lo que vamos a ver te va a sorprender no tanto por la perspectiva de quienes desarrollan el software para la Web 2.0/Enterprise 2.0 sino por la de quienes lo consumen Empecemos por revisar un caso real: una traductora me comentaba el otro día que uno de los softwares más usados entre sus colegas, está por dejar de ser una aplicación que se distribuye en CD y se instala. A partir de ahora los traductores van a empezar a pagar un derecho de uso (similar a la licencia que pagaban cuando compraban el CD) pero no van a tener que instalar nada. En cambio, van a poder entrar a un portal web y someter el documento a traducir (normalmente un .doc, un .pdf, un XML, etc) en forma completamente on line. El beneficio de este cambio se puede medir en al menos tres aspectos
Esta profesional me comentaba que las aplicaciones de traducción suelen trabajar con lo que se llama "memoria de traducción", que sirven para evitar traducciones literales de localismos como puede ser en Argentina "estar en el horno" (expresión usada para significar que se está en problemas), o en Chile "al tiro" (por "inmediatamente"). Estas expresiones, traducidas literalmente entre idiomas, no producen cosas con demasiado sentido por lo que los traductores deben elegir una expresión más adecuada. Bueno, las memorias de traducción ayudan a poner esto en práctica porque pasan a ser "diccionarios" de expresiones poco convencionales que van a ser de gran ayuda para evitar la intervención manual del traductor humano Acá viene lo interesante de esta historia: en la versión desktop, stand alone de la aplicación, la memoria de traducción la iba llenando uno a medida que iba encontrando traducciones literales incorrectas, por lo que cada nuevo usuario tenían su memoria vacía. Por ende el arranque era lento (y ni que contarte si ya habías logrado una memoria lo suficientemente madura y robusta y una vuelta se te corrompe el archivo donde se persiste: no, no creo que los traductores acostumbren a tomar backup frecuente -no lo hacemos nosotros que se supone que somos los que recomendamos hacer siempre eso, no vamos a esperar que lo hagan ellos-) Señoras y Señores... Cambió todo Andá a competirle a un servicio tan liviano y a la vez tan incrementalmente poderoso. De vuelta el efecto red: cada nuevo traductor que usa este servicio, a la par que se beneficia él porque no van a tener que pagar el costo de crear su memoria, beneficia al resto porque retroalimenta la memoria de traducción compartida
Software as a Service (SaaS). Es el mecanismo de distribución del software que te conté que usaban estos traductores del ejemplo más arriba: no se instala nada. Todo está hosteado en el proveedor (quizás, en un host que el proveedor a su vez paga por) El word y el excel de Google, al que recientemente le añadió su powerpoint es un clarísimo ejemplo de SaaS, por el que más de uno supuso "esto va a hacer puré a Microsoft". Las realidades están a la vista (y conste que no dije "a la Windows Vista"
La industria informática está viviendo en estos días un momento de disrupción similar al que se vivió cuando IBM inventó la PC. Estoy haciendo ficción con esto que voy a decir pero al empleado de IBM que inventó la PC, si aún sigue laburando ahí, le deben dar todos los meses el galardón al " Microsoft estos últimos años se ha venido adecuando a las nuevas demandas tecnológicas para no ceder liderazgo -para no perder más liderazgo También lo está haciendo en el terreno de Web 2.0, como te voy a contar más adelante En lo q SaaS respecta, a mediados del año 2006 lanzamos (hablo en primera persona del plural porque fui parte del equipo que trabajó en eso) un portal de guías para arquitectos de aplicaciones distribuidas como un servicio. Los que van capitaneando la vanguardia son Gianpaolo Carraro, Eugenio Pace y Frederick Chong, quienes han ido lanzando una serie de artículos abordando las problemáticas -ahora las voy a comentar- de este tipo de aplicaciones y las distintas formas de encararlas. Pero también han liberado en Febrero pasa el LitwareHR, una aplicación SaaS de referencia que pone las guías en práctica (orgullosamente para nosotros sudacas, el LitwareHR se logró gracias al esfuerzo conjunto con una empresa sudamericana) No obstante, desarrollar aplicaciones SaaS no es para cualquiera. Las problemáticas de SaaS son duales: para el lado consumidor de SaaS tendremos que preocuparnos de algunas, y respecto del lado servidor de SaaS tendremos que ocuparnos de otras totalmente diferentes. Por ejemplo, si el consumidor de una aplicación SaaS estaba abocado a montar su Arquitectura Orientada a Servicios (Service-Oriented Architecture o SOA) y ya había invertido unas buenas lucrecias en eso... qué rol le cabe a la aplicación SaaS en medio de esa orquesta? Cómo se maneja el login, de manera que el usuario no tenga que logonearse en varias aplicaciones? Qué pasa con sus datos que el consumidor ingresó, y que quedan hosteados en el proveedor, si discontinúa el servicio? (por ejemplo, en el caso del traductor en línea, toda la contribución que un usuario hizo a la memoria compartida... la pierde!? Uff, si es así estábamos mejor cuando estábamos mal y teníamos que instalar el software stand alone) Pero para el proveedor de la aplicación SaaS la cosa no viene más fácil: cómo lograr una aplicación que sea configurable en forma múltiple por varios inquilinos (tenants), conservando la forma en que cada uno deseó hacerlo? Hablemos un cachito de Escalabilidad (Scalability): qué hacemos, metemos a todos los tenants en el mismo servidor o mejor ponemos un servidor para cada uno para que no se peléen? La modalidad "uno para cada uno" es cara y desaprovecha recursos, pero es más fácil de lograr. Lo que pasa es que si un servidor se cae, ese tenant fue. En cambio si la arquitectura de la aplicación SaaS prevé una granja de servidores, se cae un servidor y el resto de la granja se hace cargo de levantar al muerto hasta que el servidor esté up and running de nuevo (los principios detrás de esto son anteriores a SaaS y tienen que ver con tolerancia a fallos -fault tolerance-, degradación suave -graceful degradation- y failover -la capacidad de reconocer que el servidor que venía ejecutando una tarea no está disponible y por ende reasignarle el resto del trabajo a otros-; esto último se puede hacer en forma proactiva mediante los llamados balanceadores de carga -load balancers-, que se paran en la entrada de la granja (farm) para recibir todos los requerimientos y se lo pasan al servidor que esté menos ocupado)
Desarrollo Ágil (Agile Development). Te comentaba recién de la ventaja de SaaS, del punto de vista del consumidor, de no tener que instalar el software en su propia infraestructura. Para el proveedor de SaaS esto también es un beneficio, porque se libera así de tener que estar distribuyendo diversas versiones a sus distintos clientes y comprarse así, para mañana, la obligación de dar soporte a versiones dispares. Porque creéme que no es tan fácil obligar al cliente a migrar siempre a la última versión: hay quienes migran a lo pavote pero son los menos; la mayoría es más conservadora porque no quiere ser la rata del laboratorio. Por ende, es cuestión de tiempo, vas a tener clientes en versiones distintas -casi tantas como las que fuiste liberando- y vas a estar condenado a dar soporte a todas. Los clientes se van a migrar luego de negociaciones muy duras y lo peor es que, si bien vos preparás tu aplicación para migrar fácil de la versión n a la n+1, tus clientes van a estar en la versión m<n. Creéme que migrar de m a n+1 ya no será tan sencillo y quizás tengas que intervenir manualmente convirtiendo datos y archivos de configuración
Ante todo debo decir que el Desarrollo Ágil no es una consecuencia de Enterprise 2.0. Esta forma de desarrollar software privilegiando la frecuente integración de los componentes que los desarrolladores iban terminando en una forma iterativa e incremental, usando al usuario como un miembro fundamental del equipo de desarrollo (un aliado, por así decir, alguien que no sólo provée dirección sino que se compromete a probar, frecuentemente, las versiones que se van liberado al mismo ritmo) ha estado dando vueltas de un largo tiempo antes de empezar siquiera a hablar de Web 2.0 Uno de los beneficios sustanciales del Desarrollo Ágil es que, si algo debe cambiar (sea porque el usuario se dio cuenta mejor de lo que quería una vez que vio algo más o menos andando, sea porque el negocio demanda un golpe de timón y a poner foco en otra cosa) el feedback permanente del usuario lo va a poner en conocimiento de los desarrolladores en forma inmediata. Justamente en la piedra basal que los gurúes del Desarrollo Ágil, pusieron al firmar el Manifiesto Ágil incluyeron como principio "los cambios de requerimientos son bienvenidos, incluso con el desarrollo bastante avanzado" (aunque, la verdad? Le quisiera ver la cara a Kent Beck, a Ward Cunnigham y a Ken Schwaber -tres ilustres firmantes del Manifiesto- si veinte días antes del final del proyecto el usuario les dice "estuve pensando... todos estos últimos tiempos... y la verdad que llegué a la conclusión de que lo que necesitamos es otra cosa... me gustaría tirar todo y empezar de nuevo" Como sea, hace unos meses estrenamos en el portal de Arquitectura MSDN, una sección para Desarrollo Ágil, con el padrinazgo de Peter Provost (gurú del Desarrollo Ágil en Patterns and Practices) donde vas a conocer un poco más del asunto. Porque Desarrollo Ágil no es una metodología en sí sino una filosofía de trabajo. Pero después hacés doble click y te aparecen varias metodologías concretas (entre las que descollan especialmente eXtreme Programming -XP- y SCRUM) que ponen en práctica -cada una a su modo, ojo- los principios del Desarrollo Ágil Así y todo, no es un lecho de rosas. Sólo por mencionar una de las contras del Desarrollo Ágil a tener en cuenta es que, aunque el usuario al principio va a estar muy pilas y colaborador, al cabo de un tiempo se va a ir agotando porque él no puede descuidar su día a día -y, después de todo, tu aplicación distribuida en forma paulatina no le resuelve TODOS sus problemas; ese switching de contexto cansa y se va a notar). Es muy probable que, llegado el momento, el usuario te diga "loco, yo no pertenezco al equipo de Desarrollo" (en otras palabras, lo que te estaría diciendo es "metete tu filosofía ágil sabés dónde, no?) Otro de los inconvenientes -no digo que sea una contra del Desarrollo Ágil- sino tan sólo una circunstancia que lo afecta, es que implica un cambio cultural en las políticas de la organización de dimensiones copernicanas. A los gerentes que toman decisiones de negocio le gustan las cosas claras, no te van a bancar que les digas "yo te voy a ir tirando muestritas gratis, esto de a poco va a ir saliendo, con el correr del tiempo lo vamos a ir terminando". Es factible que te paren en seco y te digan "vos me traés una carta GANTT donde vea todo el timeline del proyecto, cuándo sale el módulo de Pagos, cuándo empezamos a probar el de Morosos, cuando se termina la carga incial de datos, etc, y entonces yo te libero la guita para el proyecto. Si no, haceme el favor, tomatelá de acá que ya bastantes problemas tengo". No es imposible hacerle cambiar la forma de pensar a este tipo de gerentes, pero si lo lográs, mejor que todo después te salga bien porque si inicialmente no se ven esos resultados parciales que se prometían... En fin, suerte macho Seguramente la cosa pase por aplicar un proceso ágil sin que los de la gerencia lo perciban
El Imperio Contraataca. Microsoft no es ajeno a toda esta movida que sin duda alguna le obligó a replantear el modelo de negocio que venía liderando y que ahora corre el riesgo de perder (ocurra o no, es claro que ya nada es como fue). Microsoft viene impulsando desde años, frente a la dicotomía Desktop o Web Browser, una tercera alternativa conocida como Smart Client (por "Cliente Inteligente"). El Smart Client es una aplicación de escritorio más liviana que las stand alone, ya que no contiene toda la lógica de negocio sino que consume servicios disponibles en la nube (Internet). Preferentemente se basa en el framework .NET, y para eso toda la energía del gigante de Redmond -en lo que respecta a herramientas de desarrollo y guías de arquitectura- ha cerrado filas detrás de esa estrategia Visual Studio es el entorno que permite agilizar el desarrollo de éste y otros tipos de aplicaciones (años luz por adelante de tratar de hacerlo con el Notepad, ni se te ocurra). Las guías las aporta el comité de Patterns and Practices, que desde hace años vienen escribiendo unos libros de arquitectura desde distintas perspectivas (seguridad, acceso a datos, distribución de la lógica en capas, etc). Ultimamente están proveyendo unos aceleradores del desarrollo conocidos como Software Factories, que son unas extensiones a Visual Studio que, si desarrollar software fuera cortar árboles, es como pasar de un hacha a una motosierra (perdón por la comparación poco feliz en tiempos en que deberíamos todos reflexionar por los desastres venidos y por venir como consecuencia del ataque a la naturaleza que por acción u omisión hemos venido llevando a cabo) Hay algo innegable en mantener una parte local de la aplicación (en la expresión "Software + Services" sería el Software, en tanto que Services hace referencia a lo que está disponible más allá de la nube) que es el aprovechamiento de los recursos locales (memoria, discos, pero sobre todo la CPU) que siempre han tendido a abaratarse y por ende no hay un gran dilema con eso de "es mejor no instalar nada y ejecutar todo remoto" Por ejemplo, si la aplicación de traducción se instala localmente y se nutre de una memoria compartida (a la que, a la vez, contribuye a alimentar) distintas modalidades comerciales pueden estar disponibles. Por mencionar una, si se corta el contrato entre el traductor y la empresa que ofrece el servicio, al menos el aporte del traductor a la memoria queda almacenado localmente, de modo que pueda importarse a otra aplicación de traducción similar que el traductor contrate en un futuro Yo personalmente no compro mucho eso de que es por necesidad de abaratar el costo de las compus (mediante poca memoria, CPU barata, disco con poca capacidad) porque en la práctica el abaratamiento del hardware siempre llegó solo en cada ciclo en que por el mismo dinero se podía ahora comprar una PC con -a veces- cuatro veces más capacidad de disco que lo que se podía comprar por esa plata el año anterior, el doble de memoria, dos CPUs en lugar de una, tarjeta wireless incorporada, aceleradora gráfica incorporada, etc. Quiero decir, el baseline de los equipos es cada vez más sofisticado por precios similares, entonces de dónde la necesidad de hostear todo afuera (si hasta incluso las supercomputadoras -conocidas como Clusters, Computadores de Alto Rendimiento o HPC, High Performance Computing- hace 15 años atrás eran tan caras que sólo los gobiernos y las empresas de más alto revenue los podían tener; hoy en cambio estos equipos son más potentes que nunca y los más básicos están al alcance de una PyME) Admito que hay otras motivaciones para ir todo a Servicios que me estoy pasando por alto: la libertad de dejar todos los datos de uno en la web hace que nos podamos desplazar de un equipo a otro y que todo siga estando ahí. Qué modelo se va a imponer en el futuro dependerá de cómo cada uno de estos factores conmovió al consumidor Microsoft puso en práctica "Software + Services" mediante Windows Live, un conjunto de aplicaciones individuales que pueden o no tener lado cliente. Definitivamente Microsoft no ataca a estas tendencias sino que claramente las acompaña (el asunto es si las podrá liderar con la claridad con que lideró la evolución de la industria hasta el momento)
Okay, suficiente por hoy. En la próxima entrega vamos a ver cómo la Enterprise 2.0 revolucionó la forma de exponer y vender productos a escala global. Hasta entonces!
Esta serie se compone de July 15 Llegando a Newhalem (un Finde en North Cascades)Es verano acá en el norte y hay que vivirlo a pleno. Las fotos que te muestro acá son del finde que nos pasamos en el Parque Nacional de las Cascadas del Norte (estado de Washington). Queda a poco más de dos horas de casa En la foto, el río Skagit corre a mis espaldas, casi llegando a Newhalem, el pueblo contiguo al parque
El álbum de fotos completo lo vas a encontrar acá: North Cascades 2007 (click) July 14 [Serie] Enterprise 2.0: Parte 3- Que No se Retove el UsuarioYa al hacer la crítica sobre el libro de Dave Platt "Por Qué el Software Apesta", comentaba que las aplicaciones que no ofrecen una buena interfaz de usuario, corren el riesgo de no ser ni siquiera olvidadas sino algo peor que eso: pueden ser ignoradas por los clientes. Al respecto hay una frase muy popular de Douglas Martin (la dijo en 1989 y mirá lo vigente que es!)
Claro: con la formación computina que todos tenemos, salida de la facu en edad adolescente (precisamente en la edad del pavo) y aterrizada en la edad adulta en los primeros años de experiencia laboral, cuando se nos empiezan a otorgar las primeras grandes responsabilidades, decime en qué momento aprendemos de cómo hacer buenos diseños de interacciones para usuarios! Yo tengo una regla del pulgar para no hacer malos diseños de interfaz ni de experiencia de usuario: llamá a un diseñador en serio. No me estoy haciendo el chistoso, que quede claro. Hay veintiun mil aspectos (arquitectura de la información, usabilidad, familiaridad de las interfaces, navegación, ...) para los cuales podremos tener cierta idoneidad pero no tenemos formación. En ese sentido, al menos yo, no quiero bastardear los pergaminos de alguien que sí de veras se formó para garantizarle al usuario una buena experiencia En cambio sí puedo hacer mi aporte contando el estado del arte en tecnologías para la composición de buenas fachadas de aplicación que faciliten la puesta en práctica de diseños hechos por un profesional en el tema. Allá por Septiembre del 2005 había posteado sobre la dicotomía cliente delgado / cliente grueso y cómo en cada caso había algo que ganar y algo que perder. Y comentaba que con el tiempo, ambas partes de la discusión habían ido tomando del otro aquellas cosas que hacían a la diferencia, de modo tal que el usuario no acuse tanto recibo de la decisión tomada en lo que al tipo de lado cliente respecta La cosa no se va a resolver a todo o nada, sino que cuando convenga se usará el navegador como cliente, cuando convenga se usará alguna aplicación de escritorio. La distancia entre ambos es cada vez menor en cuanto a capacidades, tecnologías usadas, etc. La diferencia fundamental cada vez más pasa por si se quiere distribuir fisicamente al cliente (de manera de aprovechar recursos locales) o si se usa como un servicio, vía la web, accediendo a datos igualmente distribuidos y por ende manteniendo una bajísima dependencia de la estación cliente Las tecnologías que permiten hoy lograr Aplicaciones Internet Enriquecidas (Rich Internet Applications o RIA) son:
No Pensé Que Se Trataba de Cieguitos
Esta serie se compone de July 09 Bellevue 5KMHacía mil que no corría (miento: diez mil que no corría) y el otro día Marcelo (un amigo originario de Brasil) me dijo que se habían anotado para correr en la categoría de 5km de la tradicional competencia Bellevue Seafair (que en realidad es una media maratón y una maratón)
La verdad es que no me disgustó cómo corrí (discreto: 25 minutos 36 segundos), haciendo más de un año que no competía. Un detalle que debo precisar es que como nabos que somos arrancamos un minuto dos segundos tarde... porque nos fuimos a la largada de la media maratón y hasta que llegamos a la largada correcta ya estaban descolgando el cartelito!! A ver si retorno a las lides (ya voy dudándolo). De ahí, eso sí, nos fuimos a un brunch en Kirkland (sacrificada la vida, ché) Gracias, Celine, por la pic July 08 Tofler(El siguiente manuscrito fue encontrado en un baño de una Universidad. El titular de este blog deslinda toda responsabilidad de su contenido Resién bengo de dar el tofler, un esámen para entrar a la unibersidal yanki. Consiste en una serie de pregunta de matesmática qe prosedo a publicar acá en emisión espesial para que el que qiera rendir el tofler ya conosca cómo biene la mano (e sotro serbisio gratis a la comunidás) La primera pregunta también era de matemástica (antes había puesto matesmática pero creo qe la h estaba en el lugar incorrecto) y planteaba calcular el resultado de la sigiente ecuasión:
Qisás sea difísil pa lo gringol pero no para mí porqe el dó aparese dó bese (balga la rendundansia) así qe se puede tachar qedando
Si todas las cuentas ban a ser así me ban a tener que dar el diploma unibersitario nada más de rendir el tofler! El ejersisio que le segía resaba de la sigiente manera
I acá el truqito era el mismo q en el anterior, sólo qe en lugar de despejar el dó se despejaba la n (claro, ai gente qe si le cambiá una letra por un número é como qe los largés solos en Parqe Chás y les digás "llamame al selu cuando sálga"
La cosa es qe el desarroyo segía porque al salir la n que multiplicaba a si, queda si multiplicando a x, i eso asta el más inorante sabe qe da sei (a, porqe ademá é de inglés, é) En el terser desafío la tónica canbiaba: ya no era ni de tachar número ni letra. Desía "espandir la sigiente espresión"
Lójico: a un burro le tirás eso y palmó aí, porqe si abía logrado resolber lo dó primero seguro qe ba a qeré sacá todo tachando palito (alguno son tan bestia qe una bes qe aprenden ha cer una cosa no les pidá nada distinto porqe los matás, los). El punto es qe esto secsámene se asen por conputasión, entonse cuando te piden espandir lo qe en realidá qieren ber es a ber qé tan bueno só con el buord (el buord es el prosesador de teqtos). Bueno, yegó la ora de debelar el misterio: el resultado espandido da
Despué benía uno qe sí me tomó de sorpresa:
Acá sí qe no supe para dónde rajá. Entonse cobré coraje i me dispuse a aser una cosa qe en esto paíse del primer mundo és como robá un banco de lo grabe qe lo ben. Desidí copiarme de algún conpaniero. Lo qe pasaba es qe los qe tenía a la bista tenían otro tema distinto. Pero justo uno de los ejersisios era parecido, sólo que en lugar de un 5 era un 8. Entonse el buchón qe me estaba copiando ya lo tenía resolbido. Mirá qe ejersisio raro qe era qe la respuesta era un ocho aplastado
Cuestión qe me la jugé por la misma y metí un sinco aplastado yo tanbién, resultando
I el último ejersisio fue el qe más me sorprendió porqe yo me pensé qe la complejidá iba a cer cresiente pero el último me paresió el más fasilón. Claro: admitamo qe no ai jente bocho como yo qe si les mesclá cosa de número y letra se marean. Pero para mí fue regalado. Pedían "allar x en el sigiente cuadrado"
En realidá el enunsiado puso triángulo pero yo ago la fés de rata porqe si tiene dó lado no puede ser otra cosa qe un cuadrado (ya si tubiera tré é sun cubo). Cuestión qe mi respuesta a allar eqi no se iso esperá:
La semana qe biene me dan la nota, qe descuento qe ba a cer un ésito i me ba a dar el pase a la unibersidá |
-. En consecuencia, la versión web de la aplicación va a ser mejor cuanto más usada sea
). Hasta el momento el negocio central (core business) de Microsoft giraba en torno del sistema operativo Windows (desplegado en el 90% de los escritorios y aunque no tengo el número exacto, también es el más desplegado en servidores). Eso más el Office, la suite de productividad y colaboración. Pero si con .gif)
)
)
|
|
