Desarrollo Software Futuro (+5 años)

Desarrollo Software Futuro (+5 años)

Introducción

En este post, me voy a poner la gorra de Nostradamus, y mi bola de cristal..virtual claro, pensar un poco como será el desarrollo de software en el futuro. ¿Y para qué? el futuro vendrá cuando vendrá y cuando venga ya no será futuro sino presente. Pero creo que si levantamos la vista y miramos a años vista sobre el futuro desarrollo, lo mismo encontramos algo que nos interese entrar en ese campo y nos llene más, o algo más practico, estar mejor posicionado para encontrar trabajo en el futuro.

Nos montamos en el Delorean, fijamos año 2020, y en el año 2020, si el de arriba quiere, veremos cuan errados estábamos, aunque lo mismo alguna cosa ya existe.

2020

- Electrodomesticos:

Ya la tv y el telefono son smart. Y por inercia, la lavadora, frigorífico y lavavajillas también serán smart. Es decir, llevaran androi. Tienen funciones ya muy avanzadas, como por ejemplo, un modelo de lavavajillas que ví que media la suciedad del agua que pasaba por abajo para ajustar los tiempos, y ahorrar agua.
Pero de momento, estos programas vienen de fábrica. Pero lo mismo, en el 2020, tendrán un puerto USB, una pantalla táctil, y poder instalar el programa de lavadora que te has programado o te has descargado. Aunque según escribo esto, veo que ya hay una que va por ese camino. Lo que pasa que el software es el de la casa,..claro.

Esto me lleva a pensar, que un salto de gigante que al igual que hubo una explosión de ofertas de desarrolladores para smart phones, el día que exista otro dispositivo distinto al smart phone y que contenga un sistema operativo, habrá otra explosión de ofertas de empleo para eso tipo.

¿Y que dispositivos podrían ser? Drones

- Drones

Los drones cuando se ven por la tv, parece que son juguetes para mayores, pero no. Solo basta echar un vistazo a lo siguiente:

- Global Hawk: aquí si que se puede ver su tamaño en comparativa.

https://www.youtube.com/watch?v=IiGnaqouUfA

- Drone para la infanteria: con este casi si que pudiera parecer un juguete..

https://www.youtube.com/watch?v=X0xI4EbKUXs

- Estudiantes de la EETAC y la ETSEIAT construyen un 'drone' para salvar rinocerontes y elefantes de la caza furtiva en África

http://www.upc.edu/saladepremsa/al-dia/mes-noticies/estudiantes-de-la-upc-construyen-un-drone-para-salvar-rinocerontes-y-elefantes-de-la-caza-furtiva-en-africa

- Drones construyendo colaborativamente:
https://www.youtube.com/watch?v=xvN9Ri1GmuY



Y eso es solo un ejemplo, pero se puede aplicar muchas cosas. Por ejemplo:
- Vigilar los bosques españoles (y del Mundo vale..). Unos drones con camaras termicas, detectores de humo, y esos drones colaborando entre sí.

¿Qué los bosques son muy amplios? se le puede meter un mini motor a reacción

- Ayudar en buscar desaparecidos en montañas. Otra vez, drones colaborativos.

- Ayudar en vigilancia de costas.

¿Pero como podría afectar en el desarrollo de sofware?

El día que estos aparatos tengan un sistema operativo como Androi para los smart phones, habrá empresas que buscarán programadores para desarrollar aplicaciones para drones. Un ejemplo, hace tiempo trabaje en un GIS, donde este GIS, con las fotos aéreas recibidas de los campos de los olivos, contaba automáticamente los olivos. Pero estas fotos eran realizadas desde aviones, claro, pero..¿y un dron que se dedique ha hacer ortofotos de una región? más barato!.


Por lo que he visto, hay de momento:
- AR.Drone: su sdk para manejar el drone está en linux y windows. Su alcanze está limitado al alcanze de la wifi, pero para experimentar puede estar muy bien.


- Airware: parece que apostando por crear un S.O. con todos los dispositivos que se puedan conectar a su S.O. (en vez de teclados, cámaras, sensores,...) y ofreciendo una API para desarrollar aplicaciones a las necesidades del cliente.

Creo que está dando sus primeros pasos, y poco a poco se están viendo las posibilidades de los drones. Pero cuando sea relativamente fácil, programar sobre el S.O. que lleva el dron y probar. Habrá más proyectos con drones. Supongo que tendrán que ofrecer de alguna forma el S.O. gratuito  para que más desarrollen la investigen, prueben y programen..adquieran experiencia sobre ella, y luego, dejar pagar a la empresas por ello.

Realidad Virtual

Allá por los años 90s (me encanto la película "El cortador de césped", estaba en auge la realidad virtual , que luego cayo casi en el olvido, pero de nuevo se empieza a mirar a ella. Yo creo que por que se ha reducido el coste de los dispositivos.

Ya en otro blog que tengo, escribí (allá por el año 2005) varios post sobre como la realidad virtual podría ser usada para terapias de reducción de la ansiedad y del miedo. Y al reducir el coste de los dispositivos, y poder usarse en un ordenador personal, se podría instalar en cualquier consulta.
Otras aplicaciones como ayudar a hablar en público.

Para quién ya quiera picar algo:

Virtual Reality in the .Net Framework, Part 1:

Conclusión

Pero..¿que habrá en infojobs en el 2020? 

- Habrá más ofertas de desarrolladores para androi, ya que no serán solo los smartphones y las tables quién use este sistema operativo, sino que habrá otros dispositivos que lo usen.

- Habrá más desarrolladores que trabajen como freelances. Creo que las causas pueden ser evitar los atascos, trabajar desde casa, ser uno su propio jefe, ...etc, etc,..y lo mismo tiene éxito por que los clientes al contratar la persona, saben que esa persona va a desarrollar el trabajo. Una de las pegas que veo es que el cliente tema que al cabo del tiempo, no tendrá soporte, pero ahí están los contratos...

- Habrá más profesores de informática, o mejor dicho, profesionales que se pasen a la enseñanza, ya que demandará profesores especializados en diferencias campos del desarrollo de software.

happy coding...

Félix Romo

felix.romo.sanchezseco@gmail.com

Analisis de Rendimiento

Analisis de Rendimiento

Introducción

Empiezas un proyecto y empiezas a aplicar todo lo que has aprendido en la universidad y en los libros, blogs, consejos que has ido leyendo e intentar aplicar toda la ingeniera del software al nuevo desarrollo. Te creas tus diagramas de clases, secuencia, estás un minutos o más pensando que nombre dar a una clase, y las relaciones entre ellas.

Un mes despues..

Han surgido nuevos requisitos que estaban ocultos, otros se han derivado en otros requisitos y los jefes quieren ver resultados.  ¿Solucion? tiras lineas de código a casco porro, y a usar el copy&paste más que nunca (esto ya debería ser una señal de aviso..que algo no va bien). Sacas una versión, y los testeadores y usuarios: "esto parece que va más lento.."

Efectivamente, se ha dedicado el tiempo a tirar lineas de código y a sacar funcionalidad, sin reparar en el rendimiento de la aplicación.

Creo que durante todas las fases del desarrollo hay que parar de tirar lineas de código y mirar como va el rendimiento de la aplicación. El Visual Studio ofrece mucha información, que la verdad, uno casi se pierde entre tanta información. Y con este post, intentaré que me sirva para tener una especie de protocolo para cuando quiere hacer dicho analisis seguir esos pasos y hacerlo de la manera más efectiva. También, entender un poco más el tema del rendimiento.

Para ver el tema de rendimiento, me he creado un pequeño programa que genera 1000 primitivas, y según está generando las primitivas de la lotería, va dibujando la frecuencia de cada numero en la ventana. Y final de la simulación, se ve una casi distribución uniforme.

Así uno puede ver si tienes mucho histórico sobre las primitivas, la probabilidad se parece y si una tiene poco histórico, casi no tienes patrones para hacer cálculos y jugar a la Primitiva. En fin, en su día incorpore a un programa a la posición del Sol y de la Luna por los efectos gravitacionales sobre las bolas del bombo, pero nada...las variables a tomar en cuenta sin inmensas..pero bueno, nos entretenemos pensando en como...pero bueno, vamos al grano...

Variables

Hay muchas páginas que hablan sobre las variables, a si que, no voy enumerarlas, solo voy a comentar lo que me parecen y así, entenderlas mejor.

El método  public List<Primitive> Generate(int numberOfPrimis, onPrimitiveGenerated handle) es el método donde empieza a ejecutar todo. Y este método tarda alrededor de 7.062 milisegundos.

Lanzamos el profiler en modo "intrumentalización".

Paso 1:
Ponemos Current view a "Funtions"

Paso 2:
Ordenamos los resultados por la la columna "Funtion Name". Aquí algunos dirán por alguna columna donde están los resultados de los tiempos, pero como me quiero centrar solo en los tiempos de las funciones que he creado, lo ordeno por los nombres (seguro que hay una manera de filtrar, pero aún la desconozco).

Paso 3:

Buscamos la función que tenga el tiempo "Elapsed Inclusive Time", y este tiempo es el de la función
primiLotto.Kernel.PrimitivesGenerator.Generate(int32,class primiLotto.Kernel.onPrimitiveGenerated)

y sus tiempos en el profiler es de:

6.991,38(Elapsed Time Inclusive)

que, casualmente es muy parecido a con el otro tiempo calculado por el Stopwatch de 7062mseg.

Entonces, ya tenemos una correlacion. El "Elapsed Time Inclusive" mide el tiempo dentro de una función y también el tiempo de las funciones a las que llama. Es decir, el tiempo total, desde que se inicia hasta que termina.

De aquí, vamos a ver si derivamos el significado de las demás variables.

"Elapsed Exclusive Time" en el ejemplo para el método Generate es de 0.59 mseg. ¿como es posible?? esta variable lo que mide es el tiempo que es ha ejecutado el método, sin incluir las funciones hijas. Es como si cuando se llama a una función hija (en este caso por ejemplo al método generatePrimi ) es como si se parase el cronometro y a la vuelta de la función, se pone de nuevo el cronometro.

Entonces, el método que tenga mayor "Elapsed Exclusive Time" es la que me va a decir, que función esta siendo un cuello de botella.

Si ahora nos fijamos en que función tiene mayor ""Elapsed Exclusive Time" , esta es:

Y la función es drawProbability con un tiempo de 23.77mseg. Pero ojo!, hay si tiempo "Elapsed Inclusive Time", es de 1042.92, con lo cual, hay hay 'algo' en la función, que la hace ir más lenta.

Pero vamos a ver que nos dice el Visual Studio, generando el el árbol con las llamadas más costosas.

Nos dice el VS que el cuello de botella está en efectivamente en drawProbability . Y las llamadas a la API del GDI+ es lo que le está haciendo ir más lento. Mirando el código se ve que en cada iteración del bucle, se crea Pen y Brush que se puede crear al principio, ahorrando la creación de estos objetos 49 veces.

Optimizando

Creando los objetos Pen y Brush fuera del bucle en el método drawProbability , en tiempo "Elapsed Time Inclusive" es de 6564 msg.

7062 - 6564 = 498 msg ahora más rápido para 1000 simulaciones.

Truquito

Una de las cosas que se podría hacer para detectar a tiempo que una función está tardando mucho es por poner lo siguiente

public void DoSameThink()

{

    Stopwatch stopwatch = new Stopwatch();

            stopwatch.Start();

  //codigo de la función

//...............................

//...............................

    stopwatch.Stop();

Debug.Assert(stopwatch.ElapsedMilliseconds < 1000, "El método DoSameThink ha superado 1 segundo");

}

ejemplo:

Conclusión No he contado nada que este escrito por otros blogs, libros, pero a mí me ha servido para asimiliar mejor el tema del rendimiento, de como analizar y ver los cuellos de botella. Si tu también estabas en ese caso y te ha ayudado, estupendo!!! Como se ve, hay muchas variables que da el visual studio que aquí no se han nombrado, pero ya con estas dos variables que hemos nombrado, podemos mejorar algo el rendimiento de nuestro código. El código fuente por está aquí por alguien quiere bajarlo y trastear con ello modificandolo. En próximas, a ver si me adentro más en este campo. Félix Romo felix.romo.sanchezseco@gmail.com

Como construir un control Acordeon (Accordion control)

Como construir un control Acordeon (Accordion control c#)

Introducción

A lo largo del desarrollo de un proyecto, van surgiendo nuevos requisitos, o normalmente, son ampliaciones de los requisitos existentes. También por esto, es muy conveniente, antes de escribir código, contar hasta diez, es decir, diseñar, hasta que el diseño sea estable y pueda soportar los requisitos presentes y los posibles futuros (también hay que diseñar para estos). Aunque claro, muchos jefes, verán este trabajo como no productivo por que no hay lineas de código escritas, pero puede ahorrar días e incluso meses, a lo largo de la vida del código. Pero en fin, esto es otra historia...

Algo que me paso en un proyecto. Había que mostrar unos resultados de datos en una ventana provenientes de unos cálculos, podrían ser un resultado o muchos, y luego también añadir más resultados o borrar resultados que no interesaban. Aquí estime que uno de los controles que podrían encajar era de tipo acordeón.

Estupendo, ya tengo la idea que tendrá la vista, la diseño a portaminas y folio, y aquí que vemos que .Net no tiene un control de acordeón. Entonces, investigando por la red, para ver otros desarrolladores lo hacían. Me encontré con varios ejemplos, pero quería desarrollar el mío propio y así, ya tendríamos el control total sobre este control por si la vista necesitaba algo adicional que no tuviesen los demás controles.

Al lío..

Una de las fuentes en las que me base para construir el mío fue este:

http://sourceforge.net/projects/accordion/

Y empecé a investigar como estaba diseñado, una vez que capte la idea general, empeze a desarrollar el mío propio.

Las clases principales son:
Accordion: es la clase que representa el control..claro..

CheckBox: es una clase de .Net que aquí se usa como control que cuando se hace click, se oculta o aparece el control que hay debajo de este.
Control2: es una clase que une los objetos CheckBox y FLP.
FLP: es un clase que representa un FlowLayoutPanel. Mejor dicho deriva. Y es quién controla, cuando aparece un control o se oculta.

A partir de esta idea, empeze a desarrolar mi acordeón....

Mi Accordion Control

ownAccordion: clase que representa al control acordeón.
TitleControl: clase que representa el control que se va a quedar como cabezera de los controles que se añadan. Aquí se usa un usercontrol y asi poder añadir botones. En este caso, '+' y '-' para asi, añadir más controles al propio acordeón o borrarlos directamente.
myFLP: es la clase que deriva de un FlowLayoutPanel, y controla el añadir o borrar los objetos Control que se añaden al acordeón. En este ejemplo, los objetos ClientDataControl

Sé que le falta mucho a este control para que tenga una buena apariencia, pero creo que la base para seguir desarrollando. Aquí, por ejemplo, en un equipo de desarrollo, este control lo desarrollaría un programador senior, analista/programador, ingeniero software o el mismo jefe de proyecto (los cuales lo desarrollarían no acoplado el proyecto actual, sino de forma que se pueda usar en otros proyectos), y luego pasarlo otro desarrollado para que lo vaya ampliando, y además, aprendiendo. Una forma de ser mentor también.

¿Como queda?

La parte izquierda es de http://sourceforge.net/projects/accordion/

El código fuente se puede descargar de aquí.

Conclusión

Aparte de leer libros, revistas, investigar códificando, probando,..el leer código que hay por la red, intentar desarrollar los mismo, es otra forma de aprender. Y además, te habrá la mente a hacer las cosas de otra manera y lo mismo, más fácil.

Félix Romo

felix.romo.sanchezseco@gmail.com