Software Architecture

Hello everyone, today I will be talking about the article "Software Architecture" from the book "Code Draft" by Pete Goodliffe.

As in previous blogs, I will encourage you to hear a song while reading this, as I write this entries I hear music to get my inspiration flowing, so this week's song will be "The Architect" by "O.A.R", and I find it very bold how it the intro mixes a rock guitar intro with some caribbean-like trumpets, I hope you like it.

So, what is software architecture?
I found it hard the first time I heard the term to believe it, I couldn't quite understand how software would relate to architecture in any way, I remember it was my first week at work and we had a meeting to discuss some projects, I was talking with other programmers when this guy appeared in a suit and everyone just shup up and stood there, waiting for him to say something, he started talking about some very obscure things about Java and how he thought it was important for us to know, after that the meeting went pretty casual. After the meeting my friends told me about this god-like figure around the company, "The architect" was his official name around the office, he was in every project, and in none, it was very misterious to me what he did in the office, but everyone respected him, and so did I (monkey see, monkey do was one of the most useful things I learned at my first weeks on the job).

Then one day, a new project popped out, and some programmers (including myself) were asked to attend to a meeting to discuss the project development and architecture (then things strarted to become clearer). We were working on the project design and the architect just stood there in front of the whiteboard thinking, then all of a sudden, he crossed some modules we have drawn on the whiteboard and started talking about how we could skip some of them by integrating them to other modules (and some other obscure things I don't remember), and then it happened, he had simplified our original design to just five modules that contained the logic behind the whole project. He explained us how it would work and everything made sense, I had finally understood why he was the architect and what did he do that was so valuable, his sense of programming was pure, elegant, and practical.

The chapter talks about sofware architecture and how it is useful to design the project before getting to programming to avoid some nasty things during development, basically, the role of the architect is to design a software solution the most efficient, simple, way. So the project goes on with minimal setbacks, getting the most out of every trade-off.

From no-design code to client-server architectures, layered architectures or modular architectures, the architect is the one who sees everything as an ecuation that has to be balanced (with the regular programmer being the one who messes things up and becomes the oracle to restore order to our chaotic world, bringing peace between humans and machines with a great sacrifice from the one).

Silly references aside, software design is much like designing a building (thus the comparison between software architects and traditional architects, you have to design a nifty, flexible, solid structure that has the capability to hold things up, otherwise the whole project may fall grotesquely.

This is everything for now, stay tuned.

Wololo.

Moon Machines

Hello everyone, as the title of this entry suggests I will talk about the machines and the engineers that made it possible for the human to land on the moon and return back to earth successfully, as I've began to recommend music for an easier reading of this entry, For this entry I have a special song.
The band is Public Service Broadcasting, the song: Go!
What is great about this song is that it used original recordings from the astronauts and mission control on the Apolo 11, the mission that landed on the moon, the song makes you feel like you're one of the astronauts just about to land on the moon.

Enjoy.

The video talks about the engineers that made possible the moon landing on 1969, after JFK said they would land on the moon before the end of the decade and suddenly the research facilites had a huge pressure on really doing it.

First was the Guidance Computer, just after an experiment from the MIT flew a plane on autopilot 3,000 miles the MIT was selected as the institution to develop the Apollo Guidance Computer, as the requirements weren't defined yet, the project had many problems, everyone of them was overcomed by the brilliance of every engineer working religiously on making possible this great event in human history.

While the guidance computer was being developed with many setbacks, other engineers worked on deciding whether the guidance system should be the primary guidance system or just an aid, or on what medium should the computer be programmed, the ultimately chose a medium based on hair so the software should occupy less space.

I've learned from the video that when a government invests on research projects like this a lot of inventions are made that change the way engineering is done forever.

From CAT scanners (Cancer detecting technology),  smoke detectors, water filters and more machines that we now use were invented due to the Apollo 11.
If you want to read more about it, head over to this post: http://www.telegraph.co.uk/news/science/space/5893387/Apollo-11-moon-landing-top-15-Nasa-inventions.html

About me

Hello.

In this blog I will talk about my experience while taking the course "Software Design and Architecture".

Let me introduce myself first, my name is Kevin Islas, I am a student at the Tecnológico de Monterrey studying something like computer systems engineering (although I think deep down it is most similar to Software Engineering, the name of the engineering in spanish is "Ingeniería en sistemas computacionales", but some things always get lost in translation (ironically, the spanish translation of the name of that same movie is "perdidos en Tokio") so, I guess I have a point on things being more than what the language states about them.

At this point you may be wondering how the above statement relates in any way to software design and architecture, but don't worry, I will explain it just now.

Even though programming languages are different to natural languages by being structured, carefully designed (most of them, except Lua (inside joke and nested parenthesis that only a Lisp guru would understand)) and strict in a way that statements can be understood in any context by a set of rules that are strictly defined (short story, in a natural language a concept like soft depends on the context and many other things, and in a programming language (I think they're actually called logical languages, like math) things have a meaning that is defined by a set of rules, like soft being defined as a property of a previously defined object which property is less than 5 on a previously defined scale of softness, you get the idea.

As I was saying, even in logical languages, where things are defined by a combination of statements which meaning is strictly defined, the logical structure that defines those things can variate, two programmers that can make the same thing with different logical structures, where some logical structure performs better on some scenarios and worse on others (even randomsort can be more efficient that bubblesort, in some cases).

As programming languages were designed, some favoured some aspects and others performed better on other aspects, that is because of the logical structure that was used to define those languages (and as a lua programmer that doesn't like lua, I have to admit it has its benefits).

So, knowing that languages have strengths and weaknesses (every aspect in software design can be seen as a tradeoff), when trying to build software, an experienced programmer would try to use the language that benefits the most out of the tradeoffs, or at least, use the logical structures learned by using other languages to enhance the programming language used, knowing what thing can get "lost in translation" in that process.

So, by learning software design and architecture I expect to enhance my knowledge as a programmer to benefit the most out of almost every programming problem (then, as a good programmer I expect to forget all those rules and live by what works the best).

As I have talked about my hobbies in other blogs, here I will expand what I've previously said:
I almost decided to study medicine but then I've realized that even though I loved medicine it would be best for me to study something IT related, maybe someday when I get the mid-life crisis I will get the urge for living the dream and work at something IT-medicine related.

Another thing I like is psicology, so when I have some spare time I read anything I find about medicine/psicology, partly because I find it fun, but mostly because sometimes I need to get my head out of programming to later come back with a fresher mind to solve a problem.

Wololo.