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.