domingo, 4 de agosto de 2013

Manifiesto de la arquitectura de software

Por estos días comentaba con muchas personas lo difícil de llevar el mensaje de la Ingeniería de Software, y hoy al iniciar por 6 año consecutivo mis clases de Ingeniería de Software en la universidad me sentí particularmente mentirosa.

Hoy, hablar del "como deberían ser las cosas" me duele particularmente, ya que a pesar de los esfuerzos de muchisimas personas por ello, siento que sencillamente la "actual" naturaleza humana tiende a desvirtuar todo aquello que le resulta particularmente dificil o que requiere un poco más esfuerzo.

Podría hablar montones sobre los sentimientos que tengo al respecto de la Ingeniería de Software, de como amé mi carrera cuando de verdad la conocí y de cuan triste me hace sentir la manera como día a día pierde valor y se vuelve simple improvisación, (como antes dirán muchos), el problema de hoy, es que la improvisación es publica, abierta y orgullosamente oficial, y de eso no quiero hablar.

Les comparto esto que me mostró mi amigo Hernan Guzmán, acerca de los dolores que compartirmos juntos y que refleja tan perfectamente el manifiesto de Simon Brown.

Manifiesto de la arquitectura de software

  1. Crear una arquitectura inicial sobre hacer todo o nada en absoluto
  2. Diseñar requisitos no funcionales sobre tratar de añadirlos al final del proyecto
  3. Evaluar las tecnologías sobre elegirlo solo porque se ve bien en tu hoja de vida (currículo)
  4. Experimentar (hacer pruebas de concepto) sobre guardar la esperanza de que el diseño va a funcionar
  5. Codificar sobre interminables discusiones, reuniones y diagramas
  6. Colaborar sobre dar ordenes en una dictadura
  7. Participar sobre huir y dejar que el equipo lídie con los problemas
  8. Entrenar a los miembros del equipo sobre acariciar tu propio ego
  9. Pragmatismo sobre perfección
  10. Problemas reales sobre auto-estimulación intelectual
  11. Simplicidad y sentido común sobre ideas complejas y enrevesadas
  12. Documentación de arquitectura corto y útil que refleja la realidad sobre enciclopedias que nadie lee, entiende o le importa.
Fuente: http://www.codingthearchitecture.com/2009/11/02/software_architecture_manifesto.html

martes, 16 de julio de 2013

Aplicación móvil de #BarCampMed5 para Windows Phone

Como siempre por esta epoca del año, mi blog se congela, pero la razón es bastante especial, empieza la preparación del BarCamp Medellín del cual hago parte activamente como co-organizadora.

Pues bien, una de mis variadas actividades es construir la aplicación Movil versión para Windows Phone, la actualización recién va hacia la tienda pero como en ocasiones anteriores me gusta la idea de compartir el código a través de mi Github, no es de lo más lindo pero seguro y sirve para aprender algo o para usarla en otros BarCamps.


Saludos y hasta la próxima.

Sorey

lunes, 1 de julio de 2013

MVP Windows Phone Development

Hola a todos,

Quisiera compartir con ustedes que el día de hoy fuí reconocida como MVP Windows Phone Development, noticia que alegró mi día y me anima muchísimo a continuar adelante.

Mirado atrás, tengo bastantes recuerdos de como se fué construyendo esta meta en mi mente, empezando desde conocer a varios MVP que me inspiraron cuando recién era una adolescente, al apoyo recibido por ya casi 3 años de parte de mi mentor en todo esto, Walter Novoa, a quien agradezco profundamente el haberme ayudado a enfocar mis esfuerzos de manera coherente y trabajar por ellos con paciencia hasta lograrlo.

Son muchas las personas a las que tengo que agradecer, por creer en mi, por apoyar mi trabajo, por trabajar conmigo, y por resultarme toda una inspiración y hasta un reto.

En primer lugar quisiera agradecer a todos los miembros de mi comunidad, Avanet, por aportar con su paciencia, tolerancia y apoyo, por manejar tantas opiniones que pretenden desvirtuar una labor esencialmente agnóstica en lo que tiene que ver con las diferentes tecnologías de desarrollo, pero que inevitablemente suscita comentarios debido a mis metas personales. A Hernán Guzmán y Khriztian Moreno, gracias por ser quienes en particular en las actividades de Microsoft, siempre están conmigo.

Además no quisiera dejar de mencionar a empleados y colaboradores de Microsoft y a los MVPs que cada día son un soporte y en muchas ocasiones una inspiración para iniciar o continuar adelante: Josue Yeray, Jorge Gamba, Juan Carlos Ruiz, Julio Avellaneda, Roberto Alvarado, Yohis, Sandra Marín, Miguel Mendoza, Fernando García Loera, Edwin Torres, Fredy Angarita y Willy Marroquín.

También quisiera dar las gracias a Daniela Ambrocio y Erika Vilches, por estar allí y devolverme las ganas de estar, ser y permanecer.

Para finalizar gracias a cada uno de los que visita mi blog o ha participado en mis conferencias o talleres, por enviarme sus comentarios y respaldar mi trabajo, pero principalmente por ser la razón de todo esto, espero que sigan contando conmigo y trabajar juntos por continuar creciendo la comunidad de desarrolladores Windows Phone :)

Sorey García 

domingo, 23 de junio de 2013

Desarrollo de Software: Del absurdo absoluto a la validez de lo relativo

Hace un tiempo mientras estudiaba mi especialización en desarrollo de software (mal entendida por muchos como solo programación), encontré entre mis docentes alguien realmente valioso, para mi lástima, tan solo nos dió una sesión pues justo para esa cohorte no podría ser docente, sin embargo 2 horas escuchándolo lo dejaron clavado en mi mente y desde entonces llevo sus enseñanzas en cada clase a mis estudiantes. Después de conocer a Luis Fernando Londoño considero que aprendí la gran diferencia de marcar la vida de alguien siendo docente, hoy no recuerdo muchos de los nombres de docentes que vi por 4 meses, sin embargo a él no lo olvido, ahora menos, después de conocer parte de historia. Una de las frases que más uso para mencionarlo es acerca de los procesos en la ingeniería de software:

"El tema que tiene que ver con procesos es como el habito de comer, uno puede comer de dos maneras, bien o mal en ultima instancia el fin para muchas personas es llenarse… Uno puede comer comida sana o comida chatarra y vive, puede vivir con mas dificultades pero vive,… Sin embargo el que se alimenta bien tiene más posibilidades de sobrevivir"

Hoy después de 4 años tengo la oportunidad de darle a mi comunidad el regalo de escuchar de su voz y experienciencia, en carne propia como lo llamo yo, a un hombre que tiene mucho que decir, desde el conocimiento, la razón, la lucha y el corazón. Les comparto el resumen de su conferencia que será el regalo de aniversario de un sueño que lleva 4 años creciendo y siendo, Avanet.

Desarrollo de Software: Del absurdo absoluto a la validez de lo relativo
Por Luis Fernando Londoño 

No es afortunado concebir el cómo desarrollar software como un absoluto, no podemos permitir que los intereses de falsos evangelizadores, nos conviertan en débiles seguidores. 
no se puede guiar una industria en proceso de evolución a través del establecimiento de dogmas que se van haciendo paganos y toman una dinámica mercantilista que termina en establecer formas inadecuadas de hacer de lo complejo algo simple y de una disciplina como es la ingeniería de software un objeto de burla para los que ignoran su verdadera esencia,

Las múltiples alternativas de cómo hacer buen software, están basadas en precisamente que existen múltiples variables que hacen relativo ese cómo hacerlo bien, como hacer que un problema complejo se resuelva con un método simple, que no es precisamente la prueba y el error, requiere formas dinámicas y adaptables al entorno en el ‘que’ y el ‘para que’ se va a dar solución a un problema o aprovechar una oportunidad que implica desarrollar software.

Más allá de debatir que es mejor y querer imponer posiciones dogmáticas que confunden a los ilusos, les hacen creer que todo lo que brilla es oro y que solo existe una única forma de hacerlo bien, necesitamos precisar que no hay tal principio absoluto de lo ágil o lo robusto, el único principio cierto es que se requiere capacidades de adaptabilidad de nuestros equipos de trabajo que desarrollan software: “Vacía tu mente, se amorfo, moldeable, como el agua. Si pones agua en una taza se convierte en la taza. Si pones agua en una botella se convierte en la botella. Si la pones en una tetera se convierte en la tetera. El agua puede fluir o puede golpear. Sé agua amigo mío” (Bruce Lee) 

No queremos debatir, solo compartir conceptos soportados por la evidencia que se ha venido desarrollando a partir de la experimentación en ingeniería de software, no pretendemos evangelizar solo aportar con el máximo respeto por los que en silencio aportan.

El evento se realizó el 25 de Junio de 2013 a las 8 P.M., te invitamos a ver el Hangout de Aniversario de la Comunidad Avanet y escuchar ideas que te ayudarán a poner los pies en la tierra y a formar tu propio criterio.



Sorey García

lunes, 3 de junio de 2013

Movimiento de Responsabilidad Social Universitaria

Hace unos días después de recibir la invitación de nuestros amigos Ricardo Colusso y Fernando Claverino a realizar esta actividad, empezamos a invitar a las personas a asistir al primer encuentro del Movimiento RSU en Medellín.

Imaginar la actividad era bueno pero vivirla aun mejor, la cantidad de aprendizajes alrededor de ella, te enseñan cosas a nivel individual y dibujan frente a ti el por que del camino que ha llevado por tanto tiempo nuestra sociedad, y nos enfrenta al hecho de ¿qué estamos haciendo para que todo esto sea diferente?




Agradecemos a Fernando y Ricardo por sus enseñanzas y esperamos seguir difundiendo este mensaje en la ciudad y les invitamos a convertirse en facilitadores del movimiento tambien en su ciudad.

Sorey

domingo, 12 de mayo de 2013

Diagramas de despliegue en las paredes

Continuando con mis post sobre los Workshops de Ingeniería de Software basados en el modelo 4 + 1 vista, veamos uno de los posibles diagramas de la Vista Fisica, el diagrama de despligue.

Este es uno de los diagramas más fáciles de realizar, la razón es sencilla, a todos nos es más fácil mapear el universo fisico con las ideas. En este caso la vista física pretende mostrar cuales con las máquinas, vías de comunicación, protocolos y principales componentes involucrados en un sistema, sea por que nos comunicamos con o través de ellos o por que dependemos de ellos en alguna forma.

Es importante como ya les habia nombrado definir una notación con los elementos existentes.

Para un diagrama de despliegue básico se esperan algunos materiales básicos, (Recuerden que sean elementos que no arruinen las paredes). Estos puede ser:

Servidores, maquinas y dispositivos se pueden hacer con papeles de colores grandes, esto por que dentro de ellos se colocarán más elementos. Para dar gráficamente un orden, se pueden hacer los servidores de un color, lo mismo las maquinas y otro más para los dispositivos moviles.

En ocasiones cuando no se conoce como es el despliegue de un lugar desde el que se consume datos, se pueden recortar un papel en forma de nube, esta fue una idea de uno de los grupos con que trabajé y fue una buena forma de ver como los equipos se autogestionaban para comprender mejor el entorno del problema y explicarlo a los demás.

Ahora bien, dentro de las máquinas fisicas se despliegan 2 tipos de elementos, componentes que representan las aplicaciones instaladas y los servicios o tareas en background. Como sabemos muchas veces algunos componentes para poder ser usados estan instalados dentro de contenedores o aplicaciones que les sirven como entornos, es el caso de las aplicaciones web que necesitan de IIS, Tomcat y otros servidores de aplicaciones para poder ser servidas, o incluso de las bases de datos que necesitan un motor donde ser instaladas. Esto es conocido como los entornos de ejecución, para reflejar esto se pueden usar fichas bibligráficas o cortar los papeles de colores para que tengan un tamaño intermedio, dentro de los ambientes de ejecución colocamos los componentes que necesitamos usar o que vamos a construir en nuestro proyecto.

Otro elemento son las cintas de enmascarar de al menos 2 colores, una de ella se usa para las vias de comunicación entre los servidores y otra se usa para crear los boundaries, limites o fronteras (LAN, WAN etc). En la cinta que define las visas de comunicación se deben pegar el protocolo que usa la comunicación y se debe definir claramente la cardinalidad para establecer, quien consume datos de quien.

Estar atento de que se respeten las notaciones es importante, también tener conocimientos técnicos de algunas cosas para saber representar las diferentes técnologías. El ejercicio puede ser apoyado por quienes más conocen sobre infraestructura en el taller, sin embargo otro de los retos importantes como en todo el workshop es lograr que quienes definen esta vista esten en comunicación y validación constante con las Vistas de Procesos y las Vistas de Implementación. Recuerden que para este punto, todos los integrantes del workshop deben estar girando cada 15 minutos y llevando sus ideas de un grupo a otro.

Los resultados son muy bonitos, lo más bonito es como se encariñan con este diagrama al ser uno de los que más bien queda.

Les repito como antes, si bien el ejercicio no es absolutamente ortodoxo con respecto a las notaciones y de hecho no pretende reemplazar en nada a UML por ejemplo, es una manera de introducir a las personas en la experiencia de elegir una infraestructura, generar un diálogo acerca no solo de los temas técnicos si no de cuando se define algo cual es el impacto económico, un ejemplo de esto es cuando se definen servidores de backup, que son bastante fáciles de poner en un diagrama pero que implican gran cantidad de costos adicionales, de esto se debe encargar quien dirige el Workshop.

Por supuesto siempre quedará la idea de cual es la manera formal de hacerlo y uno de ellos es estudiar las notaciones propuestas en UML.

Espero que esta idea les resulte de utilidad. Hasta la próxima vista.

Saludos, Sorey.