#FlippedClass and my thoughts

During this semester, I had two classes that taught me new things. I don’t mean about theoric things, supposely I learn this every day. But I mean more about experience. Those classes were TC1018 (data structures) and TC1019 (intro to software engineering). In the first one, I had my first real challenge. To be honest, I’ve never had such a hard time with a course, not even OOP or literature (believe me, in my school was really hard). But this post is not about TC1018 and my crazy teacher. This post is about TC1019, a really different experience.

Since I remember, school has been about teachers speaking in the classroom (sometimes passing slides and spitting random words), leaving homework and handling a test which was about what they said. The same loop over 13 years (preschool doesn’t count). This semester was different. First: a class where your attendance is not important, where the teacher does not spits words, but rather makes you investigate and learn by your own (boosting your self-learning skills), where you grade yourself. One can think in two ways: a) this is the best teacher, since he achieved Teachvana, and he is not establishing any knowledge frontiers or b) this is the easiest course, I’ll probably not do anything and still achieve the perfect score. When I started this course, I was thinking like option B (I still do, a little). But as I learned new things, I started knowing what life is about. You don’t stop learning in school. If you do, you become obsolet in a short time. Returning to the non obligatory assistance and pseudo no-date assignments, I believe this teaches you to be responsible. I won’t deny it: I left most of the posts for the end of the month. But still, I

flickr photo by http://resn424.wixsite.com/resnphoto https://flickr.com/photos/raphotosseoul/14987908799 shared under a Creative Commons (BY-SA) license

Continue reading →

TC1019: Course review

Hello m8s, this is probably my last post of the semester. Hope you enjoyed all my posts.
The Fundamentals of Software Engineering course (TC1019) with Ken Bauer was great because of his flipped classroom method. Without it this course would probably be just another memorized, undigested, boring theory course. Thanks to the flipped classroom method I had to read, investigate and learn by myself forcing me to actually learn something, be responsible and get my own conclusions of the theory. Otherwise I would just have to learn by memory a dozen of sentences to write them in a piece of paper. I hate studying, memorizing words or formulas sucks, what I loved about this course is that I didn´t need to study for my exams (giving a quick read to your post before a exam still helps to refresh old memories ;) ), I knew every topic because at some point I had to read, investigate and write a post about it.

Of course, this class wouldn´t be a success without Ken Bauer, he is actually what makes this class great. He really wants us to get involved in the class and to share our experiences with others. Eventhough I didn´t participate that much on twitter, I made my sharing on the blogs. I think that is very important to have in mind that this is not a competition, if I or somebody else discovered something new or interesting we could share it to the whole class thanks to the tools Ken introduced to us (Twitter, Slacks, Blogs etc.) After all we are all here to learn. Also, he shares his experiences with us, and that is for me the most valuable things of the class. Private interviews with software developers celebrities, extra "off-topic" relevant content and a lot Continue reading →

TC1019: Course review

Time To Quality Test

Humans are not perfect

Humans are not perfect, and since we are the ones doing the programming, a lot of times programs have what´s known as bugs, or errors(Fun Fact: they are called bugs because way back in times of the ENIAC, what caused problems were literal bugs who crawled to the machine).

Sometimes bugs can be as disastrous as cracking your program the second you run it and ruin everything you´ve worked so hard for!!! and other times they´re not as bad, but either way the best thing to do is spray Raid over them and kill them(please don´t spread Raid ver your computer, that thing is really toxic).

Software testing is just what it sounds like, to run your own program and see how it works, so you can correct any mistakes you may have made. This is usually made in order to debug your program, or to give it maintenance(which a lot of times ´maintenance´ means a new bug was discovered). While it may seem easy, it often gives not-experienced programmers(like me) a really really hard time.

This is a huge topic and has a lot of coverage in it, so we´ll start from the beginning.

Why do we do it?

Well, first of all, a crash in your program carries a risk of damaging your hardware. Also the people funding or contracting you don´t want to pay for later debugging, because that is quite expensive. A study from the NIST in 2002 found that this is the cost of debugging at later phases of the development.

Cost to fix a defect		Time detected
Cost to fix a defect		Requirements	Architecture	Construction	System test	Post-release
Time introduced	Requirements	1×	3×	5–10×	10×	10–100×
	Architecture	–	1×	10×	15×	25–100×
	Construction	–	–	1×	10×	10–25×

Table taken from NIST Study, 2002

Continue reading →

Semester Review

Software engineering, craft or an engineering discipline?
Software development and design is part art and part science, it can be understood as a systematic approach to the analysis, design, assessment, implementation, test, maintenance and reengineerig of software, that is, the application of engineering to software. In the Software engineering approach, several models for the software life cycle are defined, and many methodologies for the definition and assessment of the different phases of a life-cycle model

History of Software Engineering
The term Software Engineering became known after a conference in 1968, when the difficulties and pitfalls of designing complex systems were frankly discussed. A search for solutions began. It concentrated on better methodologies and tools. The most prominent were programming languages reflecting the procedural, modular, and then object-oriented styles. Software engineering is intimately tied to their emergence and improvement. Also of significance were efforts of systematizing, even automating program documentation and testing. Ultimately, analytic verification and correctness proofs were supposed to replace testing. More recently, the rapid growth of computing power made it possible to apply computing to ever more complicated tasks. This trend dramatically increased the demands on software engineers. Programs and systems became complex and almost impossible to fully understand. The sinking cost and the abundance of computing resources inevitably reduced the care for good design (Wirth, N, 2008).

Ethics in software engineering
Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

Software lifecycle
SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and

Continue reading "Semester Review" →

Software verification and validation

Imagine that you finished a big, big, BIG project. You’re delivering it. The client sings the final check and shakes your hand, thankful. Two weeks later, you receive a call. It’s your lawyer. Your client wants to sue you because what you did is not what he asked for (at all). So… you have three choices: a) you rot in jail, b) you deliver a new product (that means, you work extremely in order to make it fast and good) or c) you travel back in time and check that what you’re developing is actually what the client needs. I have great news! Although option C is physically imposible, you can do something similar: do it before every project you build.

Verification and validation may seem the same concept. To identify the difference, ask yourself: am I building the product right? This is verification. In the other hand, am I building the right product? This is validation. Both are equally important.

There are three other concepts that are important. One might think they’re all the same, but they’re not. Here are the concepts about errors:

Fault: when your code is wrong, when you forgot a parenthesis, when you named the file with a wrong extension. Simple bugs, generally debugged by the IDE or compiler iteslf.
Failure: runtime error. It happens during execution of the program. These must be debugged manually.
Malfunction: this is a deeper error. It involves the structure and architecture of the program. Usually, this are the worst bugs. These take days to be solved. Sometimes one must restructure from zero.

This process is directly related to software testing and requirements elicitation.

flickr photo by West Point - The U.S. Military Academy https://flickr.com/photos/west_point/6005746185 shared under a Creative Commons (BY-NC-ND) license — flickr photo by West Point – The U.S. Military Academy https://flickr.com/photos/west_point/6005746185 shared under a Creative Commons (BY-NC-ND) license

User Interface design

I would classify software in three categories. All of them are equally important, and even though each of them works as one piece, a real big project requires the three of them. The first is the core software: in a simple word, algorithms. By itself, it is one of the most important things. But, without the other three components, it’s good stuff only for other developers. Second: database. How is the information stored. Again, if not used as a whole with the other components, it’s only good for developers. And third: UI. UI is, at least for users, the most important aspect on every program. You have an ugly UI, your program is “not as good as X program, which is pretty”. You have a great UI although your core is not that good, (most) users don’t care, the UI is great and simple, they can use it without problem.

User Interface is the layer of software with which users interact. It seems the most simple layer (technically speaking), but it is one of the most complex to develop. Why? They say a UI is like a joke: if you need to explain it, it’s probably not good.

UI is categorized in three forms, from more advanced to more natural:

CLI: Command Line Interface. Basically, a terminal in which one types text-only commands.
GUI: Graphic User Interface. This time is visual, but it’s fully digital.
NUI: Natural User Interface. The most natural form of UI. It includes sensors, buttons and other devices that can be physically manipulated by the user.

flickr photo by baldiri https://flickr.com/photos/baldiri/5734993652 shared under a Creative Commons (BY) license

Desarrollo de software en la industria de la Animación

La evolución que en los últimos años han tenido las ciencias computacionales ha sido de gran ayuda para potencializar diferentes mercados de la industria digital. Un ejemplo de esto es la industria de la Animación, pues en la actualidad es ayudada por la ingeniería de software mediante la producción de herramientas que le permiten a los animadores y artistas digitales realizar trabajos de mayor calidad visual.

Plataformas como 3D studio Max, ZBrush, Maya, Harmony, entre otras, han permitido a estudios de producción tanto grandes como pequeños la creación de contenidos visuales de diferentes tipos, desde publicidad, comerciales o cortos hasta películas y videojuegos. Este tipo de software cuenta con distintas herramientas que le permiten a los artistas modelar y construir personajes y escenarios en dos o tres dimensiones para posteriormente animarlos.

Aunque en los últimos años se ha popularizado cada vez más la animación, los videojuegos y la realidad virtual, el desarrollo de software ha contribuido en ellos desde mucho tiempo atrás. En 1990 comenzaron a destacar diferentes juegos de video, lo cual trajo consigo una gran demanda de animadores 3D, se crearon muchos juegos para computadora personal, y con ello surgieron nuevas plataformas que incluso en la actualidad siguen estando vigentes y actualizando constantemente el software que ofrecen para mejorar la experiencia de los usuarios. Algunas de estas plataformas son la PlayStation, de Sony; la Nintendo 64, de Nintendo y la Sega,de Dreamcast.

Como podemos ver, gracias a la ingeniería de software es que hoy podemos disfrutar tecnologías de gran calidad visual cada vez que vamos al cine, vemos una serie o un corto animado o jugamos cualquier tipo de videojuego. Es realmente impresionante todo lo que se puede lograr gracias a las ciencias computacionales, y la manera en la que el punto de encuentro entre el arte y

Continue reading →

Software Design? Let´s Take It One Step Ahead

Level up your software design

Today, I will briefly explain what software architecture is. Basically software architecture is just software design for a larger proyect, on a bigger scale.

If you remember, the basic part of software design was the algorithm design, well when you have a really big project with thousands of lines of code, suddenly algorithm design doesn´t seem as viable and yo see software architecture winking his eye at you.

Of course there are some differences in characteristics for being a bigger plan. Some of the characteristics that differ are:

Multitude of stakeholders: Usually clients who ask for big proyects are big companies or have a big name themselves, so you will have more pressure, but also better equipment and a better pay check.
Separation of concerns: Because these programs are so massive(remember, thousands of lines) they usually divide into small chunks to make them more manageable, and apply software design to them to transform them into architecture once together again.
Recurring styles: In order to make it easier, a pattern has been made(just like in real architecture) that we can all do. This is actually the birth of design patterns.

Image by Hendrix

When Science Meets Art. Software Design

Is that even possible?

If you´ve been here long enough, some time ago I talked about mixing science and art. This is one of the best examples(Notice how I said ONE, spoilers for next post).

First let´s make things clear. Software design usually refers to the problem solving through an algorithm design(software solution). This is caused because on paper it sounds so nice(it always does) but in real life, machines have physical limitations(Memory, RAM, processing power, etc.) and a lot of times, careful planning is needed in order to make efficient what we have.

And that is what software design is at a basic level. The planning of how to implement software into a problem and create a solution.

That sounds so good, how do I do it?

Well first, it is expected that when you are in this phase you should already have done the analysis of the problem at hand(actually software design is part of the implementation step). With that in mind the first suggested step is to build a “prototype that works” meaning something either really simple or really complex that solves the problem.From there on it´s just adjusting you prototype to the limitations you have. As a sort of guideline, it is recommended that one process should not take more than 15% of the resources. Actually, there are quite a lot of suggestions, the best of them being Davis´s principles for software design which are as follows:

The design process should not suffer from “tunnel vision.” A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job.
The design should be traceable to the analysis model. Because a single element of the design model can often be traced back to multiple

Continue reading "When Science Meets Art. Software Design" →