[#EVENT] My quick appeareance in #DotNetSpain2015

Hi!

Last February 28th, I was lucky enough to host 2 sessions in the biggest .net event in Spain “Spain Dot Net Conference”. I shared my Coding4Fun experiences and also I talked a little about Arduinos, Galileos, Netduinos, etc.

As soon as I ended my sessiones I take a flight to Baarcelona to host and help in the Barcelona al Mobile World Congress. I promised to share my slides, so :D

Saludos @ MWC

/El Bruno

[#EVENT] Mi paso por #DotNetSpain2015

Buenas

el pasado 28 de Febrero, tuve la suerte de tener 2 sesiones en el mega evento “Spain Dot Net Conference”. En ellas hablé un poco de cosas divertidas y además de Arduinos, Galileos, Netduinos, etc. Si bien me costó llegar al evento (gracias Roberto), una vez dentro el ver a toda la gente de las comunidades fue genial :D. Eso sí, veo que lo de dar KitKats en las sesiones ya es un clásico ;)

Lamentablemente, apenas terminó el evento tuve que subirme a un avión y venir para Barcelona al Mobile World Congress. Eso sí, prometí subir las slides y aquí estan

Saludos @ MWC

/El Bruno

[#ALM] Por favor, no añadir cosas que no necesitas en tu desarrollo!!!!!!

Clipboard01

Hola!!!

Hoy estuve involucrado en una discusión vía yammer y publiqué una respuesta similar a esta en inglés. Así que la voy a a agregar como un recordatorio a mí mismo para ver que estoy haciendo el año que viene.

Creo que es muy importante que comencemos a desaprender “la forma en la que estamos acostumbrados a trabajar” y debemos empezar a cambiar la forma en que llevamos nuestro día a día. En los “viejos tiempos” solíamos unos DSLs muy inteligentes que nos permitían hacer una abstracción de nuestros dominios y generalmente eran lo suficientemente inteligentes como generar una gran parte de nuestras soluciones. También, solíamos tener un “proceso bien definido de desarrollo” desde la fase de requisitos hasta el “día del juicio final” y que cubría la mayoría de los pasos y roles para nuestro equipo de dev.

Hoy hay una manera completamente diferente de trabajar. No necesitamos DSLs y procesos; Necesitamos “gente inteligente”, “profesionales”. Es decir, la gente que es lo suficientemente inteligente como para dedicar una parte de su tiempo de trabajo, a aprender cosas nuevas y luego aplicar este conocimiento en el trabajo que realizan.

Un ejemplo práctico de esto es la odiada “arquitectura” (nunca me gustó el término, y odio más aún a los arquitectos) Lo dejé bien claro hace un tiempo:

Un equipo que practica SCRUM deja que la arquitectura emerja a medida que se construye el software. Si bien estamos acostumbrados a planificar los aspectos de la arquitectura, debemos comprender que este enfoque no deja de lado la arquitectura de software sino que deja que la misma vaya aportando valor al software que se construye a medida que el mismo avanza.

Si una persona conoce sus herramientas y su dominio; es probable que comience trabajando en un modo muy simple con GIT y sobre la base de “Vamos a hacer algo que aporte valor“. Un par de sprint después añadiremos algunas prácticas de CI (TFS, Team Build o Team City), algunos DevOps (Release Management, HP ALM, etc.) o… cualquier cosa que requiera el proceso de desarrollo.

Si en cambio, vamos desde cero con “una pila completa de productos” probablemente estemos añadiendo más problemas que ventajas al equipo ;)

Saludos desde Madrid

/El Bruno

Referencias

http://elbruno.com/2013/12/24/scrum-scrum-no-es-para-aficionados/

[#ALM] Please, don’t add stuff you don’t need into your development !!!

Clipboard01

Hi !!!

I was involved in a yammer question today and I get to this response. Nice one to add as a reminder to myself.

I think we must start to unlearn “old ways” and start to change the way we work. In the “old days” we used to have this nice DSLs to make a cool abstraction of our domains and they usually are smart enough to generate a great part of our solutions. Also, we have a “good defined dev process” from the requirements phase to the “judgement day” and its cover most of the steps and roles for our dev team.

Today there is a complete different way to work. We don’t need DSLs, and process; we need “smart people”, “professionals”. I mean, people who is intelligent enough to dedicate a part of their work time, to learn new stuff and later apply this knowledge into their projects. A practical example of this is the hated “architecture” (I never liked the term, I hated most the “architects”) In example: A good team let’s that architecture emerges as the software is built.

If you know your tools, and your domain; for sure you’ll start with GIT and a basic “let’s do something to add value” and a couple of sprints later you’ll add some CI (TFS, Team Build, or Team City), some DevOps (Release management, HP ALM, etc) or … whatever your development solution requires. If we go from scratch with a “full stack of products” we can probably add more issues than advantages to the team ;)

Greetings from Madrid

/El Bruno

References

http://elbruno.com/2013/12/27/scrum-arquitecture-must-emerge-fs-the-classic-architects/

http://elbruno.com/2013/12/25/scrum-scrum-is-not-for-amateurs/

[#GALILEO] Using non #Grove sensors with Grove, ie: #UltraSonic Ranger

Hello!

If you work with Arduinos or Intel Galileo, you will surely be a fan of Grove. Grove is great, you only need to Plug and play sensors and lets you prototype very quickly with the boards. In a couple of seconds you can have a great layout with sensors and actors connected to each other.

The funny thing is that when you decide to use “not grove” sensors to connect them to a Shield Grove, you get get to study a little before you can use them. For example, if we compare the 2 versions of the ultrasonic sensor we will see that the Grove version has 4 connectors and the normal version only 3.

Picture1

When we read the specifications from the normal version (red one), we see that also this version does not bring a series of libraries or headers C to use on our Arduino projects. The code example includes all of the code to see how works at low level sensor.

The following lines are worth gold, we see that to “take away” what makes the sensor is

-Initializes the pin in OUTPUT mode

-several milliseconds apart, performs several digitalWrite() actions to send information to the PIN

-changes the mode of the pin to INPUT

-use pulseIn() to determine the “distance” which was collected by the sensor.

Clipboard02

And ready! then a couple of conversions to return centimeters or inches and the sensor is working. If we now that this sensor works on a single grove plate we need to respect the cables for power and ground (red and blue); e reverse the data cables. Since the signal sensor takes is captured in the white wire and plate Grove the yellow cable is used to define the Pin.

photo247099884290812206

.Greetings @ Home

/El Bruno

References:

Groove for Galileo, http://www.seeedstudio.com/depot/Grove-starter-kit-plus-Intel-IoT-Edition-for-Intel-Galileo-Gen-2-and-Edison-p-1978.html

Ultra Sonic Ranger, http://www.seeedstudio.com/wiki/index.php?title=Ultra_Sonic_range_measurement_module

[#GALILEO] Utilizando sensores que no son de #Grove en Grove, por ejemplo el #UltraSonic Ranger

Hola!

Si trabajas con Arduinos o Intel Galileo, seguramente serás un fanático de Grove. El sistema que tiene de plug and play para sensores te permite prototipar rápidamente y en segundos tener montadas placas con sensores y actores conectados entre sí.

Lo curioso es que cuando decides utilizar sensores “no grove” para conectarlos a un Shield Grove, te toca ponerte a estudiar un poco y adaptar los mismos. Por ejemplo, si comparamos las 2 versiones del sensor de ultrasonido veremos que la versión Grove tiene 4 conectores y la versión normal solo 3.

Picture1

Cuando entramos a las especificaciones de la versión normal (la roja), vemos que además esta versión no trae una serie de librerías o cabeceras C para poder utilizar en nuestros proyectos arduino. El ejemplo de código incluye TODO el código para ver como trabaja a bajo nivel el sensor.

Las siguientes líneas valen oro, vemos que para “tomar una distancia” lo que hace el sensor es

– inicializa el pin en modo OUTPUT

– con una separacion de varios milisegundos, realiza varios digitalWrite() para enviar información al PIN

– cambia el modo del pin a INPUT

– utiliza pulseIn() para determinar “la distancia” que recogió el sensor.

Clipboard02

Y listo! luego un par de conversiones para devolver centímetros o pulgadas y el sensor está funcionando. Si ahora queremos que este sensor funciona sobre una placa grove solo tenemos que respetar los cables de power y ground (rojo y azul); e invertir los cables de datos. Ya que la señal que toma el sensor se captura en el cable blanco y en la placa Grove se utiliza el cable amarillo para definir el Pin.

photo247099884290812206

.Saludos @ Home

/El Bruno

Referencias:

Groove for Galileo, http://www.seeedstudio.com/depot/Grove-starter-kit-plus-Intel-IoT-Edition-for-Intel-Galileo-Gen-2-and-Edison-p-1978.html

Ultra Sonic Ranger, http://www.seeedstudio.com/wiki/index.php?title=Ultra_Sonic_range_measurement_module

[#GALILEO] Recap posts, pre deploy mode for #MWC2015 and #dotnetspain2015

Hi!

I’ll be very busy next week with the preparations for Mobile World Congress 2015 and e Microsoft DotNet Spain Conference. So I’ll make some advances today with the recap of my posts on Galileo from pasts weeks

Bye @ Madrid

/El Bruno