Archivo de la categoría: Opinion

[#ALM] Do you ever wondered why we do use methodologies? (and again PAIN is the solution)

Posted on by

ALM 03

Buenas,

care that you I will not go into whether AGILE, SCRUM or the death of the Waterfall model. Today I’m going to something more basic:

We do use methodologies during the software development process?

Do not you like the phrase? then to see if this you think more appropriate

Is why recommended to implement good practices during the software development process?

Do you still like it? I play with the last

You do make software and work in mode Ninja, following only your instinct and reacting to changes as they arise: as… die between terrible suffering!!

I hope that after this introduction has been able to explain the concept: call them methodologies, good practices or in some other way; everyone follows a set of rules when developing software. The initial question is why we do this, and the answer is more than obvious

To reduce the risk in our projects

or if you like more

To have more predictive results that work

It seems simple no? For you to know that more than 50 years have passed since one realized this and formalized it. First created the processes, which were responsible for defining the way in which it should work. The good thing about the processes is that they were 100% measurable. It was very easy to say that as we have defined it to this task on these bases, then it should take 6 months. If everyone respected those processes because the results were highly predictable.

But of course, people are quite unpredictable beings; and both from the side of the customer and the programmers were constantly changes. That is why, a couple of cracks came together and created the manifesto agile; people on processes, response to the change tracking, etc. We are going that you know already…

And again, behind all this had one more than simple reason: to be able to predict the results and be consistent with what a person or a team can do. So now you know, if you ever ask yourself why a team works with a set of rules, a methodology, best practices or the name of fashion, as it is likely to be to improve the output of the team and to be more predictable (among other things)

Clarification: care! that that doesn’t mean that a team working under these premises that do not serve absolutely anything, those cases already know how to fix it: pain!

And close one of Dilbert gift

image

Saludos @ Home

El Bruno

image image image

[#ALM] Alguna vez te has preguntado porqué utilizamos metodologías? (y de nuevo el Dolor es la solución)

Posted on by

ALM 03

Buenas,

cuidado que no voy a entrar en si AGILE, SCRUM o la muerte del modelo Waterfall. Hoy voy a algo más básico:

¿Porqué utilizamos metodologías durante el proceso de desarrollo de software?

¿Qué no te gusta la frase? pues a ver si esta te parece más adecuada

¿Porqué es recomendable aplicar buenas prácticas durante el proceso de desarrollo de software?

¿Sigue sin gustarte? me juego con la última

Te dedicas a hacer software y trabajas en modo Ninja, siguiendo solo tu instinto y reaccionando a los cambios a medida que surgen: Pues … ¡¡¡ morirás entre terribles sufrimientos !!!

Espero que después de esta introducción haya podido explicar el concepto: los llamemos metodologías, buenas prácticas o de alguna otra manera; todos seguimos una serie de normas cuando desarrollamos software. La pregunta inicial es porqué hacemos esto, y la respuesta es más que obvia

Para reducir el riesgo en nuestros proyectos

o si te gusta más

Para tener resultados más predictivos sobre los que trabajar

¿Parece simple no? Pues que sepas que han pasado más de 50 años desde que uno se dio cuenta de esto y lo formalizó. En primer lugar se crearon los procesos, que se encargaban de definir la forma en la que se debía trabajar. Lo bueno de los procesos es que eran 100% mesurables. Era muy fácil decir que como a esta tarea la hemos definido sobre estas bases, pues la misma debería tardar 6 meses. Si todas las personas respetaban esos procesos pues los resultados eran altamente predecibles.

Pero claro, las personas somos unos seres bastante impredecibles; y tanto desde el lado del cliente como del los programadores los cambios se sucedían constantemente. Es por esto, que un par de cracks se juntaron y crearon el manifiesto ágil; personas sobre procesos, respuesta al cambio sobre el seguimiento, etc. Vamos que ya lo conoces …

Y de nuevo, detrás de todo esto había un motivo más que simple: poder predecir los resultados y ser coherentes con lo que una persona o un equipo puede hacer. Así que ya sabes, si alguna vez te preguntas porqué un equipo trabaja con una serie de reglas, con una metodología, best practices o el nombre de moda, pues es probable que sea para mejorar el output del equipo y para ser más predecibles (entre otras cosas)

Aclaración: cuidado! que eso no quita que un equipo trabaje bajo unas premisas que no sirven absolutamente para nada, esos casos ya sabes la forma de arreglarlo: DOLOR !!!!

Y para cerrar una de Dilbert de regalo

image

 

 

Saludos @ Home

El Bruno

image image image

[#ALM] #House, Occam’s razor and in the end we all make mistakes

Posted on by

ALM 03

Buenas,

Today’s post starts with a statement:

HOUSE is a genius

One can refute me that all chapters are the same, something like this:

  1. Patient X has unknown disease
  2. Give it to House you don’t want to see and accept it reluctantly
  3. Patient X creates a link with one of the assistants of House
  4. House skips rules to see that kind of disease the patient
  5. Team crap it, almost are charged to the patient
  6. To House a good of their bosses drop
  7. In a moment of inspiration, House da with disease

… and always, or almost always, by the way is ruled out Lupus or autoimmune disease.

With this summary you’ve saved to see the 8 seasons of House . However the best that has House, is that throughout the entire series, the protagonist has a nasty / Host which has made to let go a few phrases that are pure wisdom. An excellent example and of which my favorite is:

Women are never wrong, even when they are wrong, there comes a time of discussion in which surprisingly return to reason.

As that, the 3rd chapter of the first season is titled ” “ Completo de Occam Razor “, which translated into spanglish is something like “ Ockham’s razor . Ockham’s Razor is a principle of makes a pile of years (14th century) that says something like this:

In equal, the simplest explanation is usually the correct.

This is pure wisdom, and common sense to the square. When you work in computer science and issues you face every day, you end up realizing that this is a truth for framing. But of course, as in all truth to frame, should take into account the context of each claim.

Today I’m very graphic, so here is a clear example:

image

It is clear not?, I hope that Yes, the simplest statements also tend to be correct.

And now if we can already return to House . In the chapter that inspired this post, House gives one twist to the phrase of Ockham, rethinking something like:

The simplest explanation is almost always someone goofed

This is also 100% applicable to our work every day in computer science. Often we are able to find network problems, problems of deployments, upgrades, etc.; When the 1, that we should do is talk to people to see or who has touched something. It is amazing how a little 5 minute session with people affected by a problem can help more than hours and hours of trial and error with a problem.

And to close, the Council always: fosters a culture of communication in your team, this is fundamental for the correct operation of the same.

 

Saludos @ Home

El Bruno

image image image

[#ALM] Sobre #House, la navaja de Occam y como al final todos la cagamos

Posted on by

ALM 03

Buenas.

El post de hoy empieza con una afirmación:

HOUSE es un crack

Alguno me podrá refutar que todos los capítulos son iguales, algo así:

  1. Paciente X tiene enfermedad desconocida
  2. Se lo dan a House que no lo quiere ver y lo acepta de mala gana
  3. Paciente X crea un vínculo con uno de los asistentes de House
  4. House se salta las normas para ver que tipo de enfermedad tiene el paciente
  5. El equipo la caga, casi se cargan al paciente
  6. A House le cae una buena de sus jefes
  7. En un momento de inspiración, House da con la enfermedad

… y siempre, o casi siempre, por el camino se descarta el Lupus o alguna enfermedad autoinmune.

Con este resumen te he ahorrado ver las 8 temporadas de House. Sin embargo lo mejor que tiene House, es que a lo largo de toda la serie, el protagonista tiene una mala leche / hostia que tiene hace que suelte unas frases que son sabiduría pura. Un excelente ejemplo y de las que más me gusta es:

Las mujeres nunca se equivocan, incluso cuando se equivocan, llega un momento dela discusión en la que sorprendentemente vuelven a tener razón.

Pues eso, el 3er capítulo de la primera temporada se titula “Occam’s Razor”, que traducido al spanglish es algo así como la navaja de Ockham. La navaja de Ockham es un principio de hace una pila de años (del siglo XIV) que dice algo similar a esto:

En igualdad de condiciones, la explicación más sencilla suele ser la correcta.

Esto es sabiduría pura, y sentido común al cuadrado. Cuando trabajas en informática y te enfrentas a problemas diariamente, te terminas dando cuenta de que esta es una verdad para enmarcar. Pero claro, como en toda verdad para enmarcar, hay que tener en cuenta el contexto de cada afirmación.

Hoy estoy muy grafico, así que veamos un ejemplo más claro:

image

¿Queda claro no?, espero que sí, las afirmaciones más simples tampoco suelen ser las correctas.

Y ahora si, ya podemos volver a House. En el capítulo que inspira este post, House da una vuelta más a la frase de Ockham, reformulando algo así como:

La explicación más sencilla es que casi siempre alguien metió la pata

Esto también es 100% aplicable al día a día de nuestro trabajo en informática. Muchas veces nos podemos a buscar problemas de redes, problemas de despliegues, actualizaciones, etc.; cuando lo 1ro que deberíamos hacer es hablar con la gente para ver que o quien ha tocado algo. Es increíble como una pequeña sesión de 5 minutos con las personas afectadas por un problema puede ayudar más que horas y horas de prueba y error frente a un problema.

Y para cerrar, el consejo de siempre: fomenta una cultura de comunicación en tu equipo de trabajo, esto es fundamental para el correcto funcionamiento del mismo.

 

Saludos @ Home

El Bruno

image image image

[#OPINION] About the experts, how to improve as a developer and death to Hard Code!

Posted on by

image

Buenas,

image

The popular quotes are amazing, for example say that ‘God helps it to the early bird, ‘ and it is almost always true. My mother has woken up by more than 40 years before the 0600 AM and a son of the very best touched him. There is another who is also a great “practice makes perfect” and in the case of programmers, East if it is 100% real. In my case for years every time I spend less actual hours to programming and I’m noticing.

I still have marathons staying until 0200 AM to finish something, or to try something, but I don’t have the day 100% dedicated to programming. This can be seen, many times when I am faced with a problem I realize that practice, I perhaps need not to resolve it, but if speed to implement it. That is why the phrase “practice makes perfect” is 100% certain. The best professionals are actually working with a technology or tool.

Note 1:I take this opportunity to advise you desconfíes of the gurus who write topics that they don’t know or that they only transcribe things who have read on the internet that. People who know the most, are those who are in the trenches.

Note 2:It is also important to note that while you can be in front of someone who pulls 14 hours a day with a hammer in his hand, that does not mean that he is an expert in hammering. There is also much useless around che.

Returning to the topic of the muscle to set; to practice the best schedule, schedule, and schedule… it is. As the basis of programming is to solve problems, it is important to know to find a response to know your tools. I try to devote at least a daily pomodoro to solve a problem that has nothing to do with my day-to-day work (I have the luck that I prefer my work than my hobbies ;)

The best for this are the Code Katas (Juan Carlos Quijano was a very good intro here), which are exercises to solve problems regardless of the tool or language. I weekly do an internet search to find any interesting, or but I’m going directly to http://codekatas.org/ and try to resolve which is fashionable.

Another technique that I find that he helps me is to learn a new programming language. For this a few months ago I have pointed to Code Academy (http://www.codecademy.com) and excellent site where you can follow tutorials interactive to learn new languages. In my case I have opted for a language that I will surely not I use never: RUBY, but I used to test a site that has something of a Code Kata: http://codegolf.com/

image

3 Note:Some time ago recommended to learn a language every year to be a better programmer. Now I think that it is more important to learn a new platform as a new language… but to taste, the colors.

Now well and finally, another thing to do to be a better professional is to teach. When you begin to explain a specific topic to someone, is an excellent time where your brain starts to do a real analysis of the level of knowledge you have on that subject. At that time internal doubts that at another time you plantearías not soar, also will reinforce knowledge and is an excellent exercise to learn how to communicate (for 3 years had to machine works of psychology students… topic for another post). That is why I close my post with a tip in the form of teaching:

SHORT FINGERS HARD CODE PRACTITIONERS!

I’m going to the bases, but bases. Surely many will have escaped you a constant, or a string with a value hardcodeado which then in production brought many problems (to my ever happened). One way of trying to avoid this is with pain. If pain has proved to be one of the best methods for teaching for years. But, how do you manage to breach a developer pain? as through the eyes with the following steps:

1 Access to the options of Visual Studio. Menu “Tool / / Options”

2 Select “Fonts and Colors”

3. Select the item “String (C# @ Verbatim)” and changes the color of background and text, for something thathurts. In my example is lime background with yellow font color.

image

4 Starting from now hardcodeado code will look like

image

5. What hurts?

Recommended reading

 

Saludos @ Home

El Bruno

image image image

[#OPINION] Sobre los expertos, como mejorar como developer y muerte al Hard Code !!!

Posted on by

image

imageBuenas.

Los dichos populares son increíbles, por ejemplo dicen que “al que madruga Dios lo ayuda”, y es casi siempre cierto. Mi madre se ha despertado por más de 40 años antes de las 0600AM y le ha tocado un hijo de lo mejorcito. Hay otro que también es buenísimo “la práctica hace al maestro” y en el caso de los programadores, este si es 100% real. En mi caso durante los últimos años cada vez dedico menos horas reales a la programación y lo voy notando.

Sigo teniendo maratones quedándome hasta las 0200 AM para terminar algo, o para probar algo, pero no tengo el día 100% dedicado a programar. Esto se nota, muchas veces cuando me enfrento con un problema me doy cuenta de que me falta práctica, tal vez no para resolverlo, pero si velocidad para implementarlo. Por eso es que la frase “la práctica hace al maestro” es 100% cierta. Los mejores profesionales son los que realmente trabajan con una tecnología o herramienta.

Note 1: Aprovecho para aconsejar que desconfíes de los gurúes que escriben de temas que no conocen o que solo transcriben cosas que han leído por el internet ese. Las personas que más saben, son aquellas que están en las trincheras.

Note 2: También es importante destacar que si bien puedes estar delante de alguien que se tira 14 horas diarias con un martillo, en la mano, eso no significa que sea un experto en martillar. También hay mucho inútil por ahí che.

 

Volviendo al tema del músculo para programar; para practicar lo mejor es programar, programar y … programar. Como la base de la programación es resolver problemas, es tan importante saber encontrar una respuesta como conocer tus herramientas.  Yo intento dedicar mínimo un pomodoro diario a resolver un problema que no tenga nada que ver con mis tareas diarias del trabajo (tengo la suerte de que me gusta más mi trabajo que mis hobbies ;)

Lo mejor para esto son los Code Katas (Juan Carlos Quijano hizo una muy buena intro aquí), que son ejercicios para resolver problemas independientemente de la herramienta o el lenguaje. Yo semanalmente hago una búsqueda en internet para encontrar alguno interesante, o sino me voy directamente a http://codekatas.org/ e intento resolver el que esté de moda.

Otra técnica que encuentro que me ayuda es aprender un nuevo lenguaje de programación. Para esto desde hace unos meses me he apuntado a Code Academy (http://www.codecademy.com) y sitio excelente donde puedes seguir tutoriales interactivos para aprender nuevos lenguajes. En mi caso he optado por un lenguaje que seguramente no utilizaré nunca: RUBY, pero que me sirve para probar un sitio que posee algo parecido a un Code Kata: http://codegolf.com/

image

Nota 3: Hace un tiempo recomendaban aprender un lenguaje cada año para ser mejor programador. Actualmente pienso que es más importante aprender una nueva plataforma que un nuevo lenguaje … pero para gustos, colores.

 

Ahora bien y para finalizar, otra cosa que hay que hacer para ser mejor profesional es enseñar. Cuando comienzas a explicarle un tema específico a alguien, es un momento excelente donde tu cerebro comienza a hacer un análisis real del nivel de conocimiento que tienes sobre ese tema. En ese momento se disparan dudas internas que en otro momento no te plantearías, también se afianzan los conocimientos y es un ejercicio excelente para aprender a comunicar (durante 3 años pasé a máquina trabajos de estudiantes de psicología … tema para otro post). Es por eso que cierro el post con un consejo en forma de enseñanza:

CORTA LOS DEDOS A LOS PRACTICANTES DEL HARD CODE !!!

Voy a las bases, pero a las bases. Seguramente a muchos se les habrá escapado una constante o un string con un valor hardcodeado que luego en producción trajo bastantes problemas (a mi me ha pasado). Una forma de intentar evitar esto es con DOLOR. Si, el dolor ha resultado ser uno de los mejores métodos para la enseñanza desde hace años. Pero, ¿cómo logras infringir dolor en un developer? pues a través de los ojos con los siguientes pasos:

1. Accede a las opciones de Visual Studio. Menú “Tool // Options”

2. Selecciona la opción “Fonts and Colors”

3. Selecciona el item “String (C# @ Verbatim)” y cambia el color de fondo y del texto,  por algo que duela. En mi ejemplo es fondo Lima con color de fuente amarillo.

image

4. A partir de ahora el código hardcodeado se verá asi

image

5. ¿A qué duele?

 

 

Lecturas recomendadas

 

Saludos @ Home

El Bruno

image image image

[#OPINION] About techies and business support

Posted on by

image

Buenas,

always happens to me everytime I go to events whose focus is not the technology, I realize that when much distance between IT teams and business people, as work is likely to not serve for nothing.

Today was lucky enough to live to see a person… ok I can’t say the name, but I think that I can give clues. Those who know space travel will know the company where he works this person, which is one of the few commercial companies that are dedicated to send things into space. And as well as put you in orbit in a commercial way, also put the batteries and they win a couple of Championships in F1, not clear?

As that, at a certain point, raised the debate on whether internal or external it Department, and the example was terrific. It is basically remember why all the websites in the late 1990s and early 2000 were more ugly than the birth of Mick Jagger. Very simple, the led IT departments. We had very useful websites with endless lists, super complex processes to register a few details and again, uglier than stepping barefoot shit. Then it began to get into the topic of business experts and clear… the thing was better.

Note: care today an ugly web site, is in fashion. It can be to think that it is as well as a marketing technique that we associate it with a person. I recommend to take a look at this link .

I proceed, the focus to keep in mind is that the techies are (are we?) very important, perhaps essential. But a techie without direction is like a ship without a rudder, can finish anywhere. For example the case of Facebook.The Mark Z is a techie, but is a person who lives 25 hours a day thinking about one thing you would like to improve Facebook?. Those who know him (I haven’t had luck), say that as the father of the world’s largest social network, it is the person more aSocial there. This is normal, it is not an example of believe it, it is only the hand that guides the direction of FB.

Now, and why this post? (in addition to time in the ) Charles de Gaulle ) just to remember that if you’re a techie, on many occasions it is almost more important to work beside the person of business than trying to sneak shoe horn with the latest in the latest technology. 5 of the 10 most successful companies commercially, are last in the technological support on which they are supported. That Yes, meet its objective in a masterly way Risa

Resources: http://forums.site-reference.com/topic/1897/The-Surprising-Truth-About-Ugly-Websites/

Saludos @ Paris

El Bruno

image image image

[#OPINION] Sobre los techies y el negocio que soportan

Posted on by

image

Buenas,

siempre me pasa cada vez que salgo a eventos cuyo foco no es la tecnología, me doy cuenta de que cuando mucha distancia entre los equipos de IT y las personas de negocio, pues el trabajo es probable que no sirva para nada.

Hoy tuve la suerte de ver en vivo a una persona … ok no puedo decir el nombre, pero creo que puedo dar pistas. Los que conozcan los viajes espaciales conocerán la empresa donde trabaja esta persona, que es una de las pocas empresas comerciales que se dedican a enviar cosas al espacio. Y así como te ponen en órbita de modo comercial, también se ponen las pilas y ganan un par de campeonatos de F1, claro no?

Pues eso, en un determinado momento, se planteó el debate sobre si departamento de tecnología interno o externo, y el ejemplo fue buenísimo. Básicamente se trata de recordar de porqué todos los websites de fines de los 90s y principios del 2000 eran más feos que el parto de Mick Jagger. Muy simple, los dirigian los departamentos de IT. Teníamos websites muy prácticos con listas interminables, procesos super complejos para dar de alta un par de datos y repito, más feo que pisar mierda descalzo. Luego comenzó a meterse en el tema los expertos de negocio y claro .. la cosa fue a mejor.

Nota: cuidado que hoy un sitio web feo, está de moda. Se puede llegar a pensar en que el mismo es así como una técnica de marketing para que asociemos al mismo con una persona. Recomiendo darle un vistazo a este link.

Prosigo, el foco a tener en cuenta es que lo techies son (somos?) muy importantes, tal vez esenciales. Pero un techie sin dirección es como un barco sin timón, puede terminar en cualquier parte. Para ejemplo el caso de Facebook. El Mark Z es un techie, sin embargo es una persona que vive las 25 horas del día pensando en una sola cosa ¿como mejorar Facebook?. Los que lo conocen (yo no he tenido la suerte), dicen que por ser el padre de la red social más grande del mundo, es la persona mas aSocial que existe. Esto es normal, él no es un ejemplo de lo crea, es solo la mano que guía los rumbos de FB.

Ahora bien, ¿y porqué este post? (además de tener tiempo en el Charles de Gaulle) solo para recordar que si eres un techie, en muchas ocasiones es casi más importante trabajar al lado de la persona de negocio que intentar colar con calzador lo último de lo último en tecnología. 5 de las 10 empresas más exitosas a nivel comercial, son de última en el soporte tecnológico sobre el que se apoyan. Eso sí, cumplen su objetivo de manera magistral Risa

 

Recursos: http://forums.site-reference.com/topic/1897/The-Surprising-Truth-About-Ugly-Websites/

Saludos @ Home

El Bruno

image image image

[#VS2012] HowTo: Create extension methods in C++ to extend extension methods in C# already existing

Posted on by

image

Buenas,

imagetoday I write something a little complicated. The title of the post it already tells you everything, and if you are still reading, for sure have some curiosity about how it makes something that doesn’t make much sense. So, in this post you will not see any code, or any real example, this POST does not work.

And if the question you do now is why? The answer is very easy,

YOU MUST NOT ALWAYS USE THE EXAMPLES THAT ARE READ ON THE INTERNET

If some guru publish some demos on how to decompiling the core cross-cutting the Ribbon of Office 2013, and crossing a wild boar with a lizard, could embed this Ribbon in a C application #, that does not mean that you should do it!

So, this post is a call to solidarity with 2 points to consider

  • I am seriously thinking of leaving the code source of my examples in “text mode”, now should be PNGs. As you well know, I am not anyone’s example, however I’ve seen as many people Copy & Paste and then asks. The thinking now is not fashionable
  • Please think and analyze what they find on the internet. A very cool solution to a stage, in the long run perhaps a hell for your scenario. This not only applies to things with native APIs of Windows (where now suffer eternal torment of seeing as you do for WinRT!), but models of business entities, patterns, etc.

So, now I’m going back from Paris and remember all the relatives of more than one… leave a post that adds nothing (but consolation that nobody will make me a COPY & PASTE of the same!)

Image: http://ffffound.com/image/50c1b282a9c00f2d3ec68f8d5af641c75249796f

Saludos @ Paris

El Bruno

image image image

[#VS2012] HowTo: Crear extension methods en C++ para extender extension methods en C# ya existentes

Posted on by

image

Buenas,

imagehoy me toca escribir algo un poco complicado. El título del post ya te lo dice todo, y si sigues leyendo, seguramente te pica la curiosidad sobre el CÓMO se hace algo que no tiene mucho sentido. Así que bien, en este post no verás nada de código, inclusive ningún ejemplo real, este POST NO SIRVE.

Y si la pregunta que te haces ahora es ¿PORQUÉ? La respuesta es muy fácil,

NO SIEMPRE HAY USAR LOS EJEMPLOS QUE SE LEE EN INTERNET

Si a algún iluminado se le dio por descompilar el core transversal de la Ribbon de Office 2013, y cruzando un jabalí con un lagarto, pudo incrustar esa Ribbon en una aplicación C#, eso no significa que TU DEBAS HACERLO!

Así que bien, este post es un llamado a la solidaridad con 2 puntos a tener en cuenta

  • Estoy pensando seriamente en dejar de poner el código fuente de mis ejemplos en “modo texto”, a partir de ahora deberían ser PNGs. Como bien sabrás, yo no soy ejemplo de nadie, sin embargo he visto como mucha gente hace Copy&Paste y luego pregunta. Lo de pensar ya no está de moda
  • Por favor, piensa y analiza lo que encuentras en internet. Una solución muy molona para un escenario, tal vez a la larga sea un infierno para TU ESCENARIO. Esto no solo aplica a cosas con APIs nativas de Windows (donde ahora sufrirás el tormento eterno de ver como lo haces para WinRT!), sino con modelos de entidades de negocio, con patrones, etc.

Así que bien, antes de irme a París y acordarme de todos los parientes de más de uno … dejo un post que no aporta nada (pero me sirve de consuelo que nadie hará un COPY&PASTE del mismo !)

Image: http://ffffound.com/image/50c1b282a9c00f2d3ec68f8d5af641c75249796f

Saludos @ Home

El Bruno

image image image