miércoles, 28 de diciembre de 2011
CodeCamp - Introducción a Windows Phone
Andrés Felipe González uno de los asistentes al CodeCamp 2011 grabó la sesión introductoria al Track de Windows Phone, les comparto el audio esperando les resulte de utilidad. Además les recuerdo que el material y presentación del Hands on Lab están publicados en Avanet.
martes, 13 de diciembre de 2011
De metodologías, amistad y contratos de software
Bien, quien lo diría que hoy encontraría inspiración para escribir este tema que tanto tiempo lleva guardado en mi cabeza, y es que como ustedes saben, a mi me gusta hablar de ingeniería de software, experiencias y de todas esas situaciones "humanas" alrededor del tema y que finalmente terminan por impactar la calidad el software.
Yo diría que hoy quiero hablar de otro de esos temas éticos (no juzgables) que ocurren en esto de hacer software, y bueno ni soy experta ni es un tema que atañe solo a la industria de software, solo tengo el sentimiento a flor de piel para hablar de sus consecuencias.
Voy a contar a modo de historia, cada uno de los recuerdos que tengo en mi memoria, ...
Había una vez... nah, no sé ni que decir, veamos...
Otra vez estábamos ahí, frente a un bug de esos que lo dejan a uno pensando como demonios pasó,
¿Cómo pudo llegar algo así a producción? Después de horas de buscar la el problema, la razón fue un error de un desarrollador, una decisión de esas típicas que se tomaban, por darles un ejemplo, tan simple como dar una longitud fija a un vector, cosa que finalmente limitaría el proceso de negocio.
¿Quien le dijo que lo hiciera? ¿Donde está escrito?... la defensa, nadie, tampoco nadie dijo que "no podía hacerlo"... se dio una gran discusión, en el barrullo se escuchaban frases como: ¡Siempre es lo mismo!, ¿Por que no llamamos otro proveedor? ¡No podemos seguir así!, yo guardaba silencio en realidad en ese momento no tenia mucho que opinar.
Después de bastante tiempo perdido la conclusión fue, que nosotros teníamos la culpa, aunque no entendía bien por qué teníamos la culpa de que un programador tuviese malas practicas y asumiera cosas que no se le habían dicho, pero la conclusión era que nosotros teníamos que corregir la forma en que hacíamos las solicitudes para proteger a los desarrolladores de sus "errores conocidos".
El jefe dijo: ustedes ya saben como son, ya saben que cosas siempre hacen mal, entonces, escriban las cosas que no deberían hacer, para que esto no vuelva a suceder, "nosotros somos los responsables del negocio". El ambiente se notaba sombrío y en desacuerdo pero la reunión finalizó. Al salir alguien me susurró:
- Esto nunca va a cambiar, son amigos.
- ¿Amigos? ¿Quienes? - pregunté
- Los proveedores son amigos del jefe
Ese día fue la primera vez que entendí todo, entendí mil razones acerca de por qué no sucedía nada, cada repetida vez que algo mal salía y era culpa de una mala práctica por parte de algún proveedor, así que vamos al post.
El mundo de las influencias en un planeta árido, no comprensible en todas las ocasiones, a hoy yo no sé si por amistad uno termina negociando su ética o simplemente haciéndose el de la vista gorda.
Solo es un punto para concluir una vez más como hacer software es menos mágico y más humano, desde no ser capaz de solicitar calidad por lo que pagas por que a ti mismo te parece poco, sacrificar la arquitectura de un proyecto por años solo por dejarlo en manos de uno de tus amigos, hasta poner en peligro un escenario de negocio, son cosas de las que no se tiene conciencia hasta que no genera un problema real y que es observado por gente externa. Eso de pagar poco me resulta todo un dolor de cabeza, de modo que si un proveedor acepta un contrato en que la tarifa es baja, yo debo aceptar que haga un mal trabajo? Por Dios! Y en premio que hacemos? Les pagamos más? Será que así se van a corregir los vicios de fondo de sus programadores?
La calidad de software tiene un matiz más que no está en estándares ni libros, y tiene que ver con quien es el que elige cuales personas estarán a cargo de tus proyectos, cómo después de extensos procesos de selección solo quedan quien alguien quiere que quede en un lugar.
Que ser amigo de alguien no significa hacerlo mal, es cierto, como tampoco lo es que por elegir un amigo para realizar un trabajo se tenga que disminuir la exigencia sobre los productos y procesos realizados, y no hacer ni el intento de encontrar otras opciones.
¿A que costo se cede la salud de un negocio solo por ofrecer un contrato de software al proveedor equivocado?
Este post suena muy sentido pero no es más que un vago recuerdo, lástima verlo repetidamente en tantas personas e instituciones.
Yo diría que hoy quiero hablar de otro de esos temas éticos (no juzgables) que ocurren en esto de hacer software, y bueno ni soy experta ni es un tema que atañe solo a la industria de software, solo tengo el sentimiento a flor de piel para hablar de sus consecuencias.
Voy a contar a modo de historia, cada uno de los recuerdos que tengo en mi memoria, ...
Había una vez... nah, no sé ni que decir, veamos...
Otra vez estábamos ahí, frente a un bug de esos que lo dejan a uno pensando como demonios pasó,
¿Cómo pudo llegar algo así a producción? Después de horas de buscar la el problema, la razón fue un error de un desarrollador, una decisión de esas típicas que se tomaban, por darles un ejemplo, tan simple como dar una longitud fija a un vector, cosa que finalmente limitaría el proceso de negocio.
¿Quien le dijo que lo hiciera? ¿Donde está escrito?... la defensa, nadie, tampoco nadie dijo que "no podía hacerlo"... se dio una gran discusión, en el barrullo se escuchaban frases como: ¡Siempre es lo mismo!, ¿Por que no llamamos otro proveedor? ¡No podemos seguir así!, yo guardaba silencio en realidad en ese momento no tenia mucho que opinar.
Después de bastante tiempo perdido la conclusión fue, que nosotros teníamos la culpa, aunque no entendía bien por qué teníamos la culpa de que un programador tuviese malas practicas y asumiera cosas que no se le habían dicho, pero la conclusión era que nosotros teníamos que corregir la forma en que hacíamos las solicitudes para proteger a los desarrolladores de sus "errores conocidos".
El jefe dijo: ustedes ya saben como son, ya saben que cosas siempre hacen mal, entonces, escriban las cosas que no deberían hacer, para que esto no vuelva a suceder, "nosotros somos los responsables del negocio". El ambiente se notaba sombrío y en desacuerdo pero la reunión finalizó. Al salir alguien me susurró:
- Esto nunca va a cambiar, son amigos.
- ¿Amigos? ¿Quienes? - pregunté
- Los proveedores son amigos del jefe
Ese día fue la primera vez que entendí todo, entendí mil razones acerca de por qué no sucedía nada, cada repetida vez que algo mal salía y era culpa de una mala práctica por parte de algún proveedor, así que vamos al post.
El mundo de las influencias en un planeta árido, no comprensible en todas las ocasiones, a hoy yo no sé si por amistad uno termina negociando su ética o simplemente haciéndose el de la vista gorda.
Solo es un punto para concluir una vez más como hacer software es menos mágico y más humano, desde no ser capaz de solicitar calidad por lo que pagas por que a ti mismo te parece poco, sacrificar la arquitectura de un proyecto por años solo por dejarlo en manos de uno de tus amigos, hasta poner en peligro un escenario de negocio, son cosas de las que no se tiene conciencia hasta que no genera un problema real y que es observado por gente externa. Eso de pagar poco me resulta todo un dolor de cabeza, de modo que si un proveedor acepta un contrato en que la tarifa es baja, yo debo aceptar que haga un mal trabajo? Por Dios! Y en premio que hacemos? Les pagamos más? Será que así se van a corregir los vicios de fondo de sus programadores?
La calidad de software tiene un matiz más que no está en estándares ni libros, y tiene que ver con quien es el que elige cuales personas estarán a cargo de tus proyectos, cómo después de extensos procesos de selección solo quedan quien alguien quiere que quede en un lugar.
Que ser amigo de alguien no significa hacerlo mal, es cierto, como tampoco lo es que por elegir un amigo para realizar un trabajo se tenga que disminuir la exigencia sobre los productos y procesos realizados, y no hacer ni el intento de encontrar otras opciones.
¿A que costo se cede la salud de un negocio solo por ofrecer un contrato de software al proveedor equivocado?
Este post suena muy sentido pero no es más que un vago recuerdo, lástima verlo repetidamente en tantas personas e instituciones.
domingo, 4 de diciembre de 2011
Los usuarios y la gobernabilidad de IT
Una vez más escribo del día de día, nada es una mejor inspiración aunque en términos prácticos uno preferiría que su vida no fuera el ejemplo de todas esas cosas que no deberían pasar.
Este concepto a pesar de lo "obvio" no es manejado por muchas personas, por eso les dejo aquí una pequeña definición: El término "gobernabilidad " define la capacidad de una organización para controlar y regular su propio funcionamiento con el fin de evitar los conflictos de intereses relacionados con la división entre los beneficiarios y los actores.
“Gobernabilidad” es un término genérico que se puede utilizar de diversas formas acuerdo al contexto.
La expresión “Gobernabilidad” política se utiliza en casos de interacción entre el Estado (gobierno) y la Sociedad (ciudadanos y empresas privadas). Cuando se trata de una compañía o de un grupo industrial, hablamos de "gobernabilidad corporativa"
* Tomado de: http://es.kioskea.net/contents/systeme-d-information/it-gouvernance-si.php3
Tengo que confesarles que cuándo escuché el término la primera vez, y eso de que todos los jefes de la compañia se reunian en el comité de Gobernabilidad, me pareció exagerado ¿Un comité de gobernabilidad de IT? ¿Por qué? La razón es simple, al existir muchos proyectos y recursos que administrar, es necesario darle orden, en especial por que las peticiones al área de IT son un caudal constante y creciente en las organizaciones y los recursos (tiempo, dinero y personas) somos limitados.
Hay que decir que muchos usuarios son pacientes o les toca serlo, yo tengo un proyecto actualmente con más de 200 días de espera por ser iniciado y a mi usuario no le toca más que sonreir cada vez conmigo y lanzarnos bromas al respecto de que quizá ni las predicciones Mayas de 2012 nos dejen terminarlo. Antes de continuar con la razón de contarles mis aventuras en este post, tengo que mencionar que igual la gobernabilidad deberia darse en cual escenario asi los recursos y proyectos no fueran muchos.
Un comité de gobernabilidad se encarga de definir las prioridades que debe atender IT, esto aunque a veces es frustrante para los que nos dedicamos a hacer, tiene mucho sentido, ya que por política o necesidad, son las personas que dirigen la organización las que llevan el rumbo del negocio y cuándo no hay forma de atender todo el tiempo, no es IT la que pone el rostro para decir que no tenia como hacerlo, si no que los usuarios debían definir que debía atenderse, y eso cambia sustancialmente la respuesta cuándo el momento de los reclamos llega, ya que en dicho comité tienen en cuenta además las metas anuales, las personas disponibles y el dinero disponible, en el caso del lugar donde trabajo, con respecto al dinero disponible hay una expectativa que llenar que siempre me ha parecido curiosa y que he visto en otros lugares, y es, que el presupuesto destinado para un año debe gastarse, no debe sobrepasarse ni debe ahorrarse, todo debe invertirse, y es una métrica muy importante para todos, en esa vía planear mensualmente al comité de gobierno las necesidades de inversión y los proyectos pendientes, es más un "estrategia" que una simple lista que ordenar, los usuarios velan por sacar adelante sus proyectos más apremiantes a veces también sus caprichos, pero el equilibrio se establece cuando además está IT y los altos directivos, IT luchará por innovar, actualizar y mantener sus actuales sistemas, y la alta dirección decidirá que de todos esos puntos de vista es lo que se debe hacer.
El título de este post hace alusión a los usuarios, la razón fue algo que viví con un proyecto hace poco, el proyecto llegó, era muy pequeño sin embargo de impacto en la imagen de la compañía, pero técnicamente era algo "simple" de resolver a los ojos de usuario. Al listar las necesidades funcionales, la teoría de los usuarios se confirmaba, era simple, el problema tenia que ver con "quien iba a construirlo" y "que tecnologías usarían" para que dicho proyecto apalancara la estrategia general de la compañía. Me disculparán si hablo como en clave, es evidente que no puedo hablar del proyecto abiertamente.
Ahora bien, al llegar la solicitud a mi, contemple la posibilidad incluso de hacerlo yo misma, los usuarios trajeron su proveedor sugerido, un absoluto desastre por cierto, estos sabían más de anatomía de pollos, pero estaban dispuestos hasta a trabajar gratis con tal de ser proveedores de la compañía, nada habla más mal de un proveedor así. Por otro lado decidimos ver varios proveedores y entre ellos nos encontramos uno, que además de dar una rápida solución al proyecto, garantizaba el futuro de la organización estableciendo una estrategia para el tema, ya que lejos de proveer una solucíón particular, tenía una plataforma genérica para afrontar ese y otros muchos problemas. Un momento, si nos ponemos en contexto, el tamaño del proyecto, el tiempo y el dinero disponible, ese podría ser el proveedor soñado pero, no el proveedor para un proyecto de ese tamaño, ya que el costo se multiplicaría por 100, créanme por 100 si no es más. Así se intentaron ver varios proveedores, algunos simplemente escucharon la necesidad y sus propuestas jamás llegaron, no tengo idea si el problema estuvo en el tamaño del proyecto, pero en 1 mes no alcanzamos a encontrar un proveedor con una propuesta coherente tecnológicamente hablando que a su vez lo fuera en costos.
De repente el proyecto cayo en el olvido, a mi me asignaron otras prioridades al no encontrar el proveedor y no volví a saber del tema, luego de unas semanas revisando la prensa interna vi el anuncio del proyecto ya en producción, me pude quedar de una sola pieza lo único que podía pensar es que habían aceptado la propuesta de aquel proveedor incoherente (nada espero más que no lo hayan hecho) sin embargo, el tema me quedó muchos días en la cabeza hasta terminar aquí escribiendo, una queja más de las que abundan en la red por parte de ingenieros de sistemas contra los usuarios.
Analizando lo sucedido desde el punto de vista de gobernabilidad, lo que hacen los usuarios es dejar de afectar el presupuesto de IT que parece tan luchado y simplemente, poner de su propio presupuesto, contratar a quien mejor les parece que les prometa que lo que quieren sale rápido y ya, para un usuario ese parece ser el fin de su vida, cumplir sus caprichos a como dé lugar, el futuro es típico y repetitivo, la mala selección de un proveedor, el hecho de que la área de negocio que contrata el proveedor, no sepa como manejar contratos de software o que debe exigir metodologías y artefactos para el software que se crea, empieza a crear un nuevo sistema fantasma, con el tiempo el proveedor es tan malo que lo único que ocurre es que ellos terminan por darse cuenta de su error y despedirlo, y el proyecto jamás llego a ningún lugar. ¡Momento! ¿Ningún lugar? Ese ningún lugar es el área de IT donde se le tendrá que dar soporte a un proyecto abandonado, sin documentación y con seguro las peores prácticas de programación jamás vistas, por que como los usuarios se la creen que el software es un producto de masa empaquetado que tiene una receta de ingredientes, entre ellos magia, jamás se percataron de si estaba bien hecho o no.
Mi pregunta hoy ya no va como siempre contra la responsabilidad de los ingenieros de sistemas y el si conocen o no buenas practicas de software, hoy arremeto contra los usuarios, contra aquellos que como nosotros deberían alinearse y evolucionar y dejar de creer que el software es una mezcla de deseos y magia que naturalmente produce los efectos que se desean y que así como en sus diferentes campos de acción hay procesos que respetar, también los hay en el área de IT.
Solo queda arremeter contra alguien más contra los empíricos proveedores que hacen este tipo de cosas, que eticamente saben son incorrectas pero que les importa un bledo y que evidentemente solo les importa ganarse un contrato y no atender coherentemente las necesidades de los usuarios y negocios a los que se presentan, sin siquiera detenerse profesionalmente a pensar en el tema de hacer bien su trabajo.
En fin, aquí no hay moraleja, este caso es del día a día en muchas organizaciones, comprensible es que los protocolos restan oportunidades al negocio, a las que se debe reaccionar con tecnología, pero quizá la salida no es actuar a punta de caprichos su no crear áreas de reacción inmediata para este tipo de proyectos y no solo áreas consumidas por el soporte a los sistemas de producción y que nunca tenemos el tiempo para apalancar al negocio en los nuevos escenarios tecnológicos.
Espero sus comentarios, hasta la próxima.
Sorey ;)
Imagen tomada de: http://reporteciencianl.com/2011/06/retos-de-la-gobernabilidad/
“Gobernabilidad” es un término genérico que se puede utilizar de diversas formas acuerdo al contexto.
La expresión “Gobernabilidad” política se utiliza en casos de interacción entre el Estado (gobierno) y la Sociedad (ciudadanos y empresas privadas). Cuando se trata de una compañía o de un grupo industrial, hablamos de "gobernabilidad corporativa"
* Tomado de: http://es.kioskea.net/contents/systeme-d-information/it-gouvernance-si.php3
Tengo que confesarles que cuándo escuché el término la primera vez, y eso de que todos los jefes de la compañia se reunian en el comité de Gobernabilidad, me pareció exagerado ¿Un comité de gobernabilidad de IT? ¿Por qué? La razón es simple, al existir muchos proyectos y recursos que administrar, es necesario darle orden, en especial por que las peticiones al área de IT son un caudal constante y creciente en las organizaciones y los recursos (tiempo, dinero y personas) somos limitados.
Hay que decir que muchos usuarios son pacientes o les toca serlo, yo tengo un proyecto actualmente con más de 200 días de espera por ser iniciado y a mi usuario no le toca más que sonreir cada vez conmigo y lanzarnos bromas al respecto de que quizá ni las predicciones Mayas de 2012 nos dejen terminarlo. Antes de continuar con la razón de contarles mis aventuras en este post, tengo que mencionar que igual la gobernabilidad deberia darse en cual escenario asi los recursos y proyectos no fueran muchos.
Un comité de gobernabilidad se encarga de definir las prioridades que debe atender IT, esto aunque a veces es frustrante para los que nos dedicamos a hacer, tiene mucho sentido, ya que por política o necesidad, son las personas que dirigen la organización las que llevan el rumbo del negocio y cuándo no hay forma de atender todo el tiempo, no es IT la que pone el rostro para decir que no tenia como hacerlo, si no que los usuarios debían definir que debía atenderse, y eso cambia sustancialmente la respuesta cuándo el momento de los reclamos llega, ya que en dicho comité tienen en cuenta además las metas anuales, las personas disponibles y el dinero disponible, en el caso del lugar donde trabajo, con respecto al dinero disponible hay una expectativa que llenar que siempre me ha parecido curiosa y que he visto en otros lugares, y es, que el presupuesto destinado para un año debe gastarse, no debe sobrepasarse ni debe ahorrarse, todo debe invertirse, y es una métrica muy importante para todos, en esa vía planear mensualmente al comité de gobierno las necesidades de inversión y los proyectos pendientes, es más un "estrategia" que una simple lista que ordenar, los usuarios velan por sacar adelante sus proyectos más apremiantes a veces también sus caprichos, pero el equilibrio se establece cuando además está IT y los altos directivos, IT luchará por innovar, actualizar y mantener sus actuales sistemas, y la alta dirección decidirá que de todos esos puntos de vista es lo que se debe hacer.
El título de este post hace alusión a los usuarios, la razón fue algo que viví con un proyecto hace poco, el proyecto llegó, era muy pequeño sin embargo de impacto en la imagen de la compañía, pero técnicamente era algo "simple" de resolver a los ojos de usuario. Al listar las necesidades funcionales, la teoría de los usuarios se confirmaba, era simple, el problema tenia que ver con "quien iba a construirlo" y "que tecnologías usarían" para que dicho proyecto apalancara la estrategia general de la compañía. Me disculparán si hablo como en clave, es evidente que no puedo hablar del proyecto abiertamente.
Ahora bien, al llegar la solicitud a mi, contemple la posibilidad incluso de hacerlo yo misma, los usuarios trajeron su proveedor sugerido, un absoluto desastre por cierto, estos sabían más de anatomía de pollos, pero estaban dispuestos hasta a trabajar gratis con tal de ser proveedores de la compañía, nada habla más mal de un proveedor así. Por otro lado decidimos ver varios proveedores y entre ellos nos encontramos uno, que además de dar una rápida solución al proyecto, garantizaba el futuro de la organización estableciendo una estrategia para el tema, ya que lejos de proveer una solucíón particular, tenía una plataforma genérica para afrontar ese y otros muchos problemas. Un momento, si nos ponemos en contexto, el tamaño del proyecto, el tiempo y el dinero disponible, ese podría ser el proveedor soñado pero, no el proveedor para un proyecto de ese tamaño, ya que el costo se multiplicaría por 100, créanme por 100 si no es más. Así se intentaron ver varios proveedores, algunos simplemente escucharon la necesidad y sus propuestas jamás llegaron, no tengo idea si el problema estuvo en el tamaño del proyecto, pero en 1 mes no alcanzamos a encontrar un proveedor con una propuesta coherente tecnológicamente hablando que a su vez lo fuera en costos.
De repente el proyecto cayo en el olvido, a mi me asignaron otras prioridades al no encontrar el proveedor y no volví a saber del tema, luego de unas semanas revisando la prensa interna vi el anuncio del proyecto ya en producción, me pude quedar de una sola pieza lo único que podía pensar es que habían aceptado la propuesta de aquel proveedor incoherente (nada espero más que no lo hayan hecho) sin embargo, el tema me quedó muchos días en la cabeza hasta terminar aquí escribiendo, una queja más de las que abundan en la red por parte de ingenieros de sistemas contra los usuarios.
Analizando lo sucedido desde el punto de vista de gobernabilidad, lo que hacen los usuarios es dejar de afectar el presupuesto de IT que parece tan luchado y simplemente, poner de su propio presupuesto, contratar a quien mejor les parece que les prometa que lo que quieren sale rápido y ya, para un usuario ese parece ser el fin de su vida, cumplir sus caprichos a como dé lugar, el futuro es típico y repetitivo, la mala selección de un proveedor, el hecho de que la área de negocio que contrata el proveedor, no sepa como manejar contratos de software o que debe exigir metodologías y artefactos para el software que se crea, empieza a crear un nuevo sistema fantasma, con el tiempo el proveedor es tan malo que lo único que ocurre es que ellos terminan por darse cuenta de su error y despedirlo, y el proyecto jamás llego a ningún lugar. ¡Momento! ¿Ningún lugar? Ese ningún lugar es el área de IT donde se le tendrá que dar soporte a un proyecto abandonado, sin documentación y con seguro las peores prácticas de programación jamás vistas, por que como los usuarios se la creen que el software es un producto de masa empaquetado que tiene una receta de ingredientes, entre ellos magia, jamás se percataron de si estaba bien hecho o no.
Mi pregunta hoy ya no va como siempre contra la responsabilidad de los ingenieros de sistemas y el si conocen o no buenas practicas de software, hoy arremeto contra los usuarios, contra aquellos que como nosotros deberían alinearse y evolucionar y dejar de creer que el software es una mezcla de deseos y magia que naturalmente produce los efectos que se desean y que así como en sus diferentes campos de acción hay procesos que respetar, también los hay en el área de IT.
Solo queda arremeter contra alguien más contra los empíricos proveedores que hacen este tipo de cosas, que eticamente saben son incorrectas pero que les importa un bledo y que evidentemente solo les importa ganarse un contrato y no atender coherentemente las necesidades de los usuarios y negocios a los que se presentan, sin siquiera detenerse profesionalmente a pensar en el tema de hacer bien su trabajo.
En fin, aquí no hay moraleja, este caso es del día a día en muchas organizaciones, comprensible es que los protocolos restan oportunidades al negocio, a las que se debe reaccionar con tecnología, pero quizá la salida no es actuar a punta de caprichos su no crear áreas de reacción inmediata para este tipo de proyectos y no solo áreas consumidas por el soporte a los sistemas de producción y que nunca tenemos el tiempo para apalancar al negocio en los nuevos escenarios tecnológicos.
Espero sus comentarios, hasta la próxima.
Sorey ;)
Imagen tomada de: http://reporteciencianl.com/2011/06/retos-de-la-gobernabilidad/
domingo, 6 de noviembre de 2011
Consideraciones (no técnicas) para el desarrollo móvil
He usado este título indiscriminadamente ya que muchos de los puntos a tratar en este post son evidentemente técnicos, sin embargo llevan un llamado de atención y el decir que no son técnicas las consideraciones que escribiré es más para indicarle a los fanáticos de la guerra entre marcas de sistemas operativos y lenguajes de programación, que aquí no encontrarán nada de eso.
Hace un tiempo hice una presentación con base en la materia de computación móvil que vi en mi especialización en EAFIT acerca de las consideraciones para desarrollar aplicaciones móviles, tema que di como desconferencia en BarCamp Medellín en 2009 y en BarCamp Cúcuta en 2010, hay que ver como ha cambiado súbitamente el escenario de desarrollo de aplicaciones móviles para estos días en el panorama nacional, es probable que en otros paises para 2009 ya este escenario estuviese tomando muchos matices, pero evidentemente la popularización del uso de las tablets y smartphones ha puesto en boca de todas las personas lo que ya se evidenciaba como una tendencia en los mercados internacionales, la movilidad.
Y bien, probablemente no haya nada nuevo que decir, temas como estos son analizados técnicamente por muchos, y también desde otras perspectivas a las que no muchos prestamos atención cuando estamos aprendiendo alguna tecnología en particular.
Pues bien esas consideraciones y algunas otras a las que también me refería en mi post anterior son a las que me referiré ahora, sin embargo no entraré a considerar mis preferencias o lo que es mejor o no con respecto a ninguna tecnología, más bien les plantearé algunos escenarios y criterios para tomar diferentes decisiones, por que en esto del desarrollo para móvil hay más de una decisión que tomar.
Empecemos por aclarar el tema de los dispositivos móviles que para más de uno hasta hace poco no eran más que los celulares, ahora con las tablets a muchos les queda claro que se trata más que de tener gadgets, hablar de movilidad es tener la posibilidad de tener tus datos y aplicaciones en cualquier lugar, por eso hay desde dispositivos pequeños de uso personal, hasta algunos de gammas medias para uso personal o empresarial, y hasta notebooks (si señor considerados como dispositivos móviles) pero que obviamente tienen una serie de características que lo hacen un escenario robusto, pocos piensan en dispositivos como los rugged devices que son dispositivos móviles para el trabajo pesado, que soportan escenarios agrestes que se producen en diversos entornos empresariales u otros tan comunes y simples como las pantallas táctiles ubicadas en super mercados, y que también son consideradas dispositivos móviles. Es así como se reducen los esquemas mentales a pensar que el desarrollo móvil cubre aplicaciones únicamente de uso personal, escenario que si bien es muy popular no es el único y no enfrenta a muchas consideraciones que si lo hace el ámbito empresarial.
A la gran variedad de dispositivos móviles debemos adicionarle la gran cantidad de sistemas operativos disponibles para cada uno de esos dispositivos y por lo tanto la disponibilidad de tecnologías que además trabajen correctamente sobre esos sistemas operativos, es así como el campo de la movilidad se ha fragmentado terriblemente, y de pasar de convivir con 3 sistemas operativos comunes y unos cuántos lenguajes que se daban la guerra entre si, tenemos un escenario, de múltiples dispositivos, múltiples sistemas operativos y múltiples tecnologías de desarrollo.
Esta situación de mano con el crecimiento en la capacidad de los dispositivos y el hecho de que ahora tengamos a la mano equipos con la posibilidad de correr casi completamente cualquier aplicación web con navegadores que hasta hace poco solo podían ejecutarse en un PC de escritorio, ha producido en la industria del desarrollo más de un efecto, de por sí la mano de obra de profesionales capacitados en el área de sistemas ha estado en declive con los años, por razones que considerar no son ámbito de este post, pero que en conjunto con lo anteriormente descrito, ha hecho que más de un desarrollador web, y más de una empresa de marketing y publicidad ingrese a competir y ofrecer abiertamente a grandes compañias sus servicios de desarrollo de aplicaciones móviles que funcionan en cualquier dispositivo.
Bien, empecemos por ver que tiene eso de falso y de verdadero, en primer lugar, no por saber desarrollar para web, se sabe desarrollar para móvil, desarrollar para móvil nunca ha sido ni será hacer una aplicación miniatura, lo que habrá que considerar entonces es si la aplicación que necesitamos lo único que requiere es una mini-web y por otro lado si el futuro de esa aplicación no requiere características avanzadas para interactuar con los dispositivos.
Como sé que más de un programador llegará por aquí, aclaro que si se bien que existe la posibilidad de usar frameworks como Phone Gap para programar una sola vez y usar la misma app en diferentes plataformas, también llegue a programar con Mobile JSF y he escuchado acerca de los beneficios de JQueryMobile para web móvil, lo único que puedo decir a eso es que conociendo la cada vez más exigente solicitud de buena experiencia de usuario por parte de las personas que usan dispositivos móviles, una sola aplicación que use eficientemente las capacidades de todos los dispositivos usando un framework va a estar difícil, sin embargo es un escenario a evaluar que en algunos casos puede resultar válido, pero seguramente no en la mayoría, y dudosamente una empresa dedicada a publicacidad o marketing tendrá un gran área de desarrollo dedicada a fortalecer a su gente en mejores prácticas de desarrollo de software o el uso de herramientas de este tipo.
Por otro lado, cuando el tema se vuelve de tener una excelente experiencia de usuario, usar funciones avanzadas del teléfono y lo que se necesita es que nuestra aplicación esté disponible en las diferentes tiendas de aplicaciones, el problema se torna aún peor. Actualmente la forma como los principales proveedores de software que dominan el mercado de los sistemas operativos para móvil están trabajando, hace que un lenguaje como java que lideraba el mercado de desarrollo de aplicaciones móviles por tener la posibilidad de ser multiplataforma, se ubique al mismo nivel de los demás al ser un lenguaje que adopta algunas plataformas específicas y que en realidad ya no puede ofrecer dicha ventaja, por más de un tema de seguridad de las aplicaciones a las cuales no se les está permitiendo acceder a las capacidades de los dispositivos directamente si no a través de APIs de programación que provee el mismo Sistema Operativo.
Esta parte del escenario genera muchos más problemas de los que se pueden intuir, eso de mano con la escasa mano de obra profesional, lleva a que cada plataforma se luche a los entusiastas del desarrollo de aplicaciones para engancharlos al desarrollo de la suya en particular, mundos cada cual que pueden ser tan amplios que encontrar un programador que trabaje y que tenga experiencia real en desarrollo para diferentes plataformas, es una necesidad cada vez más común y más difícil de cubrir.
Creo que a más preguntas como esas quisiera llevarlos cuando les hablo de consideraciones no técnicas, esto del mundo del desarrollo móvil no se trata simplemente de lograr encontrar un programador disponible entre la escasez, tampoco de que plataforma es común o no, temas como la dependencia de un solo programador por existir tan pocos disponibles, la cantidad de tiempo que tomaría implementar nuestra aplicación para cada uno de los dispositivos y plataformas, si voy a trabajar para una sola plataforma y tendré el presupuesto para que los empleados que trabajan para mi tengan un dispositivo donde corra mi aplicación o bien, si mi aplicación es de uso masivo cuantas personas usuarios potenciales de mi aplicación teniendo en cuenta sus edades, intereses, ubicación geográfica y el foco de mi aplicación, son consideraciones más importantes que pensar en quien es el más popular en el mercado.
Espero que algunas de estas consideraciones les sirvan de utilidad antes de emprender algún desarrollo serio de aplicaciones para móvil. Espero sus comentarios y hasta la próxima.
Sorey ;)
Imagenes tomádas de:
http://www.muycanal.com/wp-content/uploads/2011/10/tablets.jpg
http://www.redusers.com/noticias/wp-content/uploads/2011/10/smartphones-1912.jpg
Hace un tiempo hice una presentación con base en la materia de computación móvil que vi en mi especialización en EAFIT acerca de las consideraciones para desarrollar aplicaciones móviles, tema que di como desconferencia en BarCamp Medellín en 2009 y en BarCamp Cúcuta en 2010, hay que ver como ha cambiado súbitamente el escenario de desarrollo de aplicaciones móviles para estos días en el panorama nacional, es probable que en otros paises para 2009 ya este escenario estuviese tomando muchos matices, pero evidentemente la popularización del uso de las tablets y smartphones ha puesto en boca de todas las personas lo que ya se evidenciaba como una tendencia en los mercados internacionales, la movilidad.
Pues bien esas consideraciones y algunas otras a las que también me refería en mi post anterior son a las que me referiré ahora, sin embargo no entraré a considerar mis preferencias o lo que es mejor o no con respecto a ninguna tecnología, más bien les plantearé algunos escenarios y criterios para tomar diferentes decisiones, por que en esto del desarrollo para móvil hay más de una decisión que tomar.
Empecemos por aclarar el tema de los dispositivos móviles que para más de uno hasta hace poco no eran más que los celulares, ahora con las tablets a muchos les queda claro que se trata más que de tener gadgets, hablar de movilidad es tener la posibilidad de tener tus datos y aplicaciones en cualquier lugar, por eso hay desde dispositivos pequeños de uso personal, hasta algunos de gammas medias para uso personal o empresarial, y hasta notebooks (si señor considerados como dispositivos móviles) pero que obviamente tienen una serie de características que lo hacen un escenario robusto, pocos piensan en dispositivos como los rugged devices que son dispositivos móviles para el trabajo pesado, que soportan escenarios agrestes que se producen en diversos entornos empresariales u otros tan comunes y simples como las pantallas táctiles ubicadas en super mercados, y que también son consideradas dispositivos móviles. Es así como se reducen los esquemas mentales a pensar que el desarrollo móvil cubre aplicaciones únicamente de uso personal, escenario que si bien es muy popular no es el único y no enfrenta a muchas consideraciones que si lo hace el ámbito empresarial.
A la gran variedad de dispositivos móviles debemos adicionarle la gran cantidad de sistemas operativos disponibles para cada uno de esos dispositivos y por lo tanto la disponibilidad de tecnologías que además trabajen correctamente sobre esos sistemas operativos, es así como el campo de la movilidad se ha fragmentado terriblemente, y de pasar de convivir con 3 sistemas operativos comunes y unos cuántos lenguajes que se daban la guerra entre si, tenemos un escenario, de múltiples dispositivos, múltiples sistemas operativos y múltiples tecnologías de desarrollo.
Esta situación de mano con el crecimiento en la capacidad de los dispositivos y el hecho de que ahora tengamos a la mano equipos con la posibilidad de correr casi completamente cualquier aplicación web con navegadores que hasta hace poco solo podían ejecutarse en un PC de escritorio, ha producido en la industria del desarrollo más de un efecto, de por sí la mano de obra de profesionales capacitados en el área de sistemas ha estado en declive con los años, por razones que considerar no son ámbito de este post, pero que en conjunto con lo anteriormente descrito, ha hecho que más de un desarrollador web, y más de una empresa de marketing y publicidad ingrese a competir y ofrecer abiertamente a grandes compañias sus servicios de desarrollo de aplicaciones móviles que funcionan en cualquier dispositivo.
Bien, empecemos por ver que tiene eso de falso y de verdadero, en primer lugar, no por saber desarrollar para web, se sabe desarrollar para móvil, desarrollar para móvil nunca ha sido ni será hacer una aplicación miniatura, lo que habrá que considerar entonces es si la aplicación que necesitamos lo único que requiere es una mini-web y por otro lado si el futuro de esa aplicación no requiere características avanzadas para interactuar con los dispositivos.
Como sé que más de un programador llegará por aquí, aclaro que si se bien que existe la posibilidad de usar frameworks como Phone Gap para programar una sola vez y usar la misma app en diferentes plataformas, también llegue a programar con Mobile JSF y he escuchado acerca de los beneficios de JQueryMobile para web móvil, lo único que puedo decir a eso es que conociendo la cada vez más exigente solicitud de buena experiencia de usuario por parte de las personas que usan dispositivos móviles, una sola aplicación que use eficientemente las capacidades de todos los dispositivos usando un framework va a estar difícil, sin embargo es un escenario a evaluar que en algunos casos puede resultar válido, pero seguramente no en la mayoría, y dudosamente una empresa dedicada a publicacidad o marketing tendrá un gran área de desarrollo dedicada a fortalecer a su gente en mejores prácticas de desarrollo de software o el uso de herramientas de este tipo.
Por otro lado, cuando el tema se vuelve de tener una excelente experiencia de usuario, usar funciones avanzadas del teléfono y lo que se necesita es que nuestra aplicación esté disponible en las diferentes tiendas de aplicaciones, el problema se torna aún peor. Actualmente la forma como los principales proveedores de software que dominan el mercado de los sistemas operativos para móvil están trabajando, hace que un lenguaje como java que lideraba el mercado de desarrollo de aplicaciones móviles por tener la posibilidad de ser multiplataforma, se ubique al mismo nivel de los demás al ser un lenguaje que adopta algunas plataformas específicas y que en realidad ya no puede ofrecer dicha ventaja, por más de un tema de seguridad de las aplicaciones a las cuales no se les está permitiendo acceder a las capacidades de los dispositivos directamente si no a través de APIs de programación que provee el mismo Sistema Operativo.
Esta parte del escenario genera muchos más problemas de los que se pueden intuir, eso de mano con la escasa mano de obra profesional, lleva a que cada plataforma se luche a los entusiastas del desarrollo de aplicaciones para engancharlos al desarrollo de la suya en particular, mundos cada cual que pueden ser tan amplios que encontrar un programador que trabaje y que tenga experiencia real en desarrollo para diferentes plataformas, es una necesidad cada vez más común y más difícil de cubrir.
Usaré un ejemplo para llevarles un poco al escenario en el que están cayendo las organizaciones sin darse cuenta, algunos de nosotros pensamos que el lanzamiento de Windows Phone iba a ser el final de Windows Mobile, al escuchar la versión oficial de esta situación, nada tenia que ver con lo que pensabamos, la versión de Windows Mobile pasará a ser Windows Embedded, la razón es que los escenarios empresariales necesitan seguir avanzando, pero en el caso de Microsoft ellos han pasado además a querer competir mano a mano con plataformas como iPhone y Android que están más enfocadas actualmente al público masivo, que tipicamente usa sus dispositivos móviles para uso personal. Colocando esta situación en los escenarios anteriormente descritos, hay dos escenarios ahora para los que trabajamos tecnologías Microsoft, y la pregunta es ¿Las otras plataformas competirán en el ámbito empresarial? ¿Quien compite en ese ámbito si yo buscara una alternativa? Ahí lo dejo de tarea para ustedes y para mí.
Me apalanco en este último tema para presentarles una perspectiva un poco más profesional, continuando con eso de lo que deberían tener en consideración empresas o proyectos cuyas aplicaciones móviles deban ser pensadas no momentaneamente o como utilidad de uso personal y es los procesos y las metodologías de software, mi tema de siempre, si bien, podemos encontrar cantidad de entusiastas dedicados al desarrollo de aplicaciones para cada una de las plataformas disponibles, la pregunta es ¿nuestros escenarios empresariales pueden someterse a escenarios de este tipo? ¿donde quedan las mejores prácticas de metodologías de desarrollo de software ágiles o estructuradas? ¿Cuántos de estos entusiastas se preocuparán por la documentación, la seguridad, la usabilidad, las pruebas de software, el soporte, la arquitectura, el buen desempeño y la mantenibilidad de nuestras aplicaciones?
Me apalanco en este último tema para presentarles una perspectiva un poco más profesional, continuando con eso de lo que deberían tener en consideración empresas o proyectos cuyas aplicaciones móviles deban ser pensadas no momentaneamente o como utilidad de uso personal y es los procesos y las metodologías de software, mi tema de siempre, si bien, podemos encontrar cantidad de entusiastas dedicados al desarrollo de aplicaciones para cada una de las plataformas disponibles, la pregunta es ¿nuestros escenarios empresariales pueden someterse a escenarios de este tipo? ¿donde quedan las mejores prácticas de metodologías de desarrollo de software ágiles o estructuradas? ¿Cuántos de estos entusiastas se preocuparán por la documentación, la seguridad, la usabilidad, las pruebas de software, el soporte, la arquitectura, el buen desempeño y la mantenibilidad de nuestras aplicaciones?
Creo que a más preguntas como esas quisiera llevarlos cuando les hablo de consideraciones no técnicas, esto del mundo del desarrollo móvil no se trata simplemente de lograr encontrar un programador disponible entre la escasez, tampoco de que plataforma es común o no, temas como la dependencia de un solo programador por existir tan pocos disponibles, la cantidad de tiempo que tomaría implementar nuestra aplicación para cada uno de los dispositivos y plataformas, si voy a trabajar para una sola plataforma y tendré el presupuesto para que los empleados que trabajan para mi tengan un dispositivo donde corra mi aplicación o bien, si mi aplicación es de uso masivo cuantas personas usuarios potenciales de mi aplicación teniendo en cuenta sus edades, intereses, ubicación geográfica y el foco de mi aplicación, son consideraciones más importantes que pensar en quien es el más popular en el mercado.
Espero que algunas de estas consideraciones les sirvan de utilidad antes de emprender algún desarrollo serio de aplicaciones para móvil. Espero sus comentarios y hasta la próxima.
Sorey ;)
Imagenes tomádas de:
http://www.muycanal.com/wp-content/uploads/2011/10/tablets.jpg
http://www.redusers.com/noticias/wp-content/uploads/2011/10/smartphones-1912.jpg
sábado, 5 de noviembre de 2011
La política, las necesidades del negocio y la tecnología
Hace unas semanas estaba pendiente de escribir este post, justo ahora que recuerdo mi proyecto estancado, recuerdo también por que queria escribirlo, la idea, abordar un poco lo que sucede en el mundo de las Tecnologías de Información (TI o IT) cuando nos enfrentamos al desarrollo de proyectos de software siendo analistas de negocio, una posición que la verdad no muchos entienden cuándo su rol es ser desarrolladores y no tomadores de decisiones, o al menos, eso me sucedía a mi.
Desde hace 8 años me encuentro en el mundo laboral, he sido analista programador y pase de dar soporte por 3 años para compañias grandes a ser parte dele equipo de Investigación y Desarrollo de la casa de software donde trabajé durante cinco años, luego de eso terminé en otra casa de software siendo diseñador de software (no, nada de look and feel), en ese lugar terminé amando el UML y aprendiendo un poco de ser lider técnico de un equipo y cuasi arquitecto de software, ante la apatía del arquitecto que estaba encargado.Pues bien, luego de ires y venires terminé estando una empresa del tipo de empresa que siempre me juré no estar si no hasta el declive de mi carrera profesional y teniendo como cargo ser analista de negocio, una experiencia sencillamente diferente.
Después de estar al margen durante un tiempo con pasos agigantados hacia atrás dando soporte, por fin fuí tenida en cuénta para cosas que valen la pena, y como en la mayoria de empresas grandes, las labores importantes de un analista se vuelven leer correos, hacer labores administrativas, seleccionar y supervisar a proveedores, ese rol tiene un montón de matices con los que no estoy de acuerdo y que terminan haciendo que los profesionales terminen por volverse seres obsoletos, pero ese es un tema de otro post.
Lo que me lleva a escribir es una experiencia que tuve en una presentación de un proveedor, de los pocos la verdad que me pudo dejar absolutamente atenta observándolo y escuchándolo por 3 horas continuas. Este señor Daniel, por su nombre de pila y de quien tengo que omitir su detalles por temas corportativos, después de explicarnos en que consistía su herramienta y de que mi jefe le preguntara como hacian para negociarla, presentó varios puntos que me dejarón impresionada, a mi pesar corporativamente hablando, pero admirada en el ámbito personal.
En su larga respuesta y explicación habló de varios puntos de los que espero espero transmitir con fidelidad dos de ellos:
- La politica es más importante que la necesidades de negocio: Cuando mencionó esto la verdad es que no le entendí, sin embargo el explicó. Cuando uno va pasando por los diferentes estadíos de su carrera profesional (de ahí que les contara un poco de mi recorrido por que coincido totalmente con lo que dice este señor), cuando recién se esta empezando, tiende a pesar que IT, es quien manda, que la tecnología es quien dirige a los negocios llevándolos a evolucionar día a día, es apenas comprensible tener esa visión de las cosas, si te ubicas al pie de una montaña dificilmente vas a observar lo que sucede en el panorama general, y haciendo un símil, desde esa posición parece que si le pones pies a la montaña, pues va a salir andando, y te quejas constantemente de que justamente alguien con dinero y desde las altas esferas no le ponga pies a la montaña para que ande a un ritmo más acelerado.
Después de que has recorrido un poco el camino y te acercas a cargos que si bien no toman las decisiones directamente, influyen en algunas de ellas y están cerca de quienes si las toman, sucede que empiezas a comprender que los negocios se rigen por unas necesidades, esas necesidades son quienes llevan a los tomadores de decisiones a invertir en lo que de verdad necesita el negocio para cumplir con sus metas.
En este punto la queja es, ¿por que no hay mejores tomadores de decisiones? ¿por que no hay gente realmente capacitada para tomar esas decisiones? Personas informadas y que entiendan temas de vanguardia tecnológica, para no dejar que proveedores maliciosos les vendan oro falso, los días son pensados viendo como la desinformación de quienes más influencia tienen llevan a las empresas a caer en fiascos que eran tan obvios.
En ese punto me encontraba yo hasta conocer a esta persona y ahora viene su enseñanza, el dijo, saben, están muy equivocados, las necesidades no son las que llevan el negocio, es la política. En ese momento imagino mi cara de signo de interrogación ¿como qué no son las necesidades? ¿la política? ¿qué importa la política?. Daniel continuó su discurso explicando como si no hay un interés real de alguien en una alta esfera por llevar a cabo un proyecto, aunque ese proyecto sea una gran necesidad de tu empresa, nunca va a realizarse. Si yo sé que esto no es nada de otro mundo, y que es muy obvio, pero creo que yo jamás lo habia visto de esa forma. En efecto de eso se trataba mi proyecto, del cual lamento no poder comentar, pero es una necesidad que debería estar cubierta hace muchos años, por mera competitividad, y cuya decisión lleva retrasada meses por que nadie de un alto rango se encontraba interesado hasta ahora. Alguno dirá que es trabajo de un analista de negocio presentarle a los directores estas necesidades, pero en este caso particular, eso no ha faltado.
Analizando un poco más lo que dice Daniel, me impresiona el pensar que despues de unos meses cuándo al fin caen en cuenta que el mundo va más rápido de lo que va la compañia, y lo que era un deber ser, se convierte en una necesidad apremiante, entonces llega la búsqueda acelerada de proveedores, en la que mi trabajo actualmente es no dejar que contraten uno de esos que vende falsas expectativas.
- Nuestro producto y nuestro trabajo valen: Creo que este subtítulo que le di no hace justicia con lo que significa este punto que voy a contarles, pero intentaré mostrarles la perspectiva que de hecho me hizo recordar uno de mis ex-jefes, Carlos, quien decia frente a un proceso de licitación al darse cuenta que su tarifa era más alta que la de sus competidores,que era el colmo que los otros competidores estuvieran arruinando el mercado, cosa en la que tenia mucha razón, y que si la empresa contratante decidia que nosotros no seríamos más los que trabajabamos para ellos por el precio, pues que así fuera, por que sus empleados y su trabajo tenian valor (Hoy desde la posición de ex-presidente de esa misma compañia seguro lo reconsideró)
Algo similar nos estaba diciendo Daniel al hablar de su producto, ¿que como lo ibamos a adquirir?, la respuesta, simple, demostrándole que la política de nuestra empresa estaba dispuesta invertir en una herramienta como la suya, que tantas necesidades iba a resolvernos a corto, mediano y largo plazo.
La verdad es que el tiene razón, lo malo es que en estos procesos de negociación donde el tira y afloja es constante, el sentó una posición muy difícil, nuestra empresa debía apostar a una inversión enorme, quizá no inicialmente, el de hecho no estaba solicitando que le fuese pagado inmediatamente el valor de su producto, pero exigía algo, que con la comprensión del primer punto en este post, es bastante difícil de prometer. La promesa que pedía era confirmarle que la política de la organización iba a estar comprometida con la adquisición del producto, en un futuro próximo.
Como les comentaba antes, esto corporativamente hablando iba a sumergir a mi proyecto en el limbo, lastimosamente nadie podia comprometerse con lo que pedia Daniel, menos cuando la necesidad inicial era tan pequeña, aunque tuvieramos la comprensión de que al futuro sería mayor. A hoy mi proyecto sigue en el limbo, buscar otros proveedores después de conocer una alternativa que solucionaría tantos problemas futuros, ha puesto en desventaja a otros y otros más al saberlo no se han ni interesado en competir.
Lo admirable, el punto que quería resaltarles de esta segunda parte es el hecho de que este señor se mantuvo y se ha mantenido firme en su punto hasta ahora, y la verdad que no creo que sea negociable, por las implicaciones técnicas de las que soy consciente, pero sobre todo por su firme covicción y conocimiento de que lo que tiene en sus manos tiene valor, y así mismo su herramienta se convierte en su caballo para librar batallas, en las que si bien puede que gane pocas, hasta ahora como el mismo nos lo dijo, los que se han comprometido, han obtenido la misma reprocidad en el compromiso y además los beneficios prometidos.
No se si haya que buscar culpables, pero respuestas seguro todos buscamos, ahora en mi posición de analista de negocio me confunde un poco alinearme en esas trés verticales, sugiriendo una implementación tecnológica viable, que satisfaga las necesidades de la compañia y que vaya con la política de la organización, que en caso de no existir se volverá una cadena de convencer a todos de que es lo que deberían hacer, y eso, eso si que es un trabajo, duro y largo.
Hoy puedo decir, que ya entiendo por que las grandes empresas parecen en algunos aspectos grandes dinosaurios obsoletos para aquellos que nos acostumbramos a estar actualizados en tecnología, hoy eso tiene más sentido y también mucha más razón.
Sorey García (@soreygarcia)
* Imagen tomada de Microsoft Office Online 2010
domingo, 30 de octubre de 2011
Instalando MojoPortal un CMS ASP.NET para pruebas locales
Saludos
Aprovechando que me encuentro montando MojoPortal, mi CMS (Content Management System) Open Source favorito (Si, si Open Source y en .NET), les dejo aquí las instrucciones para instalarlo y trataré de enseñarles algunas cositas en post futuros.
1. Lo primero es entrar a la página de MojoPortal oficial y descargar el software, se van a encontrar que pueden descargarlo desde CodePlex o que pueden usar el WebInstaller
2. Yo en este caso descargaré desde el CodePlex, ya que el WebInstaller es más fácil y los va llevando. Deben descargar la versión que corresponda con el .NET Framework que soporte su hosting, eso es muy importante. Para saber cual archivo descargar miran el nombre:
mojoportal-2-3-7-0-mssql-net40-deploymentfiles.zip
El nombre indica la base de datos y la versión del framework. Además si desean probar skins adicionales, en la parte inferior hay algunos.
3. Luego proceden a descomprimir los archivos de despliegue y ubicarlos en la ruta de su máquina que deseen.
c) Después de confirmar que se renombró ejecutenlo y dirijanse a la primera pestaña, seleccionando el proveedor para SQL Sever
d) Ingresen los datos de conexión a su base de datos, si todo está bien en la lista de bases de datos verán todas las que tienen instaladas.
e) Hagan el test de conexión
Aprovechando que me encuentro montando MojoPortal, mi CMS (Content Management System) Open Source favorito (Si, si Open Source y en .NET), les dejo aquí las instrucciones para instalarlo y trataré de enseñarles algunas cositas en post futuros.
1. Lo primero es entrar a la página de MojoPortal oficial y descargar el software, se van a encontrar que pueden descargarlo desde CodePlex o que pueden usar el WebInstaller
2. Yo en este caso descargaré desde el CodePlex, ya que el WebInstaller es más fácil y los va llevando. Deben descargar la versión que corresponda con el .NET Framework que soporte su hosting, eso es muy importante. Para saber cual archivo descargar miran el nombre:
mojoportal-2-3-7-0-mssql-net40-deploymentfiles.zip
El nombre indica la base de datos y la versión del framework. Además si desean probar skins adicionales, en la parte inferior hay algunos.
4. Creamos un grupo de aplicaciones en nuestro Internet Information Services
5. Configuramos la carpeta donde descargamos los archivos de despliegue como un sitio web usando el grupo de aplicaciones que configuramos.
6. Asignamos permisos al usuario del grupo de aplicaciones en la carpeta App_Data y Data que están dentro de la carpeta principal de archivos que descargamos. Ten presente que el usuario al que le debes dar permisos es IIS AppPool\"Nombre del Grupo de Aplicaciones"
7. Podemos probar que el sitio quedó bien colocando la url que configuramos en el explorados, debe salir un error de instalación de MojoPortal, ya que no hemos creado nuestra base de datos.
8. Vamos a SQL Server y creamos la base de datos, en mi caso es SQL Server Express R2, así que aún vamos con todo gratuito.
9. Ahora debemos configurar 2 archivos Web.config y user.config.sample. Al segundo lo renombramos y le quitamos la extensión sample, quedando unicamente user.config.
10. Debemos abrir los dos archivos y configurarles la cadena de conexión a la base de datos, dependiendo de la base de datos que vamos a usar, les dejo los ejemplos para SQL Server
Si no saben como obtener esta cadena de conexión, les recomiendo este par de fáciles opciones:
a) Creen un archivo de texto
b) Cambien su extensión a .UDL
c) Después de confirmar que se renombró ejecutenlo y dirijanse a la primera pestaña, seleccionando el proveedor para SQL Sever
d) Ingresen los datos de conexión a su base de datos, si todo está bien en la lista de bases de datos verán todas las que tienen instaladas.
e) Hagan el test de conexión
f) Diríjanse nuevamente a su archivo .udl y ábranlo con un editor de texto simple como Notepad o Notepad ++ que es el que yo uso.
g) Adentro encontrarán el string de conexión que deben configurar.
Otra opción la más fácil y sencilla para mi es usar Visual Studio, en mi caso Visual Studio Web Developer, en el Explorador de Servidores para conectarse a la base de datos y obtener la cadena de conexión de la pestaña de propiedades como ven aquí:
11. Volvemos al explorador usando la url que configuradmos en IIS y si todo salió bien MojoPortal comienza a instalarse.
12. Aquí podemos ver ya a MojoPortal funcionando :)
Espero que les sea de utilidad, si quieren ver un sitio montado con esta herramienta visiten Avanet y todos sus proyectos asociados.
Si tienes problemas con la instalación hay más detalles en el tutorial de instalación del portal oficial
Sorey ;)
jueves, 20 de octubre de 2011
Primeros elementos gráficos para tu aplicación Windows Phone
Saludos
Como ya saben me gusta mucho compartir con ustedes las aventuras que vivo en esto de aprender Windows Phone, pues bien, un poco cansada de enseñarlo y no aplicarlo empecé a hacer ya mi propia aplicación, algo sencilla pero espero usarla para enseñarles cosas y por que no subirla un día al Marketplace.
Hoy quiero entonces hablarles de por donde empecé yo, no se si sea lo primero o lo último que se deba hacer, a mi me gusta eso de trabajar viendo las apps lindas de una vez.
Mi aplicación se llama Viajero Móvil y tiene por objeto permitir que las personas que viajan mucho conserven el historial de sus viáticos en el celular, tediosa tarea que hay que hacer cada que se llega al trabajo a informar los gastos de viaje. Así es como planee que se viera:
Pues bien, tenemos 3 imagenes básicas de todas nuestras aplicaciones, si bien podemos nombrarlas como queramos cambiando la configuración de la aplicación por defecto encontraremos 3 imagenes nombradas por defecto, así que vamos a aprender para que se usan.
La primera imagen es SplashscreenImage.jpg sus dimensiones son 480 x 800. Esta es la primera pantalla que ve el usuario cuando abre nuestra aplicación, por mucho duraría unos 10 segundos así que no es recomendable colocar texto, más bien una buena imagen que de contexto y recordación a nuestra aplicación.
La segunda imagen corresponde al ícono que aparecerá en el Menú General de aplicaciones, por defecto se encuentra nombrada como ApplicationIcon.png y sus dimensiones son 62 x 62. Como ven es muy pequeño y debe llevar un icono que identifique nuestra aplicación, tenemos 2 opciones, colocar un fondo transparente y un icono blanco preferiblemente dejando que el fondo sea el color de "acento" que el usuario tenga seleccionado como tema de su telefono, o bien, colocarle colores propios, quizá asociados a nuestra marca o la imagen reconocida de la aplicación en otros contextos, sin olvidar su pequeño tamaño y que debe ser claro.
La segunda imagen se llama Background.png, sus dimensiones son 173 x 173 y se usa cuándo el usuario decide colocar nuestra aplicación como favorita en la pantalla inicial del teléfono, aquí debemos tener las mismas consideraciones con respecto a los colores, y algo más, típicamente configuraremos el nombre de nuestra aplicación para que aparezca aquí, es el caso en la imagen del "Internet Explorer". El nombre de la aplicación aparecerá en esa posición si nosotros lo configuramos en el Manifiesto (no se impacienten que ya aprenderemos que es). En mi caso, yo quería colocarle mi propio letrero y quite de la configuración el nombre para que no se viera mal, ando investigando si esto es o no recomendado y les cuento, por que todas las aplicaciones que veo en mi móvil hasta el momento lo tienen.
Bien, para contarles un poquito donde voy, mi aplicación iniciará con un panorama, insisto se que voy de a pasitos pero tranquilos ya les enseñaré acerca de Pivots y Panoramas, por el momento les muestro la vista inicial de mi panorama.
Tengo que decirles que la verdad, elegí trabajar con mis propios colores para la aplicación y no usar los colores por defecto, por que actuando como usuario cambiaba los temas del dispositivo y se me hace laborioso lograr que la aplicación se vea bien en todos los temas, así que al ver como funcionaban algunas de las aplicaciones que he descargado opté por tener una gama controlada de colores, recordando que un usuario puede usar fondo blanco y fondo negro y varios colores de acento.
Por el momento es todo, les puedo decir de acuerdo a algunas cosas que he leido acerca de por que puede ser rechazada nuestra aplicación en el App Hub es la estética, así que sabiendo que como desarrolladores no somos muy buenos para el tema, yo recomendaría o buscar un diseñador que nos ayude o bien optar por escenarios controlados o básicos ofrecidos por el mismo Expression Blend.
Les recomiendo ver los recursos de diseño de MSDN para Windows Phone y la colección de íconos de http://thenounproject.com
Espero poder hacerles pronto un video para que vean como va quedando mi aplicación.
Sorey ;)
jueves, 13 de octubre de 2011
Avanet Radio - Windows Phone 7
Ayer estuve con @PavelEspitia y @WarNov en el programa "Somos Móviles" de @Avanet con @mteheran, @ingyesid y @shontauro, los invito a escucharlo y enterarse sobre más detalles de Windows Phone 7
viernes, 30 de septiembre de 2011
Mitos Sobre Windows Phone
Hola a todos,
Como ven, últimamente ando enamorada de mi Windows Phone, cosa que la verdad me alegra, en esto de desarrollar con tecnologías Microsoft siempre he tenido mucho entusiasmo pero no un foco de aplicación y la verdad que desarrollar para Windows Phone se me hace muy divertido, por lo que tomar como foco esto es excelente para mi.
En una de esas buenas nuevas, acabo de recibir la noticia de que Microsoft me invita al curso "Train the Trainers in WP7" espero estar aprendiendo muchísimas cosas y enseñarlas como a mi me gusta, este es otros de esos bonitos regalos que he recibido de parte de Microsoft, por ser MCS (Microsoft Community Specialist) por trabajar con comunidades y hacer difusión al uso de sus tecnologías, y bueno en esa línea escribo este post, ya que desde que compré mi Windows Phone, he recibido comentarios de cada persona que lo ve o cada desarrollador compañero mío que sigue con la vieja imagen de Microsoft.
Bien, para desmitificar Windows Phone, toca desmitificar un poco a Microsoft, antes muchos de nosotros luchabamos con otros desarrolladores por defender la imagen de un Microsoft cerrado y lejano que no parecía escuchar mucho, evidentemente eso ha cambiado con el tiempo y uno solo de sus reflejos es Windows Phone, así empiezo con los mitos:
1. No, no es un iPhone: Windows Phone es auténtico, su estilo gráfico, limpio y fresco, pero sobre todo bastante usable e intuitivo, no copia de nadie, y genera una excelente experiencia de usuario, y por cierto, es mucho mejor que el actual iPhone, pero un dueño de iPhone jamás se atreverá a decírtelo. Entre otras es como dicen "para dummies" todas las opciones incluso las de configuración estan cerca y sin mucha navegación ni tantos lios.
2. Ser desarrollador de WP7 es costoso: Pocos se preocupan por informarse cuánto han cambiado las cosas los últimos tiempos, y que eso de desarrollar con Microsoft siempre es costoso no es cierto y con Windows Phone el tema es mucho menos cierto. Todas las herramientas de desarrollo para Windows Phone, son absolutamente gratuitas, desde el IDE de desarrollo hasta Expressión Blend que es una maravillosa herramienta para trabajar mano a mano con los diseñadores. Así que ya no hay excusa, si tienes una computadora con Windows puedes desarrollar perfectamente aplicaciones para Windows Phone sin pagar un centavo por las herramientas de desarrollo. Qué para subir las aplicaciones al APPHUB hay que pagar? Si claro, cosa que hay que hacer tambien en otras tiendas de aplicaciones, con la ventaja de que aquí, si eres un estudiante puedes tener el beneficio de subir aplicaciones absolutamente gratis.
3. Windows Phone 7 va muy lento: Evidentemente esto es un problema de pais y no de plataforma, pero hay gente que tiene la mania de ponerle a Microsoft todas las culpas que se pueda. Escuché decir a alguien que Nokia que es ahora el aliado de Microsoft no ha podido lanzar su primer equipo con Windows Phone. ¿Yo que sé? De eso no se nada, pero evidentemente buenas sorpresas deben venir en camino y por otro lado Nokia no es el único proveedor de celulares del planeta.
4. La tienda de aplicaciones no es tan buena, por que no hay apps gratis y las que hay deben ser costosas: Este es un comentario de alguien que evidentemente jamás a usado un Windows Phone y ni conoce el Market Place, evidentemente a la fecha hay menos aplicaciones que en otras tiendas, pero Microsoft está apostando bastante a que los desarrolladores aprendamos y nos aventuremos a crear aplicaciones. Por otro lado, yo tengo puras aplicaciones gratis que además me son muy útiles y me divierten, pero entre otras el teléfono por si solo con Windows Phone Mango es un mundo en si donde es maravilloso tener todo lo básico que necesitas, por ejemplo estar pendiente de tu Facebook, no solo tu muro, si no para tener facilmente cualquier foto de facebook en tu celular, además tener tus correos de Gmail, Hotmail y corporativos, tener Office y Excel a la mano y poder subir tus documentos a Skydrive o un sitio de Sharepoint es lo màximo.
El tema del costo es màs un esquema que se ha venido popularizando con las tiendas de aplicaciones, así que bueno poner apps gratuitas, o ponerlas a un precio asequible para ser popular es más un tema del desarrollador del producto, el MarketPlace ahí está y es la puerta al mundo para vender nuestras aplicaciones.
Aquí van un par de mitos generales sobre Microsoft
5. Microsoft es cerrado: Esto ha cambiado muchisimo y diría yo, no es que haya cambiado, más bien, ahora las comunidades y colaboraciones de Microsoft tienen mayor visibilidad, esa parte siento que si la entendieron, hoy es más fácil, pertenecer, crear o informarse a través de una comunidad que promueva el uso de las tecnologías Microsoft, incluso es bastante fácil comunicarse con la gente detrás de estas comunidades o personas como Student Partners o Evangelizadores, definitivamente es un excelente cambio proyectarse en apoyar a las comunidades e impulsarlas a replicar el mensaje.
6. No puedes hacer Software Libre desarrollando con herramientas Microsoft: Esta es una de esas discusiones que más me molesta, por que evidencia la falta de conocimiento y sobre todo las ganas de discutir por discutir o de hablar de lo que no se sabe. Hacer software libre no tiene que ver con la herramienta con la que lo construyes necesariamente, tiene que ver principalmente con a quien y con que libertades expones el trabajo que realizas, es así como muchas personas que comparten los ideales del software libre pero cuyo trabajo en con herramientas Microsoft, regalan su trabajo publicándolo en sitios como CodePlex, el mismo Microsoft a través del Web Installer promueve el uso de muchas herramientas que han sido construidas con .NET y que son ofrecidas no solo de forma gratuita a la comunidad, si no que su código puesto a disposición además de hacer trabajo en equipo para seguir creciendo estas herramientas.
Nos vemos la próxima.
Sorey ;)
Bien, para desmitificar Windows Phone, toca desmitificar un poco a Microsoft, antes muchos de nosotros luchabamos con otros desarrolladores por defender la imagen de un Microsoft cerrado y lejano que no parecía escuchar mucho, evidentemente eso ha cambiado con el tiempo y uno solo de sus reflejos es Windows Phone, así empiezo con los mitos:
1. No, no es un iPhone: Windows Phone es auténtico, su estilo gráfico, limpio y fresco, pero sobre todo bastante usable e intuitivo, no copia de nadie, y genera una excelente experiencia de usuario, y por cierto, es mucho mejor que el actual iPhone, pero un dueño de iPhone jamás se atreverá a decírtelo. Entre otras es como dicen "para dummies" todas las opciones incluso las de configuración estan cerca y sin mucha navegación ni tantos lios.
2. Ser desarrollador de WP7 es costoso: Pocos se preocupan por informarse cuánto han cambiado las cosas los últimos tiempos, y que eso de desarrollar con Microsoft siempre es costoso no es cierto y con Windows Phone el tema es mucho menos cierto. Todas las herramientas de desarrollo para Windows Phone, son absolutamente gratuitas, desde el IDE de desarrollo hasta Expressión Blend que es una maravillosa herramienta para trabajar mano a mano con los diseñadores. Así que ya no hay excusa, si tienes una computadora con Windows puedes desarrollar perfectamente aplicaciones para Windows Phone sin pagar un centavo por las herramientas de desarrollo. Qué para subir las aplicaciones al APPHUB hay que pagar? Si claro, cosa que hay que hacer tambien en otras tiendas de aplicaciones, con la ventaja de que aquí, si eres un estudiante puedes tener el beneficio de subir aplicaciones absolutamente gratis.
3. Windows Phone 7 va muy lento: Evidentemente esto es un problema de pais y no de plataforma, pero hay gente que tiene la mania de ponerle a Microsoft todas las culpas que se pueda. Escuché decir a alguien que Nokia que es ahora el aliado de Microsoft no ha podido lanzar su primer equipo con Windows Phone. ¿Yo que sé? De eso no se nada, pero evidentemente buenas sorpresas deben venir en camino y por otro lado Nokia no es el único proveedor de celulares del planeta.
4. La tienda de aplicaciones no es tan buena, por que no hay apps gratis y las que hay deben ser costosas: Este es un comentario de alguien que evidentemente jamás a usado un Windows Phone y ni conoce el Market Place, evidentemente a la fecha hay menos aplicaciones que en otras tiendas, pero Microsoft está apostando bastante a que los desarrolladores aprendamos y nos aventuremos a crear aplicaciones. Por otro lado, yo tengo puras aplicaciones gratis que además me son muy útiles y me divierten, pero entre otras el teléfono por si solo con Windows Phone Mango es un mundo en si donde es maravilloso tener todo lo básico que necesitas, por ejemplo estar pendiente de tu Facebook, no solo tu muro, si no para tener facilmente cualquier foto de facebook en tu celular, además tener tus correos de Gmail, Hotmail y corporativos, tener Office y Excel a la mano y poder subir tus documentos a Skydrive o un sitio de Sharepoint es lo màximo.
El tema del costo es màs un esquema que se ha venido popularizando con las tiendas de aplicaciones, así que bueno poner apps gratuitas, o ponerlas a un precio asequible para ser popular es más un tema del desarrollador del producto, el MarketPlace ahí está y es la puerta al mundo para vender nuestras aplicaciones.
Aquí van un par de mitos generales sobre Microsoft
5. Microsoft es cerrado: Esto ha cambiado muchisimo y diría yo, no es que haya cambiado, más bien, ahora las comunidades y colaboraciones de Microsoft tienen mayor visibilidad, esa parte siento que si la entendieron, hoy es más fácil, pertenecer, crear o informarse a través de una comunidad que promueva el uso de las tecnologías Microsoft, incluso es bastante fácil comunicarse con la gente detrás de estas comunidades o personas como Student Partners o Evangelizadores, definitivamente es un excelente cambio proyectarse en apoyar a las comunidades e impulsarlas a replicar el mensaje.
6. No puedes hacer Software Libre desarrollando con herramientas Microsoft: Esta es una de esas discusiones que más me molesta, por que evidencia la falta de conocimiento y sobre todo las ganas de discutir por discutir o de hablar de lo que no se sabe. Hacer software libre no tiene que ver con la herramienta con la que lo construyes necesariamente, tiene que ver principalmente con a quien y con que libertades expones el trabajo que realizas, es así como muchas personas que comparten los ideales del software libre pero cuyo trabajo en con herramientas Microsoft, regalan su trabajo publicándolo en sitios como CodePlex, el mismo Microsoft a través del Web Installer promueve el uso de muchas herramientas que han sido construidas con .NET y que son ofrecidas no solo de forma gratuita a la comunidad, si no que su código puesto a disposición además de hacer trabajo en equipo para seguir creciendo estas herramientas.
Bien pues, cualquiera podrá tacharme de fanática de Microsoft, en efecto tengo una alta inclinación hacia sus herramientas pero quienes me conocen de verdad saben que soy bastante Open Mind, y además que me encanta la ingeniería de software y la arquitectura de software, pero las cosas hay que decirlas como son y dejar de criticar por criticar, más bien ver la parte positiva de las cosas y sacarle provecho, que finalmente es un beneficio para cualquiera y está ahí al alcance de un click, muchas veces.
Nos vemos la próxima.
Sorey ;)
lunes, 26 de septiembre de 2011
Proceso oficial de actualización a Windows Phone Mango - Parte 2 (5)
IMPORTANTE: Este proceso es para actualizar la versión del equipo cuando eres un desarrollador, si eres usuario, solo debes realizar los pasos del 12 al 19 :). Les dejo el anuncio de Microsoft el 27 de Septiembre notificando la liberación de Windows Phone 7.5 (Mango) al mundo.
Bueno, vamos a continuar con la larga aventura de actualización a Mango, recuerden leer la primera parte.
1. Lo primero es que si ya teniamos instaladas las Beta 2 de Mango es necesario actualizarnos al RC (Release Candidate)
2. Pero por favor no olviden como yo, que no se actualiza, toca desinstalar el Beta 2 y volver a instalar
3. Mientras tanto he aquí los archivos que deben bajar desde Connect
4. El primero y ya advertido, un documento de 15 páginas que esta lleno de más advertencias e indicaciones, entre ellas que nuestro móvil debe estar desbloqueado para desarrollador, que debemos tener el último cliente de Zune, que nuestro equipo debe tener una de estas versiones 7355 (7.0.7355.0, 7.0.7389.0, 7.0.7390.0, or 7.0.7392.0) y que antes de empezar deberíamos hacer Backup, aunque según leo el Zune hace un proceso de respaldo antes de iniciar la actualización.
5. Mientras tanto está terminando la actualización de las Developer Tools a RC.
6. Bien, al terminar de instalar si hemos hecho todo bien hasta el momento, es hora de iniciar la actualización, lo primero es desconectar el equipo y desinstalar el cliente de Zune que tengamos e instalar el que se encuentra en los archivos que descargamos de Connect >> MangoB2Refresh_ZuneClient.zip
7. Luego conectamos el equipo y nos aseguramos de cerrar el Zune, e iniciamos la instalación de MangoB2Refresh_UpdateWP.zip, es muy importante que lean las instrucciones del archivo que se anexa si es que ya han realizado actualizaciones antes, si como yo es la primera vez, con lo que voy haciendo esta bien.
8. Recuerden con el equipo conectado y el Zune cerrado iniciamos el tercer paquete MangoB2-DevRetailUpdate. En la primera ventana aceptamos otra vez todas las responsabilidades de lo que suceda al equipo ya que leimos los términos en Connect.
9. Ahora empieza un pequeño proceso de respaldo, el cual no duró 10 minutos
10. Según las instrucciones cerramos esta aplicación y procedemos a abrir Zune nuevamente. Aquí el teléfono debe haber despertado y quitado la imagen de prohibido desconectar.
11. Vamos a la ruta donde la herramienta dejo nuestro respaldo y lo copiamos a otro lugar. En mi caso la ruta es C:\Users\sgarcia\AppData\Local\Microsoft\Windows Phone Update. Si perdemos este respaldo no podremos recuperar el estado de fabrica del teléfono.
12. Luego siguiendo las instrucciones vamos a Zune a configuración y en la opción teléfono seleccionamos actualizar para que inicie la busque de actualizaciones.
13. A mi me ocurrio este error...
14. Desconecte y reinicie el Zune y funcionó
15. Al presionar el botón Actualizar, comienza el proceso
16. Aquí confirmé y por alguna razón volvió a instalar el Zune, como si hubiese una actualización pendiente, según el manual esto no debia ocurrir, si no empezar la actualización del teléfono
17. Siguiendo las instrucciones en esta ventana, desconectamos el móvil que sigue vivo hasta el momento.
18. Después de esta actualización volví al punto 15 y ahí si continuó la instalación
19. Y si! después de aproximadamente un hora y un poco más tengo Windows Phone Mango :)
20. Como último paso abrimos el Windows Phone Registration Tool para registrar nuevamente nuestro móvil para desarrollo.
Y eso es todo, espero que este pequeño tutorial los acompañe en el proceso y no sufran tanto como yo, todo sale muy bien.
Sorey ;)
Suscribirse a:
Entradas (Atom)