--Originally published at Newbie Programmer

To solve big problems its not that difficult, because is the same way as the small problems, everything we learned is very helpful, the trick is that we need to look at the big problem and divide this in individual problems that are easier to do (divide and conquer), and we can use the things learned from writing good software.

We already know how to encapsulate to make the application flexible and easier for the changes, the use of requirements that is what my system is supposed to do, then is easy to combine the solution for the individual problems, and the analysis give us a context of what we need to do to supply the real world problems of each part of the big problem.

That’s a summary of what we learned, but now we need to solve the big problem, a good starting point is to make the requirements and the implementation of use cases, we can figure out what the system is suppose to do, and to add to the list the things to do, but we need more information, and how we can have more information about the problem.

To have more information is important to know how the system is like and not like, to help us to know what we need to worry about, to find out more information its important to talk to our customers, and we figure out we need features.

The features are a high-level description of the things that the system needs to do, from one feature you need to create requirements to satisfy this feature, this help you to know a great way to start in big projects.

The use cases and features are good explaining the problem, but we need a big picture view, because a picture is Continue reading "CHAPTER 6 – SOLVING REALLY BIG PROBLEMS" →

--Originally published at Newbie Programmer

The chapter two is interesting, this continues and introduces new concepts of the first chapter of how to make a good software, because explain the huge importance of the requirements.

The requirements are things that the system, project, app must have to do and work correctly in base of what the client wants. Its important to make a list of the needs, because in the process of making the product the client should have more things in mind of how they can work better with the project, another thing that is important is to write requirements in the view of the customers or users of the application, because your client uses the product different from the final user, for example in the book is the dog, in this phase you have to think beyond the requirements and prevent changes in the process.

Despite of having good requirements its a must to prevent the final product from unusual scenarios, to have a plan when the things goes wrong, in this case we can make alternative paths to solve problems, this scenarios can be explained as use cases, this use case are the different goals, this goals have an initial and final point, because is needed to have a condition that indicates that the goal is completed and the client is satisfied.

All of this concepts are useful for making the code, because you have a guide of how begin with the code and to indicate the different classes and methods you could use and the best or cheaper ways to achieve the use cases.

--Originally published at Mike's Blog

Este cuarto semestre de universidad, tuvimos la “oportunidad” de cursar la nueva modalidad de semestres del Tec, Semestre I. Oportunidad está entre comillas porque no nos dieron a escoger, y básicamente nos forzaron las materias, pero ese no es el punto. Pese a el muy amargo inicio, y la incertidumbre, este semestre me enseñó muchas cosas. Muchas de estas a la mala, pero son cosas que no se aprenden en un semestre normal.

La primera enseñanza que me deja este semestre es a controlar tus emociones, muchas veces cuando estás trabajando en un proyecto, o en algo, te dejas llevar por tus emociones, y no puedes trabajar al cien. No te puedes concentrar, haces las cosas mal, y terminas trabajando demasiado tiempo a medias. Si las cosas se atoran, o no salen como esperas, tomate un descanso y respira. En nuestra área ingenieril es muy común trabajar en la computadora, el problema con esto es que nuestros “descansos” muchas veces son dejar de trabajar, y meternos a Facebook, o hacer otra cosa, pero sin dejar la computadora. Si necesitas descansar, pon la computadora a un lado y camina, despabílate, come algo, platica con alguien. No te quedes sentado en la computadora, solo te vas a frustrar más y terminar más cansado. Muévete, en esos momentos necesitas que las ideas fluyan.

La segunda enseñanza es aprender a manejar los tiempos. Algo muy difícil de este semestre es la flexibilidad que hay para las fechas de entrega, y la ausencia de fechas límite de entrega. Yo estoy muy acostumbrado a trabajar bajo presión, y muchas veces si no tengo presión, simplemente no me dan ganas de trabajar, y termino procrastinandome de una manera impresionante. En esta clase de proyectos en los que te dan mucha libertad, hay que tener una agenda, y Continue reading "Semestre i, las secuelas." →

--Originally published at Mike's Blog

Semestre I, un semestre algo polémico en el sistema Tec, ya que las clases cambian de manera radical. Este semestre tuve la “oportunidad” de cursar un semestre en esta modalidad. Nótese las comillas, ya que no tuvimos opción. Después de muchos corajes por la manera en la que nos enteramos del semestre, creo empecé muy emocionado por este semestre, ya que nos iban a poner un reto, e iba a ser como trabajar por un semestre.

Empezamos algo raro, ya que no supimos ni el reto, ni el horario hasta el primer día de clases. Las únicas cosas que sabíamos antes de eso, era que el reto estaba relacionado a Internet de las Cosas, y que el horario iba a ser dinámico. Para los alumnos, y los profesores esto rompía paradigmas, entonces tomó trabajo el acostumbrarse al ritmo de trabajo, y a los diferentes módulos. El primer día hicimos los equipos con los que íbamos, y estamos trabajando todo el semestre. Los profesores nos dieron la opción a nosotros de hacer los equipos, y nuestro equipo fue el más grande, cinco personas; Pietra, Edwing, Diego, Wicho y yo. Al principio estuvo chistoso, ya que yo solo conocía bien a Diego y Edwing, nunca pensé lo bien que me iban a caer los demás.  El trabajo en equipo es normal en el Tec, lo que no es normal, es trabajar en equipo todo el tiempo.

El primer “parcial” fue extremadamente confuso, ya que sabíamos cual era el reto, y sabíamos como resolverlo, pero solo a grandes rasgos, no teníamos idea de como plantear una solución que estuviera bien planteada, y fuera viable, pero medio a ciegas y a como pudimos salimos. Lo que se me hacía más extraño de este parcial, era obviamente el horario cambiante, pero tambien la materia Continue reading "Semestre I una breve historia" →