Ready player one

Morrow wrote in his autobiography that he’d left GSS because … he felt that the OASIS had evolved into something horrible. “It had become a self-imposed prison for humanity,” he wrote. “A pleasant place for the world to hide from its problems while human civilization slowly collapses, primarily due to neglect.” (p. 120) 

 

(Halliday speaking) “I created the OASIS because I never felt at home in the real world. I didn’t know how to connect with people there. I was afraid, for all of my life. Right up until I knew it was ending. That was when I realized, as terrifying and painful as reality can be, it’s also the only place where you can find true happiness. Because reality is real.” (p. 364) 

-Ready player One, Ernest Cline

I have a feeling this is going to be a long post so before you start reading, sit back, breathe, relax.

This blog's song will be "Beast" by Nico Vega, it is a really great song.

 At the beginning of this blog's entry we have to different perspectives, the first is from Morrow, Halliday's best friend, which states that he left GSS because it became something horrible, it looks like he was talking about a horrible drug, on the other hand, we have Halliday's quote about OASIS, which seems like he was talking about some great medicine to make our existence a little bit more tolerable.

What are they both talking about?

In essence, they're talking about the drug of simulation. The hype of another reality, where everyone chooses his own reality.

What makes reality?

Ready player one is a beautiful novel by Ernest Cline, it is actually his first novel, and it just makes you feel like you haven't really lived until you read that book.
It is easy to read, with an interesting plot, Ready player one makes you think about the concept of reality.

Who am I? Am I the one on those Instagram photos and Facebook posts which seems to be having the best time of his life or the guy behind the screen, losing time on social media while my code compiles?

To make it all just more complicated, Ready player one has a lot of 80's references, I mean the main plot is to search for Hallidays treasure hidden between a simulated futuristic world and a simulation of 80's music, movies and cartoons. And if that doesn't make your mind melt, nothing will.

There is just so much to talk about the book right now I'm going to focus on some questions.

Do I agree on any of Halliday's/Morrow's statements?
Well, I guess it really depends on my mood, both are right in a certain way, however, right now, I'm more on Halliday's perspective, videogames are mainly something to distract us from our reality. And if we have the power of adopting a really that fits us better than this bunch of atoms we call "real world", we should, makes you think of Morpheus when he tells Neo "If real is what you can feel, smell, taste and see, then 'real' is simply electrical signals interpreted by your brain." on "The Matrix"

Do I think there are similarities between OASIS and the current IT world?

If my Facebook/Instagram reference wasn't straightforward enough, of course I do.

Most people spend more time using computers that interacting with the real world, and that doesn't mean it's a bad thing. Tonight I could be watching the stars or walking through the streets of this polluted city, instead, I choose to sit behind a computer, play some videogames, read a Wikipedia article about exoplanets, see a live concert from my favorite band, tweet about my existential crisis and connect with a girl on other country that can't sleep and thinks that the reptilians exist, talk with my best friend on Chicago and see a movie. I don't see any of that as a bad thing. I may be living in my own version of OASIS, and I like it.

Do I think it’s possible, technologically speaking, to have something similar to the OASIS by the years 2040 or 2050?

Of course, Second Life was just the start of simulated worlds, with cheaper, better technology like the Oculus Rift, virtual reality will become the next big thing in less than 20 years.
There is already a cool project called "The Apollo 11 virtual reality experience" which will make you experience on virtual reality the Apollo 11 moon landing on a virtual reality device. And this is just the start.

 http://immersivevreducation.com/the-apollo-11-experience/

If you haven't seen them already, this is what most resembles the virtual reality headsets on Ready Player One: https://www.oculus.com/en-us/

What do I think are the possible risks of something like OASIS?
The first thing I can think of is already happening, people are living more on simulated worlds than the real world, however, it makes you wonder, if everyone believes on the simulated reality more than the "real" world. Doesn't it make it real, after all, 2+2=4 is just a social convention we were all taught to believe. 1984, not a real quote, but a reference.

Wololo.

War Games

Today I will talk about the movie "War Games"

If you haven't seen the movie, you should, that's it, really simple. It is a great movie

End of this blog's entry.

.
.
.
.
.
.
.
.
.
.

Just kidding, the movie is about a teenager which is very good at making jokes and hacking computer systems, that while searching for some game files in the times where computers where connected by telephone lines (Yep, those cranky noises you heard on the old times where you couldn't make phone calls while connected to the internet unless you had two telephone lines) connects to a military supercomputer. In the middle of a cold war between the United States and Russia, his supercomputer was designed to simulate nuclear wars and choose the best case scenario in the case of a nuclear war (is it really a best case scenario?). The curious thing about it is that the computer, which had some artificial intelligence, was taught using games, so the file directory on the computer lists some common games along some disturbing games, like Thermonuclear war.

The kid, still thinking he was hacking some pc on a game company, chooses to play "Thermonuclear war" (he was just trying to impress "The girl"). Once the game started, things got really bad, thought he didn't know it. The thing is that some time before that, the military decided that they couldn't afford human error in the case of a nuclear war, so the supercomputer was connected to the nuclear missile facilites, with the power to launch them anytime it thought necessary, and the computer couldn't tell if it was still simulating a war or it was a real war. So once the game started, things could get really bad soon.

And since the military had connected the supercomputer to their sensors, they couldn't recognize that it was just a game un a supercomputer. They thought the kid was a spy working for the russians AND they were surely being attacked soon, so they started getting more aggressive, which made the russians get more aggressive, and well, you've all seen a recursive function go bad, right? It became something like that.

They couldn't even turn down the supercomputer because the systems would think that it was because of a nuclear attack and would attack back.

At the end the kid wins the trust of the military with help of the supercomputer programmer, a really cool guy that convinces everyone using common sense the low probability of a random attack like that, then they teach the computer using tic-tac-toe futility. Games that can't be won, the computer rejects the game of a Thermonuclear war using the amazing quote "A strange game. The only winning move is not to play. How about a nice game of chess?".

Even though the movie was released more than 30 years ago it really talks about some important IT related things.
- Can a computer have common sense?
- Most humans don't, do you really think a computer can replace human common sense?

-Oh, but Siri makes fun jokes...
- You are a Lua programmer, right? (You thought I wouln't make a Lua joke this time? Think again).

- Can a computer replicate the human thought process?

- "The Computer is incredibly fast, accurate and stupid. Man is unbelievably slow, inaccurate and brilliant. The marriage of the two is a challenge and an opportunity beyond imagination."
 Walesh, 1989 
No, it wasn't Albert Einstein.

Thats all for now my fellow reader(s)
Wololo.
 

Microservices

Hello, today I will talk about the use of microservices in software design.

Microservices are defined as an application that uses components where a main controller connects different web services that could be programmed in different programming languages and use different data structures, it is the ultimate application of the "Divide and conquer" strategy. Where programmers develop a service and connect with the people that use it.

A great benefit of microservices is code reuse by using a service in different applications, in that way, application developers focus on more important tasks by utilizing components as libraries, another benefit is that an enterprise could have specialized teams focusing purely on web services, front end or back end programming, everyone using other teams projects as components.

The hard part comes when trying to communicate with different processes, microservices need to be easy to use, well documented or any project using a specific microservice could crash each time it gets updated, another problem is that microservices are usually more expensive to use than native methods, so if an application performance is a critical aspect, microservices could be a bad choice (it all comes to terms on choosing the best trade-off in the end.

The last critical aspect I would like to talk about is that microservices should be well programmed, since many applications may depend on any microservice, it should be almost perfect, since a failure could cause a lot of problems on many applications, the risk of using a bad microservices is greater than using a bad method on a native application.

Microservices are much like any new programming language, developers either love it or hate it, however, in today's 'build it as fast as you can' programming enviroments microservices offer a lot of flexibility to programming projects, and as any new technique the hard part comes when a project manager has to choose the trade-off thats works best for a project on a specific context.

Wololo.

The 4+1 View Model

After two weeks since my last entry today I'm going to talk about the 4+1 view model.

This blog's song will be "I'm Comin Back" (That's the actual title) by Balance and the Traveling Sounds, great mix of funk, hip-hop, enjoy.

Software can be seen from different perspectives, each of this perspectives usually specifies on one aspect of software, a programmer may see a software project as a bunch of components built together, another programmer may see the same software project as many process working together and calling other processes, a more hardcore programmer may see the same software project as a bunch of bits being carried around between secondary storage and the processor, those bits being manipulated on each step of the process (I'm talking about some hardcore assembly programmer). A Lisp programmer may see the same program as data being processed in lists. Then a Lua programmer would not see anything, as he'll be eating glue and crayons (that would be me).

The elephant and the blind men story relates one of the main problems in software development, there is many ways to see the same thing, and all of them are right in some way, but everyone is wrong when used alone. Software programs are complex systems, made up of many components, working together to acomplish something, a software architect may need to have the skills to define the combination of representations of the same thing to get the best idea of it.

The 4+1 view model is one way to approach that problem. It defines 4 main perspectives and 1 that summarizes every one of them, focusing on the easiest way to explain software to a non programming human (yes, I've come up a term for that), in fact, I'm a strong believer that humanity can be expressed as 10 types of humans, those who understand why 10, and those who actually think of the number 10. Those who binary, and those who don''t.

Putting bad jokes aside, let me discuss the 4+1 view models below.

Logical view: The blueprint for project managers, a view that explains from a high level the components of the system for someone who has to understand from high ground what the slaves are doing below. In Egyptian sphynx this blueprint would have something like definitions for (Arm, leg, hip, sphynx head, etc.).

Development view: The blueprint for programmers, the working hands of software development, the slaves putting together the bricks for each sphinx's leg. (Not being serious).
It is a lower level diagram for the people that work in specific subcomponents of the system.

Process view: The blueprint for explaining when two components will communicate. In software, this view explains mostly concurrency, server-client interactions. In my egyptian sphinx example, it will explain how the sphinx communicates with other pyramids on Egypt that are aligned with the mayan pyramids to communicate with the aliens that humanity has already invented seedless watermelons and the end is near.

Physical view: This blueprint explains how software will deploy on a physical device. In software it mosly explains the system on which the software will be installed, on my now weirder egyptian sphinx example it explains how the telepathic module was installed on the top of the pyramids and the sphinx's head.

The +1 view, use cases: I actually love to use use cases, they are a simple, effective way to explain someone who doesn't have to know implementation details how the system will work (usually that is the client).
A pretty good thing is that use cases don't deal with implementation details or the subcomponents, they just define the behaviour and the actors of the system.
Use cases are much like approaching to a girl in a bar and telling her "I have a 3-step life plan, the first step is approaching to you, the third step is being married and throwing crazy parties on our house in Dubai." and when she asks "What is the second step?" you smile and answer  "that's the part where you make a choice, would you like a drink?" (As odd as it may sound, it actually works).
In this analogy you hide all the implementation details of your plan (even the fact that you don't really have a plan). You just refer to the expected behaviour and actors of the system.
Perks of studying software architecture.

That is all for now my fellow reader(s).
Wololo.

The SOLID principles

Today I will talk about the SOLID principles and the article "Understanding the SOLID principles" by the book“Ace the Programming Interview: 160 Questions and Answers for Success”.

The song of today's blog will be "Across the overspass" by "The Solids".

The SOLID principles talk mostly about how to do clean code in object oriented programming.

"S" stands for "single responsability", which means that classes should have the logic to handle a specific task or set of tasks, it can be summarized as "if class A handles A and B, you should delegate B to a class B". The reason for this is simple, if you have to modify something related to activity A, it is great to open class A and see only the code that handles it. 

"O" stands for open/closed principle, which means that classes should be designed in a way that they can be extended, but not modified. The reason behind this is that if you have to modify a class, you will most likely have problems on other classes that use the class. If you need to add some functionality to the class add it, but don't try to fix something that isn't broken, or you'll end up redesigning the whole house just because you needed to add a lamp.

"L" stands for "Liskov sustitution", which basically means that if class B and class C inherit from class A, the methods for class B and class C should be interchangeable, that of course limits the power of inheritance, but also brings peace between child classes, if a class should implement some funky chunk of code, it is always better that it gets it by composition rather tan inheritance, or trust me, things will become messy.

"I" stands for "Interface segregation" which is sort of a variation of "S" applied to interfaces, it basically means that instead of having an interface for a big chunk of logic, you apply "divide and conquer" and make every interface define a specific behaviour, and let classes choose to implement the number of interfaces that handle the logic each class needs. Sounds simple.

"D" stands for... "Dependency inversion" (what else did you think?) which means that code should have minimal dependency, so instead of having a class A that has an object of class B that has a set of behaviours you define an interface B and a class B and BAlternative, then, on class A you can just define a method that calls the logic of Interface B (which can come from class B or class BAlternative). That way, the behaviour of class A and class B isn't coupled.

Object oriented programming is extremely powerful for some programming problems, however, it has to follow design principles to void messy code, a problem on object oriented programming is that if you do not design well your solution, everything depends on everything, and a minor bug on class A can cause the whole thing to crash, then becoming the debugger's nightmare (where each time you clean a bug you uncover other 10 bugs on other classes, recursively, until you get a debuggerOverflow exception and everything goes bad).

Thats all for now, wololo.

Software craftmanship

Software Craftmanship

So, first things first, today's song will be "Goodbye my lover" by James Blunt

Enjoy

Today I will talk about the podcast titled "Software Craftmanship" with Bob Martin.
Bob Martin defines software craftmanship as sort of an improvement on agile software development, he talks about the need for architects to code so they feel and understand the methodologies programmers use to code.
Software Craftmanship is a mixture of agile coding, pair programming, driven development, doing well crafted software, focusing on the code instead of the design. He talkes about some ideas that seems to talk about refactoring, and leaving a cleaner code each time we modify it.

I think software craftmanship is a great approach to software development, since it defines some great ideas, as everyone working at some point on coding, since coding easily evolves, I agree with Bob Martin that if architects don't code then their ideas will be more difficult to code. I like a lot the idea of collaboration and people working together instead of coding alone, another think I think is very important is that developers have to collaborate with their clients, understanding the requirements by approaching to the client so they can produce better software.

I like a lot of agile development disciplines, since they focus on what I think is the more important aspect of software development, the coding. I think a lot of methodologies focus a lot on design and sofisticated tools (those awful CASE tools). That look nice on paper but almost always end up becoming more of an obstacle than a tool

Of course, as in everything, there is a tradeoff, but it may be appropriate to most software solutions, so maybe the key is to be flexible on choosing the best discipline for a specific project, there may be some solutions where a waterfall approach may be the best. But for most solutions, an agile discipline or an evolutionary approach may work perfectly.


With software methodologies it happens the same as with choosing the best programming language, there are no wrong approaches, you just have to choose what is best for you. So it is very importante that you know a bit about all of them, to understand each methodology's weaknesses and strengths.


I've said it many times, but in software development everything is a tradeoff, so you have to be flexible and choose what works best for you.

Wololo.

Is Design Dead?

It's been some time since my last entry (mostly because stress related problems due to exam)

So, today I will be writing about design on extreme programming and discussing Martin Fowler's article "Is Design Dead?".

First things first, today's song will be "Lost on the way home" from Chromeo, no special reason though.

There was a time where software wasn't so volatile in terms of requirements, you could gather all the requirements, then take your time to design some solution that would fit the problem perfectly, program it and deploy it, thus leading to this mythical being called "The architect". Things were much more simple than now, where everything changes very quickly, if you design based on the requirements until you've made up a perfect design, most likely the project requirements would have changed by that point, at all times you have to avoid rework and bugs, because one rule still applies now, as time passes, the cost of changing software stuff grows exponentially.

That is where agile software development comes in, a series of techniques designed to make software building in chaotic enviroments easier. One of it's most famous focus being Extreme Programming.

Extreme programming is a bit controversial, mainly because it ignores almost completely all "serious" techniques. It focuses mostly on having functional, running software as early as possible. Skipping investing time on heavy requirements engineering and design.

XP on requirements:
Since requirements change very quickly, you don't need to waste much time knowing all the requirements, instead, know the most important, basic requirements and start designing on that.

XP on design:
Design the most flexible, easiest, simple possible. Don't rely on diagrams, they are a waste of time because they are hard to keep updated, the most easiest way of design is clean code.

XP on coding:
Start coding quickly, don't code anything you think you're going to need in the near future, instead focus on the things you need to code now. After you coded and tested everything, refactor.

XP on refactoring:
Refactoring maybe the angular stone on XP, it is the main thing that keeps an XP project clean.
Refactoring can be summarized as: once you have functional code, clean it up so you get understandable, simple code.

Since XP relies on the fact that on some point, things are going to change the previous steps apply to the project on stages (stories).
Once you made functional code, you get to know which stuff is missing (at least on a very near future) so you get requirements for that functionality, design, code, test, refactor, test.

So, as the title asked, is design dead?
I agree with the author that design isn't dead, not at all, no matter what new technique is invented, you will always need some kind of design to make a software project maintainable and understandable. However, since everything is more volatile on software development than it used to be before, design has evolved to some more simple, fast, clean way of design.

Who needs an architect?

Today I will discuss the article "Who needs an architect?" by Martin Fowler.

Today's song will be "E.V.A" by Public Service Broadcasting, no special reason though.

The article talks about the definition of "software architect", the author explains how architecture is a term created to make software design sound more complex than it actually is and with a lot of Matrix references he states that architecture is just a social convention to describe what most developers think as "a high level representation of a system". Then he states that there are two kinds of software architects, the Architectus Reloadus (yes, Matrix reference here) which is most like The Architect from Matrix Reloaded, a kind of developer which has to take every decision regarding the system design, which creates a bottleneck and adds complexity to the system, and then there is the  Architectus Oryzus, which is more like a guide to the overall system development, and I think Fowler makes a bold statement when he says "the architect's value is inversely proportional to the number of decisions he or she makes", because if the architect makes few decisions then he isn't needed (the main idea of the article), however, Fowler also states that an architect decides things that shouln't change in the system, and since software isn't bounded by laws of physics as traditional architecture, then you could, in theory, build systems that are bound to change.

It all sounds very neat, and if that could be true, then Fowler has a point, there would be no need of an architect, however, I think in real software projects you need someone to lead how the system should be developed, and since every software developer knows that every piece of software we build will need to evolve sometime software projects can become a real mess very easy. The most simple system can become really complex if the developers don't have a blueprint to guide them. Lots of duplication, unneeded components and other components doing stuff that they shouldn't do. That is where the architect comes important, by designing a system he creates a blueprint which will guide the whole development, a good architect determines by his experience which things should be done bound to change and which things don't, archieving the middle ground between complexity, ease of change and maintainability.

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.