viernes, 5 de agosto de 2016

Proyectos MDM: errores y razonamientos (y II)

13:45 by Zalakain · 0 comentarios

Continúo tras un paréntesis con el siguiente post sobre Master Data Management (MDM) y en concreto sobre los errores más
Como ya comenté en mi primer artículo sobre este tema, me he basado en un artículo de "Hub Designs" al respecto. Sobre este, hago mi visión particular del tema, donde divido los errores en errores comunes a todo Proyecto TIC y errores específicos de proyectos MDM/PIM. Toca en esta segunda parte hablar de

Errores específicos de Proyectos MDM/PIM

Si consideramos debidamente cualquier proyecto MDM habremos realizado un análisis que como mínimo nos indicará:
  • objetivo: qué es lo que queremos lograr con el proyecto; descrito en "lenguaje comprensible por todos" y con el nivel de detalle que sea preciso 
  • cómo medir el resultado: qué indicadores mirar, cómo obtenerlos y qué valores son los deseados así como los aceptables (que no tienen por qué ser necesariamente los mismos)
Esto de nuevo es común a cualquier proyecto TIC. El "añadido" que nos podemos encontrar en muchos proyectos MDM/PIM es que el propio proyecto en sí sea interdependiente de otros proyectos "paralelos" y a los cuales se dé más o menos importancia: creación de una plataforma de eCommerce, creación de una nueva Web, creación de un nuevo catálogo digital...  Si este es el caso habrá que prestar una atención adicional a los puntos de "integración/interconexión" entre proyectos y esto en ocasiones es muy complejo (por motivos como políticas de empresa/departamentos; recelos entre integradores; complejidad excesiva de alguno de los proyectos...). En estos casos podemos (¿debemos?) aplicar una metodología LEAN y lograr que la integración funcione (por cierto, qué difícil resulta encontrar en Internet referencias de LEAN que no tengan que ver con las Startup...  vale, de acuerdo que a las Startup también les aplica, y mucho, esta metodología pero ¡también a muchos otros procesos y proyectos! Simplificar, Aligerar, MVP... eso debería ser parte de las tareas de cualquier proyecto que quiera tener éxito). Si no es así, entraremos en la "typical spanish" fase de echar la culpa al otro...

Bueno, centrémonos de nuevo en lo que nos ha traído hasta aquí, los Errores específicos de Proyectos MDM/PIM que nos quedaban por comentar del post anterior. "Al lío"...

No crear un Grupo de Data Governance

Esto es un error en el que es muy fácil caer, después de todo ¿a quién le apetece que le digan que tiene más trabajo que hacer? Y no obstante es muy importante evitar este error. Porque en caso contrario más pronto que tarde nos encontraremos en una situación donde determinar cuál es el origen de los datos válido o con precedencia sobre los demás quedará en las manos de un Desarrollador que estará presionado y limitado en el tiempo para decidir y que puede o no tomar la decisión adecuada (pero que en ningún caso debe ser responsabilizado por ello). Y darse cuenta de que hay un error grave en la calidad de los datos una vez hayamos terminado el Proyecto y puesto el mismo en producción es un gran fallo, uno además con un coste elevado para solucionar (pensar sólo en el tiempo que va a llevar conseguir determinar dónde está el error...). Esto es algo que se puede solucionar si establecemos desde el principio un grupo de Data Governance, con unos participantes con conocimientos no sólo de la plataforma y del negocio, si no también de a dónde queremos que se dirija este negocio (visión de futuro) ya que podrán aportar valor que si no será necesario incorporar más adelante (y no queremos andar haciendo un proyecto MDM tras otro, ¿verdad?).
Pienso hablar más adelante sobre qué es un Grupo de Data Governance por lo que no me extenderé más por ahora en este punto. Sólo comentar dos características que debe tener:
  • Ser capaz de tomar decisiones: las reuniones de este Grupo deben ser las necesarias, de la duración precisa (y no más), y concluyentes: si se requiere una decisión, se toma y se acepta. No se trata de hacer reuniones por hacer, eternas o que no valgan para nada. Todos tenemos cosas mejores que hacer que participar en grupos inútiles.
  • Ser accesible/convocable por los PMs de todos los proyectos relacionados con los datos del MDM: si hay una "ceremonia" que dificulta a los PMs el pedir algo a este Grupo, al final no se convocará y las decisiones que se tomen en los Proyectos podrán no ser las más acertadas. Por tanto estamos poniendo en peligro el/los proyectos y colaborando a dinamitar el valor de este Grupo. 

Implantar un MDM en modo "big bang"

Este fallo por suerte parece que cada vez se da con menos frecuencia, pero aún así hay proyectos donde a pesar de carecer de todo conocimiento previo sobre qué es un MDM, para qué sirve, cómo usarlo mejor, etc. se decide que la implementación sea un "big bang", un cambio radical y completo de toda la gestión previa de los datos en una empresa.
Esto desde luego que generará ruido, y también con mucha probabilidad hará "explotar" todo... en el mal sentido.
Demasiadas veces nos encontramos con numerosas dificultades en los proyectos que desaconsejan esta aproximación. La principal de ellas es la diferencia lingüística (que no de idioma, que esa puede ser otra...) entre Negocio y Desarrollo/Sistemas. Lo que un departamento entiende por "dato maestro" puede no tener nada que ver con lo que entiende otro. Y esto muchas veces se deja en manos de Consultores que tienen una enorme carga de trabajo y un tiempo muy limitado para desarrollarlo, por lo que para cuando se detecta que esto es un problema y se pretende corregir ya es demasiado tarde: un modelo de datos malo y no adecuado a la tarea que se precisa; un diseño de la solución que no se beneficia de las ventajas que la plataforma MDM aporta; una complejidad excesiva en todos los casos para acomodar situaciones "y si", etc. En definitiva, una solución pobre y mal implementada, que como poco causará animadversión a los usuarios.
La solución a este problema en realidad son dos posibilidades:
  • pasar muchísimo tiempo en la fase de Análisis del Proyecto si contamos con un equipo de Consultoría experimentado y capaz (en caso contrario, es mejor no intentar este camino), con la esperanza de que se llegue al nivel de entendimiento perfecto entre las partes y se diseñe y realice una buena solución MDM ("safe & sound").
  • o ser realista y aproximarnos al desarrollo de la solución de una manera cíclica, que permita aprender según se va avanzando y lograr el mejor valor posible de la solución en cada momento del ciclo de vida del proyecto. ¿A alguien le suena esto a Metodologías Ágiles? Exactamente, esa es la idea. Una aproximación tipo SCRUM o incluso Kanban al proyecto puede lograr que el resultado final sea mucho más satisfactorio que hacer un "big bang". 

Considerar sólo una dimensión


Por último, aquí entramos en la parte más "analítica" del proyecto MDM, en la que nos debemos plantear qué datos tenemos, cuáles queremos gestionar, cómo son (qué información contienen), cómo interactúan entre ellos, y cómo queremos acceder a los mismos. Por supuesto que todo esto desde dos puntos de vista: cómo lo hacemos actualmente y cómo querríamos hacerlo.
Y aquí es donde entran las distintas "dimensiones" de las que hablamos. Es decir, si nos planteamos un proyecto MDM sólo desde un único punto de vista (por ejemplo, manufacturing) tendremos el problema de que aunque la solución satisfaga éste no podremos fácilmente satisfacer otros que añadamos posteriormente (p.e. marketing; o web; o mobile...) si no los hemos pensado antes e incorporado sus requerimientos al diseño de la solución MDM. Esto en sí es un proceso complejo y creo que justifica por sí sólo la existencia de una fase de "Análisis MDM" en el proyecto, que se ocupe de trabajar con todas las dimensiones que haga falta, con la suficiente importancia y alcance como para garantizar unas mínimas capacidades "multidimensionales" a la solución desarrollada.
En caso de no hacerlo, tendremos el problema de que lo que se haya implementado, por bien que se haya hecho (y seguramente caro), no va a ser la solución que sirva para otras necesidades de la empresa. Y esto hay que evitarlo a toda costa, se trata de implementar proyectos MDM sólidos, duraderos y estables (al fín y al cabo, en muchos casos van a ocupar el lugar de los antiguos OS/360, que aunque "feos" pueden perfectamente definirse con esas palabras).

Y hasta aquí mis comentarios sobre estos errores en proyectos MDM. Espero haber aportado algo al respecto, y desde luego estaré encantado de cualquier opinión sobre el tema.

viernes, 24 de junio de 2016

Proyectos MDM: errores y razonamientos (I)

14:13 by Zalakain · 0 comentarios

Comienzo con este post a escribir sobre el tipo de sistemas con los que trabajo actualmente, los sistemas MDM (Master Data Management).

Recientemente leí un artículo que trataba sobre las "8 peores prácticas en Master Data Management y cómo evitarlas" escrito por "Hub Designs". Me parece un tema interesante y quería aportar mi propia visión sobre el tema, ya que por desgracia después de tantos años los Proyectos Informáticos siguen tropezando en las mismas piedras...

La visión que daba el artículo, si lo traducimos al castellano y lo simplificamos es esta:


En general estoy de acuerdo con los errores que se detallan, pero he realizado una pequeña modificación: los círculos en naranja representan errores comunes a todo proyecto TIC mientras que los azules tratan de errores específicos de proyectos MDM/PIM.

Veamos más en detalle cada uno...

Errores comunes en proyectos TIC (IT)

La gestión de los proyectos TIC, y casi de cualquier proyecto, es una tarea muy compleja como bien saben mis amigos del Asociación Navarra de Gestión por Proyectos. La toma de requerimientos, la gestión de los recursos, los plazos... son tareas que pueden resultar enormemente complejas y requerir mucho esfuerzo, y que si no se llevan a cabo correctamente darán al traste con el proyecto.
Lo que sí conocemos y de lo que voy a hablar aquí, son una serie de errores que si no los corregimos pronto harán que nuestro proyecto fracase sin importar el esfuerzo que dediquemos al resto de tareas. (Aclaro que entiendo por "fracaso" el hecho de que un proyecto no se reconozca como éxito o beneficioso, a pesar de que se haya entregado por completo, en tiempo y en costes; vamos, que si no nos reconocen el resultado ¿para qué hemos trabajado?)

Olvidarse del caso de negocio

O, dicho de otra manera ¿para qué estábamos haciendo esto? Aunque parezca mentira, a veces los proyectos desarrollan soluciones que no son lo que se necesitaba o no solucionan completamente el problema que se pretendía solucionar. Sobre esto, las Metodologías Ágiles como SCRUM ayudan enormemente a no cometer este error ya que siempre se mantiene el foco en lo que el cliente quiere solucionar en todo momento. De este modo el resultado es lo que el cliente espera (y por tanto supondremos que es lo que le soluciona sus problemas :) ). Otra técnica, más simple y que no implica necesariamente cambiar el proceso de desarrollo que tengamos implantado, es la metodología Lean y sobre todo el concepto de Producto Mínimo Viable un concepto que debería ser obligatorio en todo desarrollo software y que comprendí mucho mejor de la mano de expertos como Mario López de Ávila o Rodrigo Corral: (simplificando el concepto muchísimo) desarrolla la solución necesaria mínima, e itera sobre esta.
En cualquier caso, hay que tener siempre presente lo que buscamos solucionar y asegurarnos de hacerlo, sin florituras. El resto, para más adelante.

Sin Sponsor ejecutivo

Esto es un problema que demasiadas veces se obvia en los proyectos, y luego causa enormes dificultades: ¿quién es la persona (o personas) dentro del cliente que apoya este proyecto y tiene capacidad para hacerlo? Si no la hay sinceramente sería mejor no realizar el proyecto. Porque cuando haga falta buscar aprobaciones, información, respuestas, apoyos, formalizaciones, firmas... si no existe esta figura vamos a tener que perder mucho tiempo (y dependiendo del cliente puede ser mucho-mucho...) y esfuerzo para conseguir algo que debería ser muy simple.
Esto, que puede parecer trivial, nos va a causar dos problemas mayores:
  • Si somos estrictos en nuestros requerimientos, va a causar retrasos y más retrasos en el proyecto (que potencialmente podrán encima ser achacados a la tarea del PM...)
  • Y como PMs tenemos muchas otras tareas en las que dedicar nuestro esfuerzo y nuestro tiempo. Soportar estos temas es más que probable que nos cause una percepción negativa del proyecto.
Por tanto, aunque parece algo trivial este error nos puede causar unos problemas muy graves. Así que lo trivial debería ser determinar esa figura.

Tecnología errónea

Esto sí que está claro, sin duda :) El elegir una tecnología errónea para una solución nos va a dar muchísimos dolores de cabeza. En ocasiones no es fácil o posible conocer de antemano qué es lo que nos interesa más, por lo que se hace preciso realizar un buen análisis de las soluciones existentes para conocer cómo solucionarían el problema concreto.
Además, también es muy conveniente tener en mente una visión amplia de hacia dónde queremos que evolucione en el futuro nuestra solución o plataforma, de tal manera que no nos quedemos "atados" a sistemas legacy o con muy poco recorrido a futuro.
Aquí me permito hacer una pequeña "cuña publicitaria": STEP de Stibo es la mejor solución de MDM del mercado, para ambos puntos ;) 

No planificar el cambio organizativo y cultural

Esta es una parte que los programadores "de siempre" hace años pensábamos: "ya se adaptará el usuario y si no que aprenda". Y aprendimos a las duras que eso no es así, y que encontrarnos con un grupo de usuarios finales que hecha pestes del proyecto no es bueno, y trae problemas...
Así que hay que preocuparse de esto debidamente, planificarlo, desarrollarlo, etc. como un subproyecto del proyecto, con su propio PM si es preciso, recursos, tiempos, etc... 
El asegurarnos de que el usuario final entiende y conoce cómo utilizar nuestro desarrollo es una parte esencial si luego queremos lograr ese reconocimiento del resultado. En esto un proyecto es como cualquier otro negocio: si entregas algo mal y sin instrucciones claras lo más posible es que no te valoren "5 estrellas"...

Sin métricas para evaluar el resultado

Este es el último de los problemas "genéricos" de cualquier proyecto, el que podemos traducir como "ni sabemos dónde estamos ni dónde queremos llegar". Y es que en muchas ocasiones (demasiadas) los proyectos nacen de una "idea feliz" o impresión sobre que algo es necesario, pero no se sabe muy bien ni por qué ni para qué. Sólo unas métricas adecuadas (y nunca "impresiones") pueden aclarar esto debidamente. Y siempre es posible determinarlas. Todo software proporciona valores o datos que son medibles. Toda actividad de una persona puede representarse de acuerdo a algún parámetro que se puede medir. Por tanto, por complicado que parezca esto, es posible. Y muchas veces nos encontramos con que los proyectos no se miden de ninguna manera más que por el tiempo y el coste de los mismos. ¿Y qué hay del resultado?
Por eso las métricas son necesarias, para conocer y documentar lo qué se ha hecho y por qué se ha hecho. Y en consecuencia que se reconozca el éxito del proyecto.


Hasta aquí esta entrada, en la próxima me centraré en los errores más "puros MDM". Espero haber aportado un poco sobre este tema, y por supuesto que cualquier comentario, crítica u opinión es más que bienvenida. Entre todos mejoramos :)

miércoles, 4 de noviembre de 2015

More Hybrid Apps please!

9:43 by Zalakain · 0 comentarios

Finally after a couple months' work, I've finished my new Hybrid App for Android, "San Fermin Quiz"(perhaps to be published for WindowsPhone and iOS, though the "tax" Apple charges discourages me to publish a free App). As with my previous development, "CPE Tráfico", I used Apache Cordova (the open source version of Adobe Phonegap) for development. This is the third  hybrid App that I publish, and I consider it new because it is a complete re-make of the previous version of "San Fermin Quiz", though that one too used Cordova/Phonegap plus jQuery Mobile for the front-end. In this case, however, I wanted to work with Ionic Framework (instead of Onsen-UI that was my framework for "CPE Tráfico"). Both are modern presentation frameworks that use AngularJS, Google's MVW framework which I've fallen completely "in love with" after these projects. And if there is just one thing both have taught me is to run away from jQuery like the plague! :D I also learned some more details that I want to talk a bit about on this post, in case it can be of somebody's use.

So, let's start saying that IMHO it keeps gettings clearer that Hybrid Apps are the future of Apps. "Clear as water". "Wasting time" nowadays (sorry if anyone thinks I'm wrong) developing with Swift, Java or any other "mono" platform is, at least, unproductive. Cordova / Phonegap offers everything it requires to develop quality applications on any platform, and only requires JavaScript knowledge. On top of that we can add that developing with JavaScript + AngularJS grows one's toolbelt future-proof (as they have become the "de-facto standard" for any development: web server, web client, IoT, ...), so the benefit is multiplied. It is true that there are some cases that may require the development of a truly "native" App: for example, one that must interact with "intents" not covered by Cordova / Phonegap or done for a very specific device; or those in which tight control of code is a must (such as POS Apps). But what could be the percentage of such cases? 5%?... Therefore, it is very difficult to justify the extra effort to develop "native".

Regarding the use of Ionic compared Onsen-UI, I have mixed opinions. On the one hand, I liked Onsen-UI initially. Its elegance "out of the box" together with some very good examples of code that could be used straigth away in any App(read "copy & paste") to make its skeleton, were some things I quickly appreciated. When I used this framework to develop "CPE Tráfico" I felt comfortable from the start: I liked what I saw, it integrated with Cordova / Phonegap faultless, it helped me understand the basics of AngularJS... Overall I had few problems. But one thing that I found "difficult": Onsen-UI is a development of the Japanese company Monaca, and the information available on the web about this platform is scarce: the truth test is to look for the term "onsen-ui" in Stackoverflow.com which returns 1,213 hits, while searching for "ionic" returns 10,970... True, Monaca is trying to solve this with new products (Cloud Monaca, Monaca Debugger, Monaca LocalKit ...) and adding more members to its team to train and support users (for example Fran Dios @frandiox). And also if you know how to look around and search for information, everything is solved :)
But when I've used Ionic... that's activity! Among the entries in Stackoverflow, their blog and products (Ionic Lab, Ionic Market, ...) and some of the authors who are writing articles about it (Raymond Camden, Christophe Coenraets, Ashteya Biharisingh, Simon Reimler ... and many more) it is not uncommon to find information and direct solutions to any problem. Truth is there is no comparison in on this point (well, at least for now). Another difference is the way to develop a project. Ionic installs on your development machine a handy CLI which allows immediately running the development App in your own local web server, whilst monitors the code and automatically updates itself when code is changed. You can also compile the app (although I prefer to do this on my own with Phonegap Build) and deploy it on an emulator or on a physical device connected to the machine. A very good way to accelerate development times and simplify testing (Monaca has created something similar for Onsen-UI, Monaca LocalKit, but I could not test it). And something more "invisible" but ultimately helpful: Ionic CLI creates a structure of files and folders to start our project in an organized manner. With Onsen-UI this is done manually thus there can be differences between projects that can negatively impact development ("Where is the library I created for ..."). This is in Ionic side becomes clearer (though one can screw things up if wants to, of course). Something I don't like about Ionic? Well, his OOTB visual style is ugly, very weak compared with Onsen-UI where everything is more visually pleasing (plus Onsen-UI lets you use Font-Awesome icons besides Ionicons for your project, though this can also be achieved in Ionic with some effort). But apparently this is part of the business strategy of Ionic, as they have recently launched Ionic Market where you can buy themes, plugins and packages for your Ionic starter applications. Luckily I found Ionic Material which is a free and simple way to implement Material Design on my Apps.

Ultimately both are very good frameworks, but Ionic today is much more accessible. Will this be like VHS and Beta? Who knows, maybe. I could not make a more thorough comparison that would be more appropriate to opt for one or the other (hey, I am a "one-man-shop" Apps developer using my spare-time!:) ): functionality, performance (this would be especially important to know about, so if anyone has information about this: please share!), supported platforms and versions, tests on real devices, update frequency, error resolution, future planning...

Maybe / certainly the next projects I have in mind will help me learn more: an app for Market Research, another app for Camera fans... Hybrid rules!

martes, 3 de noviembre de 2015

Más Hybrid Apps!

12:02 by Zalakain · 0 comentarios

Por fin tras un par de meses de trabajo, he terminado mi nueva App híbrida para Android, San Fermín Quiz (quizá la publique en WindowsPhone y iOS, aunque el "sablazo" de Apple me molesta mucho pagarlo para una App free). Como en el caso de mi desarrollo anterior, CPE Tráfico, he usado Apache Cordova (la versión open source de Adobe Phonegap) para su desarrollo. Se trata de la tercera App híbrida que publico, y la considero nueva ya que es un completo re-make de la versión anterior de San Fermín Quiz, que aunque también estaba basada en Cordova/Phonegap empleaba jQuery Mobile para el front-end. En este caso sin embargo quería trabajar con Ionic Framework (en vez de Onsen-UI que fue mi elección para CPE Tráfico). En ambos casos se trata de frameworks de presentación modernos que hacen uso de AngularJS, el framework MVW de Google del cual me he enamorado completamente tras estos proyectos. Y si algo me han enseñado ambos es a ¡huir de jQuery como de la peste! :D También he aprendido algunos detalles más que quiero comentar un poco en este post, por si es útil.

En primer lugar destacar que cada vez tengo más claro que (en mi opinión) las Apps Híbridas son el futuro de las Apps. Claro como el agua. Hoy en día "perder el tiempo" (perdón si alguien piensa que me equivoco) desarrollando con Swift, Java o cualquier otra plataforma "monocolor" es, como poco, improductivo. Cordova/Phonegap ofrece todo lo que se necesita para desarrollar aplicaciones de calidad y multiplataforma, y sólo requiere conocer JavaScript. Si a eso añadimos que al desarrollar con JavaScript+AngularJS estamos haciendo crecer nuestro abanico de herramientas de futuro (ya que es un "estándar" practicamente para cualquier desarrollo actual: web server, web client, IoT,...) el beneficio se multiplica.
Es cierto que sí hay algunos casos en los que pueda requerirse un desarrollo de App "nativas": por ejemplo las que deben interactuar con "intents" no cubiertas por Cordova/Phonegap o muy específicas de dispositivo; o aquellas en las que se quiera tener un control férreo del código (como TPVs o algunas Apps de empresa). Pero si pensamos que estos casos representarán como un ¿5%? del total de proyectos de Apps, resulta muy complicado justificar el esfuerzo extra de desarrollar "nativo".

Respecto al uso de Ionic comparado con Onsen-UI, tengo opiniones encontradas. Por un lado, Onsen-UI me gustó mucho inicialmente. Su elegancia "out of the box" unido a unos ejemplos de código en su página muy utilizables (léase "copy & paste") para hacer un esqueleto de App en poco tiempo fueron de agradecer. Cuando utilicé este framework para desarrollar CPE Tráfico me resultó cómodo desde el principio: me gustaba lo que veía, se integraba con Cordova/Phonegap sin fallos, me ayudaba a entender lo básico de AngularJS,... En general tuve pocos problemas. Pero una cosa sí que me resultó algo difícil... Onsen-UI es el desarrollo de la empresa japonesa Monaca, y la información disponible en la web sobre esta plataforma es escasa: la prueba del algodón es buscar el término "onsen-ui" en Stackoverflow.com que devuelve 1.213 resultados, mientras que buscar "ionic" devuelve 10.970... Es cierto que Monaca está intentando solucionar esto, con nuevos productos (Monaca Cloud, Monaca Debugger, Monaca LocalKit...) y añadiendo más miembros a su equipo para divulgar y dar soporte a los usuarios (por ejemplo Fran Dios @frandiox), y que sabiendo buscar y programar un poco todo se soluciona :)
Pero cuando he usado Ionic... ¡menuda actividad! Entre las entradas en Stackoverflow, su blog y productos (Ionic Lab, Ionic Market,... ) y algunos de los autores que tienen escribiendo artículos para ellos (Raymond Camden, Cristophe Coenraets, Ashteya Biharisingh, Simon Reimler... y muchos más) lo raro es no encontrar información y soluciones a cualquier problema. La verdad es que en esto no hay comparación (por ahora). Otras cosas distintas son la manera de desarrollar el proyecto. Ionic instala en la máquina de desarrollo un CLI muy útil, con el que ejecutar de manera inmediata en tu propio servidor web local la aplicación que estemos desarrollando, y que además monitoriza el código y se actualiza automáticamente cuando hay cambios. También puede compilar la App (aunque yo esto lo prefiero hacer por mi cuenta con Phonegap Build) y desplegarla en un emulador o en un dispositivo conectado a la máquina. Una manera muy buena de agilizar nuestros tiempos de desarrollo y simplificar las pruebas. (Monaca tiene algo parecido para Onsen-UI, Monaca LocalKit, pero no he podido probarlo). Y algo más "invisible" pero que a la larga ayuda: Ionic crea una estructura de archivos y carpetas para comenzar nuestros desarrollos de manera organizada. Esto con Onsen-UI se realiza de manera "manual" con lo que podemos tener más diferencias entre un proyecto y otro que pueden complicar el desarrollo ("¿dónde está aquella librería que creé para...?") mientras que en Ionic la cosa está más clara. ¿Algo que no me guste de Ionic? Bueno, su estilo visual ootb es malo, muy flojo comparado con Onsen-UI donde todo resulta más agradable visualmente ( y Onsen-UI permite usar iconos de Font-Awesome también, además de los de Ionicons, aunque esto también se puede conseguir en Ionic con algo de esfuerzo). Pero según parece esto es parte de la estrategia comercial de Ionic, ya que recientemente han lanzado Ionic Market donde se pueden comprar temas, plugins y paquetes starter para nuestras aplicaciones Ionic. Por suerte yo encontré Ionic Material que es una manera gratis y simple de implementar Material Design.

En definitiva cosas buenas en ambos frameworks, pero puestos a elegir Ionic tiene a día de hoy mucha más información accesible. ¿Será esto como VHS y Beta? Quién sabe, puede que sí. No he podido hacer una comparativa más exhaustiva "al uso" que sería lo adecuado para poder decantarse por una u otra: funcionalidades, rendimientos (esto sobre todo sería importante conocer, si alguien tiene información al respecto por favor que la comparta), plataformas soportadas y versiones, tests en dispositivos reales, frecuencia de actualización y de resolución de errores, plan de futuro... Al fin y al cabo, soy un "one-man-shop" desarrollando Apps en part-time!

Quizá/seguro que con los siguientes proyectos que tengo en mente aprenda mucho más: algo para Estudio de Mercado que en el Marketing se invierte mucho, algo para los aficionados a las Cámaras,... Hybrid rules!

martes, 7 de abril de 2015

Review of "Rapid Flask", by Gareth Dwyer from Packt Publishing

10:31 by Zalakain · 0 comentarios

After having tried Python's most well-known framework (yep, that's Django), I wanted to try and see the difference between that and one of the tiniest and newest contenders in town, Flask. So, to know about it I watched "Rapid Flask" (http://bit.ly/1yBhseM) video from Packt which is a very good introduction to this framework. About 42 mins of video showing the use of Flask to develop a simple yet fully usable "Weather web site", that shows how simple it is to create a Web app in Python with it. Some of the Flask features covered are Jinja templates usage (the "AngularJS-like" HTML template that Flask provides), use of cookies for session-based access, and GET and POST routing. Some pointers too are given about database support, user session management and security. Personally I would have liked to have some samples about these features, to be able to implement a more complete/complex web app with Flask, something more like what can be done with Django. But this is a "Rapid" video training, which helps getting to learn Flask, so the pros outweigh the cons. 

All in all, a set of videos in clear english that can be watched in a single afternoon whilst learning how to start with Flask nicely. 4 out of 5 for me.

lunes, 18 de noviembre de 2013

Review of "CSS Fonts", by Eric A. Meyer from O'Reilly Media

0:09 by Zalakain · 0 comentarios

It's been a while since my last review, having changed jobs recently I've had to move away from front-end development and back to the "dark-side" of O.S., DBs and backend applications. However, a book like "CSS Fonts" is a very easy and short read.

If you are ever considering the use of CSS Fonts in any project (web, mobile...) this little one of 58 pages is a must. You will find no black magic here, but a great primer on how and where to add some CSS code and "hey presto!" have a much nicer looking web page. All using standards, everything from Font families, faces, weight, styles, etc. It even covers font matching, a rather unfrequent technique used to guarantee the most similar UI font experience on any user agent.
The book is full of little code bits that serve as good base for your own CSS stuff. I missed a more complete example, kind of a "walk through" sample showing what can be achieved with the use of CSS fonts (well, one can always revert to Google for that I guess). This makes this book more a quick-guide style than anything else.
Not much more to say, it's a short one you can read in a relaxed afternoon and since the book is all-standard, you will sure make use of some of it's contents sooner rather than later.

domingo, 21 de abril de 2013

100, 150... y contando!

23:45 by Zalakain · 0 comentarios

Cuando publiqué la App que mencionaba en mi anterior post (y que algunos habéis tenido la amabilidad de descargar y probar ¡muchas gracias!), pensé que sería interesante hacer otra entrada en mi blog cuando llegara a las 100 descargas activas (bueno, si llegaba...) comentando la experiencia que supone. No pretendo con ello decir que conozco la "fórmula del éxito" con esto ni mucho menos, sólo quiero anotar lo aprendido con la experiencia y si a alguien le sirve de algo, fenomenal!

Antes de seguir adelante, me voy a permitir "hinchar un poco el pecho" porque a día de hoy las estadísticas hasta ayer (Google siempre te da las estadísticas "a día de ayer") dicen que hay 158 instalaciones activas de la App, sobre un total de 214 instalaciones. Si bien toda estadística puede leerse de dos maneras, y la mala me dice que tengo un 25% de usuarios que no han encontrado lo suficientemente interesante la aplicación como para mantenerla en sus dispositivos, creo que me quedaré con la buena, la que me dice que 157 personas además de mí tienen la aplicación instalada. Para ser una App tan específica y creada con una herramienta tan básica como AppInventor, ¡creo que no está nada mal!

Y ahora que ya me he permitido meter mi cuñita, empiezo con lo aprendido:
  • Lo primero de todo es que se empieza "fuerte", no sólo en el ánimo, sino también en las descargas. En cuanto al ánimo me refiero a lo contento que se queda uno cuando empieza a ver que la gente se descarga tu aplicación, los primeros comentarios, las primeras valoraciones... La verdad es que da cierto "gustito" ver que realmente algo que has hecho como una especie de hobby, a ratos, para probar... resulta ser útil para algunas personas y que encima probablemente son más de las que te esperabas. Lo cierto es que eso es Internet: mucho más de lo que parece y un canal de comunicación enorme y disponible para todos. Esto te da mucha idea de hasta dónde realmente se puede llegar con esfuerzo (con esto quiero decir que ya hay un montón de ideas más en esta cabeza...).
  • La "fuerza en las descargas" es algo que ya está estudiado por mucha gente, y a fondo: el modelo típico empieza con una gráfica ascendente más o menos empinada, que dura no mucho tiempo, y a partir de ahí se llega a una "zona plana" donde se estabiliza la cosa: bien un poco hacia arriba si la App es buena y merece la pena "vivir", bien un poco hacia abajo si los usuarios poco a poco la van desinstalando con lo cual acabará "muriendo". En el caso concreto de "Código Penal Artículo 384" todavía parece que no he alcanzado ese plano, sigue teniendo una cierta tendencia incremental, pero muy suave (es decir, lentamente). Esto es algo que ya me esperaba, por tanto aunque los resultados eran buenos lo importante es que realmente cumplían mis expectativas. Ya dije en mi anterior post que esta App no es ninguna revolución, pero eso no quita para que me fijara un objetivo realizable de descargas (100), que es el que me interesaba ver cómo se cumplía. Con esto quiero decir que aunque siempre haya "hechos esperables" (cosas que pasarán sí o sí, tal y como muchos eruditos han estudiado y demostrado) lo importante es aprender sobre cómo suceden, si hay o no desviaciones, por qué se dan, si son corregibles/mejorables/deseables, etc. Como digo para mí todo este proceso de publicar una App es un proyecto de aprendizaje, por lo que ya sólo por esto estoy muy contento.
  • Al hilo de todo esto, hay que decir que la promoción bien hecha de la App siempre ayuda. Personalmente no he realizado una promoción activa de la App más allá de este blog y los enlaces que se generaron automáticamente en Twitter y Facebook cuando publiqué la entrada anterior (¿he dicho ya que no creo que sea una "killer-App"? :) ), pero me consta que el amigo que me pidió que la desarrollara sí que se ha tomado la molestia de publicar comentarios en foros que él visita, decírselo a más conocidos, etc. y de hecho en ocasiones podemos asociar los incrementos en las instalaciones a hechos concretos donde él ha promocionado la App. Lo cierto es que desarrollar una estrategia de promoción de la App puede ser no sólo interesante sino también necesario para lograr una buena cantidad de instalaciones. De hecho, ya existen en Internet cursos on line para aprender a desarrollar estas estrategias (por ejemplo este de Udemy), así que para determinadas Apps yo contemplaría esto como una parte del proyecto de desarrollo de las mismas.
  • En cuanto a temas más concretos, el hecho de tratarse de una App "de nicho" (para un conjunto muy específico de usuarios) tiene sus ventajas e inconvenientes. Por el lado de las desventajas: poca base de usuarios (si nos referimos al total de usuarios de smartphones, por ejemplo); temática de interés muy determinado; que estos usuarios no nos conozcan como un "desarrollador autorizado" (por así decirlo) al que merezca la pena considerar... Pero también tiene sus ventajas: si la App funciona bien, el "boca a boca" es más sencillo y efectivo; la posibilidad de detectar nuevas necesidades en este nicho que podamos satisfacer facilmente con otra App (esta podría ser de pago...); que pueda ser un sector "poco explotado"por otros desarrolladores donde poder crecer facilmente, etc... En definitiva: trabajar con un nicho tiene ventajas e inconvenientes, como todo. Es cuestión de cada uno querer ver la botella medio llena o medio vacía (yo ya sabéis cuál me quedo!).
  • Como esta App surgió como una "prueba de concepto" para un nicho concreto, me permití el lujo de utilizar AppInventor para su desarrollo. Esta herramienta originalmente la desarrolló Google pero hace un tiempo se la cedió al MIT (que es quien la mantiene actualmente), y es un ejemplo de cómo se puede construir software a base de bloques tipo puzzle. Por una parte AppInventor me ha resultado demasiado simple y en ocasiones poco estable para lo que yo quería realizar. Sin embargo, es cierto que lo que empecé diciendo que iba a hacer y lo que he acabado desarrollando es bastante diferente. Por tanto no diré que la herramienta es mala, sino que no la he usado para lo que está diseñada. Aún así, creo que la App resultante es bastante presentable y que con un poco de imaginación los problemas de AppInventor o sus limitaciones pueden ser solucionados. Además, tiene una ventaja adicional: ¡no hay ni un sólo fallo o "error no recuperable" registrado en la App! Y eso, dado el número de usuarios, es algo que está muy bien y debo agradecer a haber utilizado AppInventor. Eso sí, para todo lo demás... usaré algo más potente.
  • En cuanto a cosas que tengo pendientes, la principal (que espero cubrir en breve para sacar la versión 1.1) es proporcionar a los usuarios un mecanismo válido de soporte, a través de una página o portal Web. Esto, aunque tal y como he dicho antes la aplicación no presenta actualmente errores y pueda parecer innecesario, es muy importante no sólo desde el punto de vista del soporte en sí, sino de conocer a nuestros usuarios y poder interactuar con ellos: desde plantear cuestiones a través de la web a los que accedan a la misma para decidir qué nuevas características añadir a la App o qué nuevas App crear, a obtener datos analíticos de valor mediante herramientas como Google Analytics, CrazyEgg, etc. El motivo es muy simple: los datos siempre nos aportan valor y por tanto debemos registrarlos y, por supuesto, analizarlos. No hacerlo es un lujo que no nos podemos permitir en un mercado como Internet y las Apps.
  • Está claro que esto implica que también debemos esforzarnos en tener una web como Dios manda, con todo el trabajo que eso implica, lo cual puede parecer que nos aleja de nuestro objetivo inicial que era simplemente "hacer Apps"... Pero es que lo uno no puede ser sin lo otro, sería como dedicarse a hacer procesadores sin que tengan un ordenador donde funcionar... 
  • Por último, y esto lo añado tras las últimas lecturas que he hecho, está claro que dentro de las Apps también hay clases, y no me refiero al tema de cada una sino a su modelo de "negocio" (si lo tienen): una App gratuita probablemente tenga poco que ver con una App de pago, y tampoco con una "freemium" (las que son gratuitas pero que te ofrecen comprar algo en cuanto quieres avanzar; un ejemplo muy claro son la gran mayoría de Apps de juego actuales). Sin embargo creo que todos los pasos que se aprenden lanzando un App gratuita sí que son comunes en todos los demás casos.
Así que ahora tendré que plantearme conocer alguno de esos otros modelos de App...

Seguramente me habré dejado algo por comentar, así que si cualquiera de los lectores de este post quiere añadir algo más, ¡bienvenido será!