Destacada

Yoda says: Always pass on what you have learned

#Mastery00 – An introduction to the course.

This is the first post on my new blog. I’m just getting started, so I’d like to introduce me.

My name is Oscar; i’m studying a BS in Computer science. I’m in love with music and the life! and I think that if you put enough effort on something, you always will get what you want. Also, I love photography, thats one of the things that I think makes this life better, because it gives me the opportunity to share with others how I can see the world, and sometimes, you can share emotions too. I have a meme page with over 70k followers, and yes, I do memes, but also i take it from other pages, the watermark is always there, so our followers can know where is the meme coming from. I have a little dog, his name is Pirata; he’s always making my days better and its more effective than a home alarm! For me, mathematics are present in everything, and if something has todo with numbers or patterns, i’m gonna be as focused as possible.

I took this picture when the wildfires were going on along Jalisco . Thats one of my favorite pictures because the message it carries.

But let’s get back to the topic

I think that this kind of courses (the ones that use modern educative methods) are the greatest because education has evolved based on its reasons. This “connected courses” thing will let us learn in a different way by reading what our classmates have concluded, and by interchanging opinions and perspectives, making our criteria and concepts better. I’m Trying to connect my own website with this blog, but I think that will have to wait until the next week, because i have a lot of projects going on. I’m hoping to give the best of me in this course and to get the most knowledge that I can.

Cyber-Management 2077

Photo by Wikimedia Commons.

Probablemente en este momento estés pensando: ¿A caso este tipo se quire colgar de la fama del poderosísimo Cybertruck? o ¿es acaso otra broma futurista de mal gusto? vamos a averiguarlo. A pesar de que relacionamos el prefijo cyber con lo futurista, lo tecnológico o lo modenro, la palabra perse no significa eso. Esta palabra viene del griego y su significado es timonel(sí, esa persona que dirige los navíos). ¿Ahora comprendes hacia dónde va el asunto? No estés tan seguro.

Ser administrador puede parecer un trabajo tentador, pues te toca comandar y organizar, así que podrías asumir que tienes el control de todo lo que sucede y simplemente dar órdenes…

Pues no mi ciela' te dejamos los mejores memes | Gluc.mx

Primero que nada, es necesario comprender que a pesar de que puedas tener toda la experiencia, no lo sabes todo. Por ello, es necesario saber aceptar que en algunas situaciones vas a requerir ayuda y podrías acudir con una consultora, un colega o bien con tu mismo equipo de trabajo; esto abre una nueva interrogante: ¿Qué otras cualidades necesita un gerente? Podemos listarlas así:

  • Lidera con el corazón
  • Confía en tus instintos
  • Inspira pasión por lo que hacen en tu equipo de trabajo
  • Desarrolla un buen olfato para la mierda.
Vayamos un poco más profundo acerca de esto

Necesitas poner tu corazón en el juego porque es la única forma en la que las personas responderán de la misma forma (No, no me refiero a que instaures una red poliamorosa en tu espacio de trabajo, si no que se note que amas lo que haces). Debes confiar en tus instintos para tomar decisiones, un administrador no asertivo no logrará transmitir esa confianza necesaria hacia el equipo. Finalmente debes estar alerta para encontrar esas posibles situaciones que puedan hundir tu proyecto, por eso es importante que seas bueno reconociendo ese fétido olor.

Ahora pasemos a este punto: ¿Por qué un buen gerente no puede ser considerado el timonel del barco? la respuesta es sencilla: un buen gerente no necesita dirigir cada movimiento de la jugada porque puede confiar en el equipo que construyó para llevarla a cabo. Además, un buen gerente puede ser reconocido por la forma en la que sus delegados piensan en él (Recuerda que como administrador de proyectos, tu activo más importante es tu equipo de trabajo).

Finalmente, uno de los consejos más importantes para ser un buen gerente es:

Escucha más de lo que hablas.

¿Por qué esto es importante? porque un buen gerente está receptivo a su entorno, como un buen general militar, tienes que conocer tu campo de batalla y dominarlo, y eso lo puedes lograr si pones atención a los detalles, en lugar de asumirlos. Esto puede resultar una tarea difícil, pues muchas veces por la idea tradicionalista, tus subordinados pueden sentirse en un nivel inferior que tu o simplemente no tener la confianza suficiente para decirte las cosas, así que puedes generar espacios seguros donde puedan escribir feedback sobre cómo va tu administración para que esta pueda mejorar y ellos puedan sentirse seguros y contentos.

Project Management 102

Photo by Austin Distel

Volvamos a los 4 principios fundamentales de la administración que mencioné en una de mis entradas anteriores; para ser un buen administrador debes saber escoger a las personas indicadas, darles el trabajo correcto, construir equipos y motivarlos. Es importante que sepas tratar con las personas y el cómo organizarlas, pues también hay que considerar que puede haber brechas generacionales entre los equipos, o estos pueden ser muy grandes o muy pequeños, es decir, existen muchos factores a considerar para lograr un mejor resultado.

Antiguamente se tenía la idea de un jefe tenía que imponer respeto y en algunos casos miedo. Esto, además de ser absurdo, no funciona. Imponer miedo sobre las personas no funciona como motivación, pues solo lograrás crear un ambiente de inseguridad y poca certeza, que traerá como consecuencia inseguridad en las personas, conllevando a que estas no tomen riesgos. Muchas veces, el tomar riesgos puede beneficiar de sobremanera el desarrollo del proyecto, pero si el ambiente de trabajo no permite a las personas que se sientan libres de tomar riesgos y en algunos casos equivocarse, todo se tornará hostil y terminaremos con un ambiente de trabajo tóxico (Justo lo que queremos evitar por el bien del proyecto).

Una buena administración ayudará a que las condiciones de trabajo sean mejores para tus delegados y también mantendrá satisfecho al cliente, aunque esto no es del todo sencillo. Uno de los aspectos más importantes para tratar con tu cliente son los plazos que debes de respetar para que este esté contento (Además de evitarte problemas legales y multas, pues recuerda que hay un contrato que respalda el proyecto). Sin embargo, tienes que considerar que no importa que tan simple o compleja sea la solución que estás desarrollando, el trabajo no se va a poder completar a tiempo si el tiempo estimado es demasiado corto como para implementar la solución. Por ello, es de suma importancia que a tu cliente le des plazos que sean verdaderamente alcanzables a que le des un plazo que suene bien (Ya sea por decisiones comerciales o simplemente por quedar bien con el cliente, pues al final fallarás).

Para finalizar este post, me gustaría recordarte que en la industria del software y la tecnología existen mil formas de hacer dinero. Imagínate que en este momento te propongo una idea en la que nuestros usuarios finales no van a pagar ni un solo centavo por nuestro servicio; probablemente me vas a tildar de loco pero, ¿Cómo crees que funciona facebook?… Esta industria nos permite generar modelos de negocio disruptivos que rompen con lo tradicional y pueden generar gran valor. Por ello, me gustaría concluir esta entrada con una frase de uno de los grandes innovadores del siglo XXI “Think different“.

Administración de proyectos 101

Foto por Aleks Dorohovich

El mundo está lleno de proyectos. nos encontramos rodeados por productos y servicios que en su primer etapa fueron ideas que después se transformaron en proyectos para poder llegar a un producto final. Cualquier proyecto requiere alguien que lleve el control de todas las actividades que son necesarias para alcanzar el objetivo. Cuando se trata de un proyecto pequeño, tú mismo cubres todos los roles (Como cuando planeas sembrar una nueva planta en tu jardín o tienes que desarrollar un pequeño proyecto escolar) pero cuando el proyecto es enorme, es cuando las cosas se ponen interesantes.

Como administrador debes ser capaz de planear, organizar, y comunicarte para lograr armonía en tu flujo de trabajo y en el grupo de quienes están a tu cargo. Antes de comenzar a aprender sobre administración de proyectos, tenemos que comprender una cosa: esto se trata en su mayoría sobre las personas; obviamente el proyecto es lo importante, pues es la meta por la cual todo el equipo se ha congregado, pero tu misión como administrador es hacer que las cosas funcionen y, en otras palabras, eso significa tratar con personas: con tus clientes, con tu equipo de trabajo e incluso con tu familia cuando tienes que quedarte a resolver pendientes o detalles que no se contemplaron durante el diseño (Sí, puedes ser el mejor gerente del mundo pero los imprevistsos no distinguen personas).

Imagina ahora que tienes un proyecto a cargo; como este es un blog orientado a las ciencias computacionales, nos enfocaremos en un proyecto de software. Tu misión es construir un producto con algunas características innovadoras, requieres de nuevas tecnologías y un equipo de 30 personas para lograr el objetivo. Si bien, tu vas a darle la cara al cliente, debes saber que tu proyecto no solo se trata del producto final, sino de quienes van a construir ese proyecto final. Por ello, es super importante que sepas contratar personas, pues necesitas el capital humano correcto para realizar la actividad, pues no vas a contratar a un zapatero para que prepare pizzas. Además, considera que contratar a las personas correctas traerá un impacto tremendo en tu productividad.

Además de esto, tienes que considerar cómo hacer que esa persona trabaje en lo que más se le acomoda, o en otras palabras, que haga match con su trabajo; imagina que tienes dos programadores con casi las mismas habilidades técnicas. La única diferencia entre ambos es que a uno le encanta jugar videojuegos y el otro pasa sus días tomando fotografías de todas las cosas que le parecen interesantes. Estás desarrollando un videojuego en realidad aumentada, así que, ¿A quién crees que le debería tocar la parte de jugabilidad y quién se debería encargar del reconocimiento de objetos? Si tu equipo tiene los trabajos correctos, tus probabilidades de éxito y de entregar a tiempo incrementarán. (Sí, tu trabajo como administrador también es dar un estimado de tiempo para realizar un proyecto.)

Una sola persona no va a desarrollar una característica completa, por eso es importante que dentro de tu plantilla de trabajo construyas equipos que se encargarán de desarrollar características, pues facilitas la comunicación interna y ayudas a que el flujo de trabajo sea mejor. Además, es necesario que mantengas a tu capital humano motivado. Si no se encuentran en la misma sintonía y no tienen iniciativa para hacer las cosas, cumplir las metas se volverá más difícil.

¿Cómo funciona la industria que ha generado tantos millonarios en tan poco tiempo?

Tal como cualquier otra industria, la economía de la ingeniería del software está basada en los mismos principios financieros de todos los negocios. En pocas palabras, se busca tomar decisiones inteligentes que permitan incrementar el valor de la empresa y tener las mejores relaciones costo-beneficio posibles. Como casi todo en la vida, podemos resumir esto en decisiones, decisiones que tomaremos basados en la información que los diferentes rubros de las finanzas nos arrojan.

Cuidar el flujo de efectivo es una de las actividades más importantes, pues es lo que mantiene a la empresa viva. En pocas palabras, el flujo de efectivo se resume en la cantidad de dinero que ingresa a la compañía y la cantidad que sale en un periodo de tiempo. Buscamos tener el mayor rendimiento costo/beneficio, pero, ¿cómo podemos incrementar eso? Analicemos los costos fijos; ¿sabías que un buen programador puede resultar hasta 10 veces mejor que uno mediocre? Desde ese tipo de casos, podemos darnos cuenta que las decisiones inteligentes nos permiten mejorar nuestra productividad y nuestra rentabilidad. Si quieres aprender más acerca de este tema, te recomiendo esta lectura que analiza de manera más amplia todo el rubro de la economía en la ingeniería de software.

New course, new blog

This is not my first time writing a blog, However, i like to experiment with my things and what i like to do. This last months i’ve been rediscovering myself and i think that i should be doing new things, such as learning another plucked string instrument in order to break some patterns in my head that have been generated by always playing in the standard EADGBe tuning of the guitar. I think the school is another place where I should experiment. So, this is not my first time blogging, but I think this should be my first time speaking in front of a camera, having in mind that this should help me to improve my communication skills. Stay tuned, soon you will be able to see this little human speaking to the world about project management.

Combat dunk: Agility or objects?

Object-Oriented Programming and the principles it promotes make a big difference in creating large scale, maintainable code. It allows developers to design and write code in more productive ways than were possible with procedural languages. The same happens with the agile methodologies; agile is a set of methodologies which share development values. Trying to be more specific, i’m going to focus on Scrum.

A general view from Scrum

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value, looking for effective team collaboration on complex products. A scrum team is divided into three roles:

Scrum values
  • Scrum Master:  is a servant-leader for the Scrum Team. Is responsible for promoting and supporting Scrum. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
  • Product Owner: is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
  • Development Team: consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.

Nice, nice, there are roles and good things but, How does exactly scrum works?

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.  The Scrum Events are:

  • Sprint: is a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
  • Sprint Planning: is the work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. Usually is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
  • Daily Scrum: is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. 
  • Sprint Review:  is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. There could have been a single deployment or many deployments during a Sprint which lead up to that Increment to be inspected.  This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. 
  •  Sprint Retrospective: is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. It occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.

What is the backlog?

Is a breakdown of work to be done. Contains an ordered list of product requirements that a scrum team maintains for a product. Common formats include user stories and use cases. The requirements define features, bug fixes, non-functional requirements, etc.—whatever must be done to deliver a viable product.


MVP ( Minimum viable product)

As you could read, Scrum is always focused on the Done, which we are going to call MVP. This is because scrum looks to deliver a functioning viable product after each sprint. This helps with the client satisfaction and to the productivity of the team.

Finally, I hope that reading each scrum activity and with the help of the first image, you have a better idea of what Scrum is and of course, Agile came to revolutionize how the software is made.

Baby you can drive my car

I’m glad to introduce you to a new ally. Call it TDD

Do you know what you get when you combine an iterative process, an incremental one and then add a pinch of testing? you come up with Test Driven Development. TDD is a software development process that relies on the repetition of a very short development cycle: first the developer writes an automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck stated that TDD encourages simple designs and inspires confidence. The concept is simple: write a test, write code, test it, do it again.

This is TDD in a nutshell

Here are the steps:

  1. Write a test that defines a function or improvements of a function. this helps the developer to focus on the requirements before writing the code.
  2. Run all tests and see if the new test fails. The new test should fail for the expected reason. This step increases the developer’s confidence in the new test.
  3. Write the code that causes the test to pass. it doesn’t matter if it is the ugliest thing you have done, that is acceptable because it will be improved and honed in Step 5.
  4. Run tests: If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features.
  5. Refactor code: Now put the dressing on your code, make it look fancy and be sure its readability is good.
  6. Repeat!

In a few words, TDD implies: write only enough of a unit test to fail and then write only enough production code to make the failing unit test pass. Basically, you are trying to do the most with the less effort possible, using an iterative method and going step by step. Besides this, using TDD meant writing more tests and, in turn, programmers who wrote more tests tended to be more productive; furthermore as they were tackling little problems at once, they found no need to invoke the debugger.

But, be careful…

Test-driven development does not perform sufficient testing in situations where full functional tests are required to determine success or failure, due to extensive use of unit tests. since the test are typically created by the developer who is writing the code to test, the test my have a blind spot and in consequence, the program will have it too.

Hit or Miss, I guess they never miss huh?

Is testing really that importan? Here is your answer.
A system expecting a 16 bits word received a 64 bits one, causing an overflow which led to the destruction of this machine.

As you would expect from this starting lines, I’m about to write about testing. Once you finish coding, you should test what you did in order to detect any error/failure so you can handle it. Also, you have to check if the software really does what it is meant to; how it fits it, defines the software quality.

This is an OO blog, so, let’s talk about Object-Oriented Systems Testing. This is a continuos activity during development. For the OO branch, testing includes three levels:

Unit Testing

This is somehow an individual test. Typically, is an automated test with associated control data that simulates how the source code to check should behave. checks if the methods and interfaces are error-free and if the attributes are implemented. This kind of testing is the responsibility of the developer who implements the source code of the structure.

Subsystem Testing

This is more complex than unit testing. It involves testing the associations and dependencies within a subsystem and how it interacts with the outside. this one is responsibility of the subsystem leader. This kind of test can be used as a regression for each newly released version of the subsystem.

System testing

This one involves testing everything as a whole. Often, this can be used as regression tests when a new release is assembled. This tests are responsibility of the quality-assurance team.

Testing Techniques

Grey Box Testing

The different types of test cases that can be designed for testing object-oriented programs are called grey box test cases. It is called gray box because the tester has a partial understanding of the internal structure in the system under test; also there is a black box and a white box technique, but this one is the most used. There are a lot of gray box tests, some of the most important are:

  • State model based testing − This encompasses state coverage, state transition coverage, and state transition path coverage.
  • Use case based testing − Each scenario in each use case is tested.
  • Class diagram based testing − Each class, derived class, associations, and aggregations are tested.
  • Sequence diagram based testing − The methods in the messages in the sequence diagrams are tested.

Techniques for Subsystem Testing

  • Thread based testing − All classes that are needed to realize a single use case in a subsystem are integrated and tested.
  • Use based testing − The interfaces and services of the modules at each level of hierarchy are tested. Testing starts from the individual classes to the small modules comprising of classes, gradually to larger modules, and finally all the major subsystems.

Categories/Stages of system testing

  • Alpha testing − This is carried out by the testing team within the organization that develops software.
  • Beta testing − This is carried out by select group of co-operating customers.
  • Acceptance testing − This is carried out by the customer before accepting the deliverables.

Please, do not Deploy on Friday

Let’s supuse you are about to deploy a new software system. Before you put in into production, you need to be sure that it is working, so, you should validate it. But, what exactly is validation? when i was learning programming, one of the very first concepts i have to catch up was validation. Back to those days, validation was only to assure the user input will not affect your program. However, things change.

Image by Pixabay

Validation is the process of checking whether the software product is up to the mark or in other words product has high level requirements. It is the process of checking the validation of product. Validation is the dynamic testing.

Also, you need to verify your system. But, what is different from validation. Well, just as efficiency and effectiveness, they are similar, but not the same. Verification is the process of checking that a software achieves its goal without any bugs. It is the process to ensure whether the product that is developed is right or not. It verifies whether the developed product fulfills the requirements that we have. Verification is static testing.

So, in a few words, Verification is asking your team: Are we building the product right? and validation means: Are we building the right product?

In order to get a better understanding of this concepts, you can read its differences below:

VerificationValidation
It does not involve executing the codeIt always involves executing the code
The verifying process includes checking documents, design, code, and program.It is a dynamic mechanism of testing and validating the actual product
Methods used in verification are reviews, walkthroughs, inspections and desk-checking.Methods used in validation are Black Box Testing, White Box Testing and non-functional testing.
It checks whether the software conforms to specifications or not.It checks whether the software meets the requirements and expectations of a customer or not.
It finds bugs early in the development cycleIt can only find the bugs that could not be found by the verification process.
The goal of verification is application and software architecture and specification.Target is an actual product
This is the first stepis the last step

Since the verification and validation are part of the quality control process, this activities are regulated by international standards, such as ISO 9000. Remember, Validation consist in the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers, while verification is the evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition.

In a perfect world, verification should go before validation and the validation after the verification. Somehow validation is more related to the software engineering, where you check the system is been building right, and the validation, also related to the software engineering, because you have to check wether or not has all the requirements, it is also a developer’s and testers thing. If you wanna learn more about Testing, I recommend you to look for Kent Beck, He is an awesome engineer and he has made a lot of contributions to this beautiful software engineering world.

Somebody toucha my spaghet!

I’m sure you have passed trough a moment like this.

A code review is a process in which the dev team checks up an implementation to come up with ideas on how to enhance it, or maybe refactor it, discovering possible bugs, architecture errors, missing test cases and several things that may happen. Now, you should be wondering: why in the hell someone else has to check my code, I’m such a programming guru… Well, yes, but actually, no.

When you are working in an organization, you should know that you are not the only one working on a project. On this context, socialism actually works (excepting your paycheck) because you are writing code that will be on constant development, enhancement and will require maintenance, all of this given by a bunch of developers in the future. Actually there are a lot of benefits on doing this exercise.

Knowledge is shared

  • People can discover tools, API’s and different ways to solve a problem that they were not aware of.
  • Obtain global knowledge about the system (Not only the components you are working on).
  • When new members join the team, more experienced engineers mentor the newer members. Often, teams have hidden knowledge within the code that surfaces during code review. Newer members, with fresh eyes, discover areas of the code base that need a new perspective. So, code review also helps ensure new insight is tempered with existing knowledge.

Keep in mind, code review is not just a senior team member reviewing a junior team member’s code. Code review should happen across the team in every direction. Knowledge knows no bounds! Yes, code review can help newer engineers, but by no means should it be used solely as a mentoring exercise. 

Code review pretends to

  1. Contribute with different points of view and to fix something that the developer may have forgot.
  2. Enhance the software quality and the code readability.
  3. Get the desired “code collectivity “

Let’s say that the code you wrote is already into production. Unfortunately, there is a bug in some code you wrote. This Math formula is code review in a nutshell:

G stands for how guilty you will fell
R stands for the number of people who reviewed your code.

How to review code?

As a code reviewer, you should ask:

  • Are there any obvious logic errors in the code?
  • Looking at the requirements, are all cases fully implemented?
  • Are the new automated tests sufficient for the new code? Do existing automated tests need to be rewritten to account for changes in the code?
  • Does the new code conform to existing style guidelines?

As a developer, you should ask yourself:

  • Is my code easy to understand?
  • Do I will be able to understand this code in a couple of years?
  • Did I consider every factor that may affect to the system?

But code reviews take time!

Sure, it takes time. But that time isn’t wasted–far from it; when the code review its done right, it actually saves time in the long run.