Blog

semana 4

posted Apr 13, 2015, 3:10 PM by aarias@nearsoft.com

El tema de esta semana me gusto mucho, aprendí cosas muy importantes y me gustaría comentar las que mas me gustaron, de las principales tareas de esta semana para nosotros fue encontrar 3 problemas con los cuales nosotros pudiéramos desarrollar una simple solución, lo increíble de esto fue que nos hizo pensar fuera de nuestra zona de confort y de nuevo recordarnos que no todo es acerca de programación y código,  al principio estuvimos pensando problemas con los cuales nosotros pudiéramos elaborar alguna Aplicación móvil o algún tipo de sistema, pero realmente nos dimos cuenta que primero necesitamos saber si realmente eso es necesario,  y  yo personalmente me di cuenta de algunos problemas que están sucediendo en Nearsoft y no tienen que ver con sistemas cosas por el estilo.

Es mucho mas simple que eso, y por lo tanto seleccionamos tres ideas con las cuales nosotros pudiéramos asignar algunas soluciones simples para tratar de minimizar el problema, los problemas que encontramos fueron los siguientes

Muchas personas que vienen a Nearsoft no tienen huella, por lo tanto cuando llegan mueven la puerta o  si llegan y no hay nadie en la planta baja que les pueda abrir se tienen que esperar mucho para que les abran la puerta, por eso se  nos ocurrió la genial idea de un Nearsoft bell. Cosa que ayudaría a todas estas personas sin huella para que no pasen mucho tiempo esperando afuera.

Otro problema que se encontró fue acerca del transporte de Nearsoft, el problema es básicamente que  las personas no llegan ala hora de salida del transporte y entonces se toma mas tiempo en completarse la ruta y eso automáticamente retrasa alas personas de  la siguiente ruta.

Y el tercer  problema que se encontró, creo de los que todos  se han dado cuenta fue el de el olor de la cocina cuando se esta cocinando algún alimento, ya que ese aroma llega hasta el segundo piso,

De los problemas antes mencionados se hicieron algunas pruebas para garantizar realmente que se necesitaban resolver como por ejemplo se tomo un conteo de las personas que llegan en las tardes sin huella,  en la cocina se cerraron las puertas tratando de minimizar el aroma, y  en el problema de las rutas avisarles alas personas para que no se retrasaran ala hora de salida.

Todo esto no tenia mucho sentido para algunos de nosotros al principio de la semana, pero cuando preguntamos a Isaac el objetivo a mi en lo personal me dejo pensando bastante, su respuesta fue que todo absolutamente todo debe ser probado y no debemos de asumir nada, realmente creo que esto es algo que pondré muy en practica no solo en experimentos como los anteriores, creo que no dar hecho algo y realmente hacer las pruebas para tener la respuesta correcta es algo que debemos tener muy encueta para todas las cosas.

Otras de nuestras tareas fue ver algunos muy interesantes videos acerca de Testing en varios tipos de sistemas, comentare un poco sobre el que mas me gusto, este habla sobre Netflix, una plataforma que maneja volúmenes de información realmente increíbles donde el sistema debe estar disponible  todos los días del año a cualquier hora, me pareció genial que el equipo de desarrollo de Netflix tenga su propio kit de testing nombrado  la armada de los simios, y que básicamente simulan mucho caos dentro de sus sistemas para recrear condiciones reales , claro como eh aprendido en mis anteriores tareas y libros que eh leído , siempre debemos encontrar esos errores nosotros antes que nuestros usuarios finales. creo que hacer testig a plataformas tan robustas es un reto , una frase que me gusto fue la siguiente:

“building distributed systems is hard, Testing them exhaustively is even harder”

Algo Importante sobre el video  “The testing user experience”, este dice que  hacer pruebas no es perder el tiempo, creo que es una trabajo tan importante como el de desarrollo del sistema, en este video aprendí cosas muy interesantes como que hay veces que para resolver un problema solo necesitas es  modelarlo correctamente, creo que es importante que nosotros los desarrolladores tengamos una buena cultura de testing, que no nos de flojera o miedo encontrar errores a nuestros sistemas, porque diseñar sistemas de calidad es nuestra  obligación como profesionales.

Moviéndonos un poco sobre el Testing, me gustaron mucho los videos de Ciencia y computación de “Seth Lloyd “ acerca de las creaciones de la imprenta, la escritura  y la reproducción humana, algo que me pareció muy interesante es cuando se habla acerca de las partículas elementales, y como estas tienen un estado y que al interactuar estas mismas cambian su estado, considerando que el universo siempre esta procesando cálculos, como si el universo fuera una gran computadora. Me gustan mucho este tipos de temas sobre computación cuántica y cosas del universo, realmente me agrada que Isaac nos asigne ver cosas interesantes de este tipo , porque es importante ver hacia donde nos dirigimos en un futuro próximo.

En general esta semana aprendí muchas cosas y me divertí, ya paso un mes desde que entre a Nearsoft y hicimos una pequeña reunión para compartir nuestras experiencias en este tiempo, me gusto que pudimos aclarar nuestras dudas sobre los temas que se nos asignaban o sobre el programa de Nearsoft Academy, y además ver que realmente tenemos buenas oportunidades que no debemos desaprovechar, otra cosa que me pareció muy buena es que se nos dio una retroalimentación sobre nuestro trabajo aquí en Nearsoft, creo que este tipo de actividades son muy importantes para ver en que punto estamos fallando para así poder mejorar en eso y poder lograr ser unos excelentes profesionales.


semana 3

posted Apr 13, 2015, 3:09 PM by aarias@nearsoft.com

Aprendí cosas increíbles esta semana, comentare de las que mas me tomo tiempo entender y las que mas me gustaron, Aprendí cosas interesantes sobre una aplicación que tuvimos que completar sobre un problema de  “big data”, básicamente se trata de desarrollar un recomendador de películas de Amazon, realizar una prueba con maven y ver si la pasaba en menos de 4 minutos, esto lo desarrollamos con java, tomo un poco mas de tiempo que lo que se nos pidió pero  logramos hacer que funcionara y aprendimos muchas cosas sobre manejo de archivos en java. El archivo de las películas tiene un peso de 3.32gb lo que nos hacia tardar demasiado tiempo para procesarlo con la ayuda de java, creo que podía incluso tardar horas en el proceso,  lo que nos llevo a consultar a Isaac para que nos brindara un poco de asesoría, y lo cual nos sirvió bastante porque logramos procesarlo de una manera mucho mas eficiente , reduciendo el tiempo a alrededor de unos dos minutos, todo esto lo logramos usando una librería genial de apache llamada mahout que utilizamos para saber las recomendaciones de las películas a algún usuario dado.


Tuvimos problemas al momento de realizar algunos métodos que estaban en el archivo de prueba, como por ejemplo obtener el total de recomendaciones de películas para tal usuario, ya que las recomendaciones se nos proporcionaban en un tipo diferente al solicitado en el método para comparar si estaban correctas, Otro problema que tuvimos fue que los datos del archivo de Amazon no tenían el formato que mahout necesita para hacer las operaciones,  estuvimos pensando en varias formas de resolver este problema hasta que encontramos que la solución era mas simple de lo que esperábamos, mahout tiene una librería que hacia eso y te quita muchos problemas de encima.


Con este proyecto y unas de las lecturas aprendí sobre cosas que no sabia sobre lo importante que es probar nuestras aplicaciones para que estemos seguros que nuestros productos finales funciones correctamente y que entreguemos productos de calidad a nuestros clientes, aprendí términos que no conocía como Xunit que es una derivación del test Junit, no sabia realmente la cantidad de Frameworks que actualmente tenemos disponible para realizar todas estas pruebas ya sean manuales o pruebas automatizadas.


Otra de nuestras tareas fue  ver algunos videos muy interesantes como por ejemplo un video que tiene el titulo Pale Blue Dot, este video realmente te hace ponerte a pensar muchas cosas, trata como se ve nuestro planeta en una foto tomada a muchos kilómetros en el espacio,  esto puso en prospectiva mi manera de ver a nuestra humanidad y como todos nuestros grandes problemas y logros están en ese pequeño punto en el espacio.


Otro de los videos que me gusto mucho fue el de Machine Learning, que explica como realmente y no es tan difícil crear algoritmos de predicción, y como poder usar estos para poder resolver problemas de la vida real. Claro esto no es una ciencia exacta y desarrollar un algoritmo  no siempre funcionara al 100% con diferentes problemas, aun así pienso que si mas personas se interesaran en este tipo de trabajos esto podría avanzar y tener logros mucho mas rápido que nos ayude a resolver problemas o crear algo increíble, personalmente tal vez me ponga a investigar un poco mas sobre el tema porque creo que esto me pueda ayudar a entender  cosas importantes y quizá podría aplicar mi lógica de programación en esto para aprenderlo mas rápido.


Otros videos fueron sobre como algunos trabajadores de Google  tratan de imaginar alguna solución a algún problema, como tratan de pensar fuera de los limites para así crear cosas  asombrosas que logren un cambio en el mundo. Personalmente estoy de acuerdo con este tipo de pensamiento, todos debemos de tratar de hacer un cambio en el mundo, aunque sea muy pequeño porque  de alguna forma ese pequeño cambio pueda hacer una gran diferencia en el mundo.


También me gustaría comentar sobre lo que aprendí en un video llamado la mejor presentación de tu vida , que nos enseña que nuestra audiencia puede ponernos atención no solo por 20 minutos, si no que realmente las personas podemos poner atención hasta 2 horas,  ir al cine a ver una película es un ejemplo básico de esto, podemos poner atención solo por 20 minutos si el tema que estamos viendo es demasiado aburrido para nosotros.


Lo principal para hacer de una presentación un éxito es lograr que nuestra audiencia pienze y logre sentir, esto mostrándole alguna de nuestras ideas nuevas. Claro debemos de enfocarnos totalmente en nuestra audiencia y no solo estar pensando en nosotros, esto ya lo había aprendido en algunos otros videos que se nos asignaron ver en nuestras tareas pasadas.


También el video llamado Leading me gusto mucho, este video nos enseña como debemos tratar a las demás personas,  porque en nuestro trabajo uno de los factores mas importantes es tener una buena relación con las personas, y muchas veces cuando estamos discutiendo sobre algún tema, las personas siempre quieren tener la razón, creo que este video trata de mostrarnos como nosotros podemos pedir algún consejo para asi poder crecer como personas, a veces es difícil recibir consejos de otros pero creo que es sumamente importante para poder llegar a cumplir todos nuestros objetivos.


De los videos que se nos asigno ver creo que uno de los que mas me puso a pensar cosas fue el de  Quantum computing, video que muestra el experimento que esta llevando acabo Google con la NASA, Donde explican cosas un poco difíciles de entender pero trata sobre entender el comportamiento de las partículas, creo que estos tipos de experimentos son los que nos van a proporcionar los avances mas grandes que podamos imaginar, ya que con ellos creo que podríamos tener respuestas para las preguntas mas fundamentales del universo.


Hablando en general me gusto mucho nuestras tareas de esta semana, Isaac siempre nos brinda videos con los cuales podemos crecer como personas y nos muestra como con algunas habilidades como tener buena comunicación  y pensar fuera de lo ordinario podemos llegar a crear cosas en nuestro trabajo y no solo en el trabajo sino crear un cambio en nuestro mundo para poder mejorarlo aunque sea un poco.



Compilation of Tips from Pragmatic Programmer!

posted Apr 13, 2015, 3:03 PM by Rodrigo Alonso

  1. 1. Care about your craft. 
  2. Think! About your work. ← mantra
  3. Provide options, don't make lame excuses
  4. Don't live with broken windows
  5. Be a catalyst for change
  6. Remember the Big Picture
  7. Make quality a requirements issue
  8. Invest regularly in Your Knowledge Portfolio
  9. Critically analyze what you read and hear
  10. It's both what you say and the way you say it
  11. DRY—Don't Repeat Yourself
  12. Make it easy to reuse (and avoid duplication[tip11])
  13. Eliminate effects between unrelated things
  14. There are no final decisions
  15. Use tracer bullets to find the target
  16. Prototype to learn
  17. Program close to the problem domain
  18. Estimate to avoid surprises
  19. Iterate the schedule with the code
  20. Keep knowledge in plain text
  21. Use the power of command shells
  22. Use a single editor well
  23. Always use source code control
  24. Fix the problem, not the blame
  25. Don’t panic
  26. Select” isn’t broken
  27. Don’t assume it, prove it
  28. Learn a text manipulation language
  29. Write code that writes code
  30. you can’t write perfect software
  31. Design with contracts ← lazy code, strict to accept, promise little return
  32. Crash early
  33. If it can’t happen, use assertions to ensure that it won’t
  34. Use exceptions for exceptional problems
  35. Finish what you start
  36. Minimize coupling between modules
  37. Configure, don’t integrate
  38. Put abstractions in code, details in metadata
  39. Analyze workflow to improve concurrency
  40. Design using services
  41. Always design for concurrency
  42. Separate views from models
  43. Use blackboards to coordinate workflow
  44. Don’t program by coincidence
  45. Estimate the order of your algorithms
  46. Test your estimates
  47. Refactor early, refactor often
  48. Design to test
  49. Test your software, or your users will
  50. Don’t use wizard code you don’t understand
  51. Don’t gather requirements, dig for them
  52. Work with a user to think like a user
  53. Abstractions live longer than details
  54. Use a project glossary
  55. Don’t think outside the box, find the box
  56. Listen to nagging doubts--start when you’re ready
  57. Some things are better done than described
  58. Don’t be a slave to formal methods
  59. Expensive tools do not produce better designs
  60. Organize around functionality, not job functions
  61. Don’t use manual procedures
  62. Test early, test often, test automatically
  63. Coding ain’t done til all the tests run
  64. Use saboteurs to test your testing
  65. Test state coverage, not code coverage
  66. Find bugs once
  67. Treat english as just another programming language
  68. Build documentation in, don’t bolt it on
  69. Gently exceed your users’ expectations
  70. Sign your work

Pragmatic Programmer and What I learned

posted Apr 13, 2015, 3:02 PM by Rodrigo Alonso

I found this book really helpful towards the view of programming. I don't have much experience with software development, although I'm well on my way to learning how it's done. I think that this book was a great read since I'm gonna start implementing what I've learned as I learn how to code.

I'm assuming that people who normally read this book are people who have experience in the field, which means they have to change a lot of habits or “unlearn” several bad practices that they normally use. I on the other hand don't have that issue in most cases.

In other cases though, as I was reading the book I realized that all the programs I've written prior are utter crap. Even the programs written the first week did not follow the “guidelines” that I have started to become familiar with.

There were several aspects that were very technical and that I did not quite comprehend fully, but I believe that I was able to grasp a general idea of each chapter, and I compiled a list with the Tips that I found in the book.

This list I have saved on a file and will continually check it, refer to it, and make sure it becomes ingraned into my programming habits. Maybe not all at once, but continually getting better and improving the art of writing code. I have appended the list at the end of this document. 

I think the most important way that the book impacted me is in changing my mindset, accordingly with the Nearsoft Academy program. For as I was reading the book, I realized that a lot of the stuff mentioned has formed part of our training as interns. 

For example, we had a class with Julio about communication, which I believe was complemented with that section of the first chapter of the book. We saw a conference of the myth of the lone programmer, which I remembered as I read the section on pragmatic teams. 

One of the things that really stood out to me is the DRY principle, for a number of reasons. First off, my mentor mentions it when I sit with him and watch him write code. Secondly, this is a principle that I never included in my code. I always repeated myself, and even had a teacher who said “this is why copy-paste was invented”. I now realize that is an inefficient mistake, and a bad practice in programming. 

One of the things that I have been implementing as I read the book is to continually learn new things. It said that as a programmer it’s important to expand our personal knowledge database, which is something I’ve always enjoyed doing. 

Also In the third chapter there was a section that talks about learning how to use a simple text editor, and learning how to use it well. Therefore, during my time at NS I have been using vim to edit all my code, and even installed the plugin for Intellij so as to use vim commands to edit the text. 

I learned new stuff, like source code control, assertive programming and testing. Unit testing also being something that was implemented in our training program, and a concept I had never heard of before. 

Another key aspect that I learned about in this book is making code easy to read, and to build documentation in. I had never used documentation and my code has never been easy to read. My variables normally were three letters or shorter, to make writing it faster… and reading it a living hell. 

Once concept I did not fully comprehend was “tracer bullets”. I understand how they work in FPS games (Battlefield 3 FTW), but not quite how to implement it in code… I’ll have to revisit the book after having more experience “on the battlefield” to grasp a better understanding of how it works.

Last summer I took a class at the University of Arizona about systems thinking and requirements applied to any kind of engineering. I distinctly remember the teacher explained that the concepts were abstracted from software engineering, something which I kept remembering as I read the chapter on “Before the project”.

He always stressed the importance of writing good requirements and making sure the client agreed with those requirements. He also stressed on the importance of the iterative design-build-test cycle. I am now realizing where it all came from and why it’s implemented. 

Lastly, there is the lesson on being a team member, not being territorial in a “keep your paws off my code” sense. In this chapter, the book revisits concepts about the pragmatic philosophy in team views. 

I think the biggest challenge within teams would be the DRY principle, since several people are working on the same project. This book suggests appointing a librarian or focal points to parts of the project. In this manner, if someone has a question or an issue, they should speak first to the corresponding person in charge of that area. 

Another part of the book that changed my personal view was tip60, where teams are organized based on functionality, not function. Say, instead of grouping teams with all of the developers together and all testers together etc, group them by module. All of the people working on one specific function of the project together, to improve efficiency in communication. 

Those are the main concepts that I learned of this book this first time I read it. I’ll revisit it in a couple months to learn more about pragmatic programming, and keep it as a reference henceforth. Also, I’ll leave the list of tips I compiled in another post.

tarea semana 1

posted Apr 13, 2015, 3:01 PM by aarias@nearsoft.com

Mi reseña trata sobre varias lecturas y videos que estudie en esta semana, aprendí

cosas muy interesantes que comentare en unos momentos. Primero que nada me

gustaría comentar algo importante, en estos momentos mi vida esta tomando un curso

increíble, se me dio la oportunidad de formar parte de la academia de Nearsoft y estoy

muy emocionado por aprender tanto como sea posible, mi objetivo es ser un gran

profesional, quizá un gran desarrollador de software, un emprendedor o quizá dueño de

mi propia compañía en un futuro.

Con mis lecturas aprendí que para lograr esto tengo que pensar fuera de lo ordinario, ver

las cosas diferentes, a que me refiero con esto, primeramente hablando un poco sobre

tratar de ser innovador, aprendí que muchas grandes ideas no salen a la luz por un

terrible miedo al fracaso, esto es terrible ya que si nos ponemos a pensar un poco sobre

esto. ¿Cuantas de esas ideas en este momento estarían haciendo nuestra vida mas

fácil?, realmente el miedo esta siendo un terrible factor que debemos cambiar, creo que

debemos tener mas iniciativa para realmente plantear nuestras ideas y ver si realmente

es una buena idea para así llevarla acabo y hacer la diferencia.

También es muy importante saber como comunicarnos con las personas, para que

realmente ellos vean la importancia del cambio, que se den cuenta que lo que estamos

tratando de hacer es algo bueno, la gente tiene miedo al cambio, eso lo mencionan en

las lecturas, es algo que realmente ya se sabe, pero entonces por que no tratar de hacer

algo para cambiarlo, creo que para hacer esto tendríamos que tener una cultura de

innovación desde que somos pequeños y que no se nos acostumbre a solo aprender

algo y que dependamos de ello.

Algo muy importante en comunicarse con las personas que logre aprender con mis

lecturas, es que debemos no solo ser buenos en lo que estamos hablando con ellos, las

personas necesitan sentirse conectados humanamente con nosotros para que realmente

nos entiendan y así poder tener un impacto con ellos, esto tiene mucho que ver con las

ventas, particularmente hablando sobre vender algún producto en el cual el vendedor

tiene que tener empatía para saber de que forma hablar con las personas que están

sufriendo algún problema, esto para así darles una correcta solución, claro que no solo

es eso ,también se mencionaron otras formas de crear resonancia, palabra que

realmente me gusto, como ser genuino, tratar a nuestra audiencia como si fueran los

héroes y nosotros sus mentores, cosa que siempre pensé que era al revés.

Para lograr un cambio la idea que estamos planteando alas personas debe ser buena, y

esto es algo increíblemente importante que logre aprender , debemos saber si el

producto que vamos a hacer, o el servicio será utilizado. Así que mientras mas rápido

sepamos si nuestro producto no tendrá éxito tendremos aun tiempo y recursos para

tomar otras alternativas, esto es una de las cosas mas importantes que aprendí en mi

tarea de esta semana llamado Pretotyping,

Trata sobre como no gastar miles de dólares desarrollando un producto que realmente

no será utilizado, esto sin duda es algo que todo emprendedor o empresa debe tener

muy en cuenta, personalmente aprendí ciertas cosas que al momento de pensar

desarrollar cierta aplicación no tomaba en cuenta, como que todas las personas somos

diferentes, no tratar de crear algo que sea lo mejor sino tratar de crear algo que de

solución a las personas, tomando en cuenta sus gustos y diferencias.

Otra es que nosotros somos mejores trabajando en equipo, esto es lo que comprendí de

un video sobre Jonathan Haid, personalmente no comparto completamente sus ideas

pero creo que es interesante lo que comenta. Al igual que todos somos iguales, y todos

tenemos las mismas capacidades, esto es totalmente cierto, a lo largo de mi vida eh

conocido muchos tipos de personas realmente buenas en lo que hacen, incluso

personas con discapacidades que son increíbles, ya sea en nuestra área, o en alguna

otra ,así que estoy de acuerdo , incluso si llegara a tener un equipo y tuviera que

contratar personal tenerlo muy en cuenta.

Algo del material que mas me gusto sobre algunos videos fue sobre el cambio de la

tecnología, y como esta avanzando de manera increíble, hasta llegar el punto de poder

correr juegos directamente desde nuestros navegadores web, o incluso una terminal

Linux, tiempo atrás para instalar un juego tenias que instalarlo como con 5 discos en mi

computadora. Claro esto se debe y estoy de acuerdo con el autor del video, a la

popularidad del lenguaje, en este caso JavaScript, me pareció muy interesante que este

lenguaje se creo en tan solo 10 días y ver a lo que se ha llegado, Investigando un poco

sobre el mismo porque me pareció muy interesante, encontré que actualmente se están

desarrollando muchísimas librerías geniales en este lenguaje incluso plataformas de

tecnologías de entrega de mensajes en tiempo real, hasta programación de robots , creo

que si queremos ser innovadores y progresar ,estamos obligados a conocer todas estas

tecnologías para sacar el mayor provecho de las mismas.

Algo muy importante también es el uso de nuestro correo, personalmente no me había

puesto a pensar lo importante que el correo seria en mi carrera, aprendí como ser mas

productivo con el y darle el tiempo que realmente se merece, es importante ser lo mas

productivos posibles y creo que es el tiempo que ponemos en checar nuestro Email es

importante, así como establecer algunos métodos para agilizar nuestras respuestas de

Email.

En resumen creo que para lograr ser un excelente profesional en nuestra carrera

debemos ser capaces de dominar muchas habilidades que se mencionaron en las

lecturas y videos que nos asignaron esta semana ,como poder hablar correctamente con

las personas, mostrar empatía, tener buena comunicación, y no tener miedo al fracaso,

para así poder llevar acabo nuestro proyectos y si llegasen a fallar, aprender de los

errores y así tener mas experiencia y tener mas éxito en nuestra vida, esto es mi reseña

de mi tarea, lo enfoque totalmente en mi carrera profesional y estoy muy seguro que todo

lo antes mencionado me ayudara mucho en mi vida.

Software is Just Another Tool

posted Apr 13, 2015, 3:00 PM by Rodrigo Alonso

This week we were assigned to conduct three experiments to solve three problems. This was to learn that software is not the solution to everything, but is just another tool used to solve the problems we face day to day. 

Some of the videos we watched this week were related to last weeks videos, since we saw some of the quantum machine videos, this week some were related. Several of them were on Feynman, a person who I didn't really know much about before. 

After watching the videos I have come to learn that Feynman was quite the character. He was a really cool person who made a lot of contributions to quantum physics and quantum computing. 

A part I really loved about the video was when he told a physicist (I forget the name) “I redid your calculations last night, and you're correct” and the guy was like “wait, what?! It took me six months! What do you mean you 'redid them last night'?” 

Although his lecture on the scientific method had very bad audio, I liked the way he teaches. It's true that he was a great explainer apparently. He seemed to teach with good humor and simple concepts. 

The videos by Seth Lloyd were a lot more techy, talking about quantum computing and “programming the universe”. What I learned from these videos is that the universe is infinitely more complex than we can ever fully understand as humans. I found the analogy of the universe itself is a computer in which it's elemental particles are making calculations and changing their state based on interaction. 

There was also testing subject, a video that talks about Netflix service. Big systems such as this one are hard to make without any flaws. So the system has to be tested exhaustively. 

I learned through this video that there is more to testing than just unit testing. There's several strategies to testing, like simian army, canary deployments, and a lot more. I think the important thing to testing is to always test before deployment. 

Each new feature or change should be tested, to avoid issues later on in users' homes. The video also talks about several issues that they've had to deal with. As in everything else, it's utterly important to not make the same mistake twice. If an issue is found in testing, it should only be found once, and fixed. 

The mentality shouldn't be “found an issue- report it” but “fixed an issue- moving to the next one” and that issue should not appear again. The problem is not finding bugs but fixing them. 

The problem then becomes the motivation in engineers, because a lot of them don't like testing. A suggestion would be to not just give them red boxes, but green boxes from time to time, to keep up morale. 

I also learned that when something fails, the ideal thing is to find the root cause of that fail. Have a culture of fixing problems in a way that the next time it breaks fixing it will be easier. 

Testing in bigger systems (like Google) are a lot more complex. Google actually built their own continuous build system where there could be simultaneous tests that didn't interfere with one another. They then have a matrix of changes and tests where you can identify the test, the change and where it broke. Ingenious. 

At first I thought that test engineering was the QA job, but my mentor explained the difference last week, and this week there was a video where they mentioned it. Test engineering is not QA, but has different roles. I have now a better understanding of test engineering, and testing in production, and testing during development, but am now slightly confused as to what QA actually does… 

Learning how to code! Or at least trying to....

posted Apr 13, 2015, 2:59 PM by Rodrigo Alonso

This week I learned a lot about coding. Mostly about OOP since that's what the classes are about. I am really learning quite a lot of new stuff about this, but most importantly: that all the coding I've done is garbage. 


I say that because of all the concepts, best practices, suggestions and conventions that I've been learning this week, which I had no idea existed. But again, failure is knowledge, and I'm getting the hang of this. 


Speaking of failure, I had quite some issues installing a Java IDE to solve this weeks coding exercise: first off, I had no idea that jdk and jre were needed. After asking around and a little research I managed to make a project in Java. 


With the videos and readings I learned about a lot of useful tools to solve the big data code problem. I learned about map reduce, mahout library and unit testing. 

I spoke with my mentor about unit testing, and he explained how it works and why it's implemented.


With the videos I learned about machine learning, that it's not so complicated to implement as it seems. I had seen a series of videos from coursera about machine learning, and this video consolidated all the information that I had learned with that series. 


There was a video on Ipv6, where the history of the internet is explained, which I didn't know about. It explained the limits of Ipv4 and how it was saturated very quickly. We basically live on the internet now and it's full of devices connected. Personally I have a cellphone, two laptops, an xbox and a kindle connected to the internet… and that's just me. 


There were some very interesting videos on quantum physics, mechanics and computing, which is a subject that I've always found very interesting. I had no idea that Google and NASA were on a joint mission to build a functional quantum computer. 


This week there were also some life lesson videos on leadership, how to give presentations, and a perspective change. This last one was called the pale blue dot, and showed an image of the “the pale blue dot”, which is earth taken from space, hardly visible. 


This small speck in the universe is the place we live in, with all the other human beings, and it's the only home we have and the only home we'll know, and therefore it is important that we take care of the planet and get along with everyone in it as best we can. 


This takes us to the leadership video. In this video it explains how to deal with people better. Most of the time, people want to always be right, to always have an opinion, and to always give advice. In the video there was an exercise where people would walk up to random strangers and say “I want to get better at X”, and they'd receive advice. The advice had to be written down, and thanked for, without replying anything.  


I think the main message of the whole talk was to be openminded enough to ask for advice, and when that advice is given, to just say thank you and write it down.  Not to reply. Also, I think that one key aspect of leadership in any kind of relationship is to forget the baggage. We can't fix the past, so just forget what's behind and move on. 


Another video was about how to conduct a presentation that is worthwhile for the audience, and how to achieve the goal of a presentation using basic tools, the most important ones being: Make them think, and make them feel.


Audience participation is important because it makes them feel important. A positive feeling is a good thing so they relate the presentation material to good feelings. When the audience participates there should be no wrong answer. Always ask questions that are about opinions. When given opinions never reply with “yes… but”, instead reply with “yes… and”. That way you make sure the participants point of view is of equal value as yours, and there is no interest conflict or competition to be right. 


The best way to be able to evoke emotion into the audience is by living said emotion in front of them. If you want to evoke happiness, be happy while you speak. 


The most important lesson for me this week was that failure is the best way to gain knowledge. I learned a lot about how coding works and IDEs by not being able to write a “hello world” in java. 

What's Go, Scala and Dart?

posted Apr 13, 2015, 2:56 PM by Rodrigo Alonso

Coding started this week for us interns, part of the nearsoft academy. Three problems in three languanges: Go, Scala and Dart. When I first saw the assignment I asked another intern, "What's Go, Scala and Dart?". Yep, that's how lost I was.

There were  also 10 hours of videos, which was quite a stretch for this week, but it was fun to do nonetheless. I didn't quite finish the programs, and after writing a couple of them I realized I made a huge mistake, by writing them with input from the console instead of from a text file. Sadly I didn't have enough time to fix those issues, but the last program I wrote, I did it correctly.


From this experience I learned that it is important to take into consideration all requirements into the code that is being written. I wasn't aware of the requirement of being able to read text file input. Frankly, I had only used console input all my life. The other interns then explained to me that I did it wrong.


At the end of the week, this requirement was published in the skype conversation, but by that time it was way too late to change it. Like the talk I gave today, I failed writing these programs, but in failing I learned a valuable lesson: Requirements are extremely important! And if I don't know a requirement, I should immediately ask instead of doing the wrong thing.


Another lesson learned is that I write very inneffective code. I am well aware that the first program I wrote is very very bad code. Especially after reading the first few chapters of pragmatic programmer. I like to think that by the time I wrote that same problem in the third language, the code was better written. Not the best, most elegant efficient code, but granted not the crappy code I wrote at first. Especially because I included the requirement to read a text file. (Go was the first language, and Dart the third)


So having said that, there were several videos that we had to see. This time they were more “techy” than last week, but also very valuable lessons for working as developers.


The first one was called “the myth of the genius programmer” and explains a very important issue for developers. The Genius Programmer does not exist. It then goes on to explain some tips on how to develop effective software.


I would think that the most important part of this video is to lose the ego. An egotistic proud programmer will hide his code, be territorial, won't want to admit failure, and will not collaborate. All of these are terrible habits because they forget that no good software was built by one person.

The same guys that gave that conference give another one, called organizational manipulation. It explains how ideal companies work, how most companies work, and tips on how to change your company for the better. I found this video very interesting, because some (dare I say most) of the attributes that ideal companies have are implemented here at Nearsoft.


Another of the videos presents the importance of performance. In the society that we live in today most everything is mobile, and most people want everything immediately. People don't want to wait for websites to load anymore, especially not on mobile. A sometimes the users are on their mobile, and don't have WiFi access so they use their mobile phone internet service. This presents the issue of a slower network (maybe 3G) and data usage.


Clients don't want to wait for the web page to load, and they don't want to overpass their data limits. This is why performance matters in websites so much these days. Colt McAnlis explains this issue and explains how to use some tools to measure performance, find out exactly where the problem lies and what dependencies that need to be resolved before the web pabe loads causes the low performance.


There was a series of three videos explaining compression algorithms. It goes through the history of morse code, and the way that computers started implementing the variable length code that morse code uses.


It explains the way that Variable Length Code works and how it started to develop. It explained the probability functions used and how the most important algorithms were created. Where winrar, winzip, gzip come from, etc. It talkes about the most important ones, being the LZ family based on the LZ77 and LZ78, and Markov Chains.


The most interesting video this week for me was Developing Expertise, because Dave goes through the stages of learning a new skill. This was the most interesting one for me, since I'm learning a lot of new skills this week, and recognized several characteristics of the stages that I'm going/will go through. Going from Novice, to Advanced Beginner, to Component, to Proficient, to Expert. This model is called the Dreyfus Model. Several hilarious anecdotes were said during this video, about the speaker learning how to fly. A key phrase in that talk was “Don't try to race sheep, don't try to herd race horses”. Basically it talks about novices doing novice works, and experts doing expert things.


Another video was about the creator of CouchDB, how we didn't want to have this ordinary job where he's working for other people, and decided to go work on his own stuff. It worked pretty well for him, with IBM joining him on his project. At the end his conclusion about this whole journey that he took was “I'm the guy who gets paid to work on cool stuff”.


So to keep this short, cause the assignment was to write two page reviews, there were a couple other videos, by Linda who presented several ideas on agile software development. Speaking with my mentor, he explained that agile is a methodology that is used here at nearsoft. In the videos though, Linda explains that this is more of a mindset than a methodology. We are not to do agile, but to be agile.


There were also a couple videos where Linda is interviewed, although not necessarily on the same subjects on the previous videos. Linda speaks about prejudices and stereotypes. She explains that these stereotypes are unconscious, that it is the way that we perceive the world based on what we observe.


Therefore, two different people who  share an experience have different memories of said experience. This is because we as human beings interpret everything based on what we know. Everything we see and perceive from the world is distorted by previous knowledge we have, which happens to be different from everybody else.

This is important, because it reminds me of a talk we had with Julio about perception and effective communication. What we perceive is not what the client or mentor perceives, and therefore we need to learn to communicate effectively what we actually want the receiver of the message to interpret.

Reset!

posted Apr 13, 2015, 2:54 PM by Rodrigo Alonso

This week the assignment in the academy was to learn. Not necessarily technologies that will be needed during our course through the academy, but more about soft skills needed to adapt to the culture at Nearsoft.


What I have understood throughout my interaction with Nearsoftonians and the orientation classes during my two weeks, is that Nearsoft is about teamwork. One of the videos seen talked about the religious experience of the diminishing of the “I” to become the “we”.


Although I disagree with his views on “religion” in the way he put it (let's face it, it's extremely hard to agree with someone on religion) he makes an interesting point about teamwork. When a group of people comes together united under one goal, amazing things happen.


When we understand that no man is an island, but part of a continent, we face the challenge of communication; even harder: effective communication. The ability to give a presentation, message or meeting, where everyone understood what the speaker intended to say.


This is a challenge because every listener in the room comes from a different background and has a different way of thinking. They have their own worries and their own desires. So the challenge comes in uniting them under one same rallying cry—willingly.


One of the readings was a whole book explaining how to be able to tune a message to the “frequency of resonance” of the audience. Personally I believe that this doesn't apply only to presentations, but to effective communication of all kind, especially among teams or with clients.


The tool most used for communication in the work place is the tried and true email and skype. With the ideas presented in a google tech talk and the ones given to us by Julio in the communications class, I propose a small system to use these tools.


This system consists of identifying and separating the important and not-so-important email. Three large categories: Urgent, Important, Not-so-important. The urgent email would be client or team work related stuff. Say if the client's server is down and needs help, that seems pretty urgent. Important stuff is stuff that definitely needs attending, but not necessarily immediate. Not-so-important could be spam-ish stuff.


This is done in order to be able to use email more effectively and not waste time. Urgent email should be checked every few often. Maybe implement some sort of desktop notifications, or phone notifications for emails that come from the client.   


The Important email should be checked every hour or so. This is because humans are not capable of multi-tasking, despite what many people try to argue. If you lose focus or attention on what you were doing to check email you'll lose the idea, and it will waste time trying to recover it.


Distractions consume a LOT more time than we're aware of. The idea is to NOT check the important email during times of concentration. But since they are important, they should be checked every period or so of time, and act immediately on it. Say you got an email that requires a response, but it's not urgent. You let it sit there while you finish your hour or so of concentrated work, or until you can come to a pause. You then check the email and respond immediately. Having resolved the issue, go back to work. Effective and non-time consuming.


Part of the vision of nearsoft is to become a leader in innovation in Mexico, and some of the videos and readings we saw were very interesting regarding innovation. It's incredible to see how wrong I was on innovation.


A very interesting read was about the 10 myths of innovation. There was also two videos of lectures from the author talking about innovation, where he exposes his research on innovation. I found it so interesting, I purchased his book. To my surprise, I believed several of the myths of innovation. Too extensive to go into it here, but basically he says that innovation comes from hard work, smart work, dedication, and most importantly: the freedom to think.


The idea is to not be afraid of ideas, but to explore them before killing them. One safe way to explore new ideas and their acceptance into market is called pretotyping. This concept was developed by Alberto Savoia who studied success and flops in business.


He realized that some ideas that had great acceptance and were invested in were total flops, while other rejected ideas became success. So he proposes a way to test the ideas before actually investing time and money in them.


The best example would be speech-to-text by ibm. Instead of investing time and money in building a machine that converts speech-to-text, have a person in another room typing what the user is saying. Then bring in customers to test the “machine” and see if they would buy it. Turns out they wouldn't buy it, and they saved loads of time and money by NOT building something that no one would buy.

On the subject of technology, there were a couple of videos on JavaScript, how it's used, what it has achieved, and what could be the future of it. Despite not knowing much about the language, I found them quite interesting.


To wrap things up, there were also several life lessons learned during this week. About how personality can change, about how fast learning beats already known knowledge, about the perception of problems and oneself against them, about how society sets labels on people and can't get past them, and even about how relationships die.


All in all there was a lot of learning material, a lot to ponder on, and most importantly, a lot of habits and ways of thinking to adapt to myself. I consider myself a flexible person who will embrace change and pursue it, if it seems better. I will try to embrace all the stuff that promotes positive change in myself learned this week, and seek to make them my habits, mentality, and culture.

Green Field Project

posted Apr 9, 2015, 3:50 PM by Unknown user   [ updated Apr 9, 2015, 3:55 PM ]

Although we didn't have to write a summary of what we learned during this week, I decided to do so since I missed the first week assignment:

Lessons learned from watching Videos:

    This week, the videos discussed a lot about what you can do as a programmer to improve your performance, as an individual and as a team. Every team starts with a problem and works to solve it. In the Agile Practices videos, it was displayed how we can implement different methods (or practices) to increase team productivity by working together and increasing our ability to communicate and thus come to solve the problem at hand. All of the practices demonstrated are something that teams should use to improve the skill of the team as a whole and as individuals. As interns, we need to know these practices because they are used by every team, and it is good to start implementing these practices early on and get accustomed to them. This also ties into the video about “how do we heal medicine?” We are constantly trying to improve as an individual and as a team. When something goes wrong, instead of putting the blame on someone else, you should try to see where you (as a team or as an individual) failed. From there, you create a solution, and then, hopefully, when the problem is encountered again, it can easily be fixed (or avoided).
    Another good point that I noted from the videos (and one article) was about being on time. Tardiness is not an uncommon thing. It isn't something that only happens in the work place, but all through your life. We're late for school, work and social events. Being late is something that has become apart of our daily lives. In the article, it explains how we can avoid being late, and I agree with every suggestion, but its not always easy for people to do such things. We have to make being on time a habit rather than force the idea. This ties into the talk about optimism, and how many people believe that bad things wont happen to them, but to the next guy. I tied this to being late in this way: we never intend to be late, but we end up being late. Those who are consistently late (and in denial about it) are always the ones to say, “Yeah I can meet you for lunch at noon,” and show up 30 minutes late. They'll deny their lateness and make an excuse rather than take responsibility for it. This also ties into the point about “anticipation makes us happy.” I'm not sure the anticipation of writing a few paragraphs about what you learned on a Friday is the type of anticipation that makes anyone happy, but we do it and it sometimes causes more stress than joy. But those who rush to meet the deadline to send in their paper will make light of it throughout the week and say that they will have it done on time “this time” and are still rushing to beat the clock on Friday night (this, of course, isn't me). Optimism makes us happy, and even if its unrealistic, it keeps us hopeful. Hopeful behavior can be risky, but nothing is ever achieved unless a risk was taken.


Lessons Learned in Class:

    In class this week, we reviewed previous concepts such as the five principles of class design (SOLID) . We went over inheritance, discussed the good and bad parts of it, and compared its use again composition. Usually, if you have doubts about a class with inheritance, you should use composition. If you have no doubts, then use inheritance. In the end, we did a complete review of the concepts we used the past two weeks about Object Oriented Programming, and then worked on “real life problems” which was to design a a chat server. We worked as a group to come up with back end components, classes and methods. We then went over the hardest (or most interesting) problems to solve. It was something I enjoyed doing because sometimes I do not always understand how to do things, and by having us work as a group and answer questions about problems we need solved helps me see other peoples views of how to solve a problem.  

1-10 of 48