Hidden Figures

What I liked the most about the movie is that (even though it is dramatized) I thinkit shows and/or reaffirms something that I believe is true and I think we can actually see clearly in the world today (especially when compared to the time in which the movie is set): oppresive culture ebbs progress.

Even though I believe the movie is a dramatized representation of the events, I also believe that, at the time, at least some people at NASA came to that realization. In the movie it is shown very explicitly when Katherine has to tell Al Harrisson (the boss - already on the moon guy) where she goes for forty minutes a day, and why she does it.

Nowadays it can be observed in highly productive environments such as big companies, and organizations alike, where non-oppresion organically becomes part of the culture (like it happens in the movie, but maybe not that dramatically).

I'm not sure how or why exactly, but I have a feeling that an one can use the fact that an oppresive culture slows down progrss as an argument for proving human equality to a certain extent. The body of the argument or it's specifiications are content for some other, much longer blog post (maybe even another medium).

On an entirely different topic, another thing that I liked about the movie was the usage of the word computer. Apparently, there was a time where people were computers. I don't think that I was familiar with that. Never in my life I had heard that. Now every that I'm performing some complicated - enough computation I start calling myself a computer because of it.

Something that bothered me about the movie was that lots of other allegedly smart people were very uncomfortable with black people. I understand their uncomfortable feelings, as they were raised that way, but I do not understand their inability to overcome those feelings like only the boss did.

Ethical Reflection on Ready Player One

The discussed quotations as well as the original questions can be found at this activitie's site.

Do you agree with the quotations?
I do not. I believe that the quotations are valid personal judgements of the value of what I'd call alternate / artificial realities. I think that these characters have these opinions because they see more value in the real world than in the one they created, but I wouldn't be comfortable with producing the same judgement or sharing that opinion before actually experiencing the two 'realities' they are comparing.

I do understand that, in that particular story the OASIS can be seen as a distraction that takes away time from otherwise be humanity progressing, but I don't believe that that is something inherently wrong or flawed with the OASIS. I think that the real flaw is the human tendency of seeking distractions(?). I believe humans find other distractions or 'shelters from their problems' even if something like the OASIS isn't there.

Do you personally see any virtues in a system like the OASIS?
I do. I think that the ability to 'live out'/'actually experience' basically anything imaginable (do anything, be anyone) would empower humanity to have a different perspective on the human condition that could help us overcome flaws and limitations that we share as a species.

Do you think our value system (personal and cultural values) could be altered if we spent most of our time in an OASIS like system?
Yes. Particularly the things we value. I think that, as humans, the things we desire are not always well lined up with what is best for us. Both individually and as a group. Like I mentioned, maybe if we got to spend most of our time in a reality where anything is possible then that migh help us shift our priorities towards something that is truer for the betterment of everyone. (I could also see it going the other way around too though, like in the novel)

It'd be important to mention that I believe that the more the experience in a system like the OASIS becomes indistinguishable from the real experience, the more I'd stand for the answerst to my last two questions.

Metaprogramming

I think that most of the people taking this course have actually already worked directly with metaprogramming! At the Programming Languages course that it is taught here by our professor, a significant effort is made towards using what I'd call Clojure's runtime-self-metaprogramming tool called macros. Pieces of Clojure code that would 'expand' into more Clojure code before being actually evaluated.

I certainly did all that, completed all my macros homework and solved the exams macros excercizes. I enjoyed it. It felt super powerful to have metaprogramming integrated to such an extent into a language, because it meant that you could build on top of the language itself. It allowed you to basically extend the syntax itself to do whatever you could imagine. We even read some articles telling tales of how this flexibility allowed some website company to out-perform their competition.

But, in my personal experience, I see the impact of metaprogramming in another area: the issue of compatibility, interoperability and portability. Particularly with frameworks.  The projects that I work with the most these days simply wouldn't work without metaprogramming. I work a lot with projects in which I code in a node (ecmascript) environment, but the programs that end up being the result of my code and are actually executed do not look like my code at all, but instead are products of what I guess could be called 'metaprogramming' pipelines that adapt it to whatever environment it is targeted at. Things such as the Babel and Typescript libraries are powerful examples that I work with every day. Those libraries basically translate between versions of programming languages. Even more obvious examples are the cli interfaces of frameworks like Angular or Rails, where a single command automatically translates into N different programs of N different programing languages (such as when components are created in Angular, or 'entities' in rails).

That is where I see metaprogramming practices being more impactful.

Microservices

I feel like this article is trying to rationalize / justify something that needs no justification. It felt like it was overly defensive  about the architecture it talks about, when it really didn't need to be in my opinion. Another thing that I feel is important to mention about it (especially in the context of the material covered in previous blog publications) is that from the very start it was clear to me that this article came from a much more recent time than the other ones. Not only because of its mentions of companies such as Amazon and Netflix, or terms like 'cloud' but also because it didn't talk about change in a worried or scared way like the ones that date back to the birth of agile.

Another aspect of this article I'd comment about is that, in general, it gave a vibe and it made it fee like the things it talked about operate at a larger scale. A very large scale.

This leads me to a thing that I've been liking about this course that I hadn't commented on before. It had happened in the past ( in the post about software craftsmanship i think ) that I've felt that the practices mentioned in the content would only work on projects and industry slices that are only beyond a certain size or scale level. I've been both liking and disliking this to be completely honest. I like it because it makes me feel confident that we are going over some for real sruff in the course. I dislike it because in our shallow experience, very few of us have gotten to work and operate in those scales, and it is our perception that a majority of the industry around us is not of that scale.

The 4+1 View Model

Throughout all of the courses that our degree goes over, I believe that we actually go through a significant amount of theory about the UML, with its many methods and diagrams.  (the diagrams are the things that stick with me the most because their visual nature). From what I can remember, we did not actually go over a model (such as the one presented) that would integrated all these different tools. We kind of saw the UML as a toolset, went over every tool in detail, learnt what they did, but never actually covered a method that would bring them all together.

I'll start out by saying that there is a particular thing that I really appreciated about this video explanation: It brings together a bunch of UML tools that I knew about but never looked at in that context. When the presenter argues that certain diagrams or documents (the tools) cover certain 'views' of a project, the presenter helps me make sense of them, it makes them look more obviously useful as a part of a whole, not as isolated tools.

But, what bothers me a bit about the explanation is that I don't actually know if this view model came about to try to make sense of all the different assets offered by the Unified Modeling Language or if it was the other way around. I looked it up and I was happy to find out that the 4+1 view model is generic and does not actually require the use of any particular language or notation. So it was the presenter that was fitting the UML tools into the view model. This is important to me because the view model would have made less sense to me if it existed as a way to fit UML tools into a process. I can rest easy now. Now I'd want to find out if there are other view models for software architecture out there that might make even more sense to me, but that'd be a story for another time.

The SOLID Principles

This one is a hard one for the blog. At the moment I can't begin to produce an opinion about the material that can remotely be 300 words long. I think this was the shortest reading material I've had to blog about ever. Especially in class. Not only that but it was uncomfortably informative. Blogging about it is like being asked to write a 300 word 'comment, opinion or critique' about a random set of five entries in a dictionary.

I guess that from this reading I'd say that I'm getting continually more and more impressed the complexities and details of software making beyond solving complicated abstract algorithm problems. It starts to make sense to me why there's so much worrying for the role of a 'software architect', following best practices, crafting and so on.

These principles (or best practices) particularly are very much focused on situations that arise in very object oriented progamming, which is why I am not ultra familiar to the situations. If looked at in greater detail, I believed that all of the 5 refer to a greater principle we hear a lot about when talking about OOP: the concepts of coupling and cohesion, and how we're supposed to have very little of the first one and a lot of the second one. Particularly coupling.

The SOLID principles addres inter-class dependency, which to me is a form of coupling, of having one class care a little too much about another. Perhaps they don't solve or address coupling directly.  I think it would be more accurate to say that, if followed, they prevent high-coupling situations from happening. Unlike refractorings, principle like this aim at preventing those situations.

At the moment I have a feeling that I have not worked in a project that was big enough for these better practices to be of use, so I am very curious to reach the time (if it ever comes) in which I go like 'Oh! this is it! here and now good software architecture practices are explicitly needed.'

GLOBAL THERMONUCLEAR WAR (War Games)

Ever since I read through the part of Ready Player One where the movie 'War Games' appears I've been thinking that we should watch it in class one day instead of the other media that we usually do watch (Silicon Valley). I even mentioned it to some of my classmates out loud. I know that watching it was probably planned in the course all along (I believ that it's in the nature of our professor to have things planned like that all along) but a tiny part of me still likes to believe that he overheard me saying it in class and thought 'you know what? yeah we should watch War Games one of these days' and so he mercifully got it and played it for us.

Anyway, I really enjoyed the movie. Even though our professor warned us that the movie was old and that it showed a lot I don't quite believe it did. Not enough for that warning. Where it did, it didn't bother me at all. I think that when a movie is good like that my brain just accepts the universe it presents to me without questioning it. Another influential factor is (I think) that our professor was there in the setting that the movie presents, and I think he can remember and/or relate to the things in the movie, looking back. He sees and has lived the aging with the movie (Gracefully).

One of the things that I enjoyed the most about the movie is that despite having been around for a long time it actually kind of touched upon the single thing that actually worries me about computer security nowadays: with so so many super important, mission-critical or classified or life dependant information and procesess being hosted or automated with computers and the internet, I sometimes consider the possibility of two or more powerful groups (not nations necessarily) getting into conflict or crysis because of something that happended in the computer-data or internet social media world. Just like the characters in the movie, it's a scenario that I wouldn't like to live through.

Software Craftsmanship

I liked this episode of SWE Radio. Uncle Bob Martin is an interesting guy to listen to, and I think that the host of the show makes a good job as an interviewer, extracting the fundamental opinions that Bob has on a lot of issues. Martin esentially presents a very interesting take on the process of creating software. He says we should craft software.

Martin presents and defends.. what I guess you would call a movement called Software Craftsmanship (I know, it's kind of bad that the name tries to appeal to a relatively young industry and yet it excludes an entire gender). He explains that basically, ever since agile came about, the software industry lost an important focus on software quality. That it is overly concerned with agile processes and meeting business goals. He believes this is wrong, in the sense that the situation is contradictory: software quality helps meet business goals in the long term.

To solve this issue, he says, the software industry should be composed mainly of software 'craftspeople' (he actually says 'craftsmen' /: ). A community of professionals, something that sounds like a guild (he references the law industry and the medical industry), that craft products and should be proud of how they do it.

Even though I think that this is a good idea, I also believe that our software industry is so so varied that it would be hard for everyone involved to follow this movement closely. Especially for the industry at the smaller and smallest scales, this whole movement gives me a feeling that the discipline and effort involved are just too much work for the scale. Just like with doctors or lawyers or even carmakers, I can see this working very well at higher levels, at bigger scales (In fact, in my experience, a culture like this is expected from a programmer at the largest scales). It sounds like a top-down solution that leaves out the bottom tiers. Maybe I'd like to hear about something that is more bottom-up.

Is Design Dead?

These past articles have left me with a strange feeling of.. something that is similar to boredom. Not in a bad or offensive sense, just something... aniclimactic. I end up feeling like these people are too surprised, or overly excited, or worried about the things they are talking about. It is a strange thing to experience. But this was the article that finally allowed me to understand why I was having those feelings. I looked at the dates. I finally laid my eyes on the dates when these materials were written. 
This piece of writing in particular (Is design dead?) was written for a conference that was held in the year 2000. That was nearly two decades ago (damn we are old!).  So now I understand that when these people talk abou this as if it was just discovered the day before or as if it was beamed down from an alien spaceship is because it was! (not the alien part). 

These authors were just learning and gathering experience with new ways of doing the things that they had been doing (probably) for years. They were indeed concerned with what it all meant and how the future was going to be for the industry they knew.

Today, even as rookies, most of us are familiar with iteration and evolution. We came about when these ideas were already out there and being used to produce software at the largest of scales. When Fowler says "no, design is not dead" it is obvious to me now, when I'm conscious that even when you build projects in iterations and evolutions you are always making little design choices, always desigining, even if at the tiniest of levels. But now I understand why it wasn't obvious to him. Why it wasn't obvious to them. Back then.

Who needs an architect?

It seems to me that this dude (Martin Fowler) was (at least at the time of writing this piece) as confused as I am about sofrware architecture. He is inconclusive (to say the least) about software architecture itself. He does make some subtle and interesting points (most of which I agree with) about the process, art or act of making software but I really disliked how he had to ramble on and on about the search for the 'true definition' of software architecture when it appears to me that his article is not about that perse. I'd be grateful if he could just state his points plainly and just make his thought-train-discovery process and discussions (the rambling about the definition of architecture) available to the reader if he/she desires it. I'm not reading his stuff for entertainment.

His entire article could be summarized in the following: "There is no one definition of 'software architecture' because it is a very subjective concept because building software is not limited or bounded by anything physical, but only by the minds and intelligence of the people doing it." I agree with that. I didn't need the rest.

In my eye design has a very simple definition: You are going to produce an object. A thing. That thing has to meet/have a very peculiar set of goals and requirements. If you create your object in such a way that does, you've made a good design. Otherwise, you haven't.

That is my personal definition, the one that I go with in my life. It is very general. Anything beyond that would be a bit too specific for me to try to apply it generally like I do with the one I mentoned. This is why the authors piece on the search for a specific and yet generally appliable definition of what he calls 'architecture' is very unenjoyable to me.

Software Architecture

This was an interesting read to me because it managed to convey the ideas and the intuition behind the thing that it was explaining (software architecture) without saying a single word about how anyone is supposed to actually go and create ‘a software architecture’. It kind of makes sense, since the thing it is talking about is very abstract itself. “It should do this, and do that without too much of this, and with just the right amount of that, but always taking that into consideration.” But not a word on ‘you might want to use these diagrams’ or ‘use a text file’, ‘a mailing list’. Just ‘a document’.

What I understood from that is that the document defining software architecture can be a lot of things, because you can do software architecture in a lot of different levels. At the beginning that didn’t quite ‘click’ with me.

But if there’s a position from this reading that I can agree with is this: from a programmer's perspective, knowing about and having your design (or ‘architecture’) in hand is like a guiding light. Like a scuba diver’s lifeline, or the mission objectives in a video game. It keeps you on track. When you take on a project, defining that higher-level ‘solution’ is a problem that you should only solve once, and the solution you produce must be one you can adjust later but most importantly, it must be one you can trust later. Because later you’ll be concentrated solving the fun lower-level implementation details and you don’t want to be questioning why you were doing all this to begin with. No one has time for that, you already went through it. Having that clear ‘architecture’ in mind allows you to go ‘oh, this is why things are this way, this is what that is supposed to do, this is how I’ll make it happen’.

In my experience, I’ve received this guidance from lots of different places: from a well-defined project folder structure (that is initially empty), to an ugly-looking drawing-diagram that conveys just the key points of what the thing I’m working on has to do. This is why I think it makes sense for the author not to talk about the object representing the architecture as anything other than ‘document’.

Moon Machines: Navigation Computer

I believe that the Moon Machines: Navigation Computer documentary presents a good example, a good argument of why careful design is important in almost every piece of technology one sets out to make.

In my opinion, the documentary presents the story of the computer (and computer software) that guided the navigatio of the first Apollo mission to go around the moon and back. It mainly presents such story through the experiences of the 'programmers' and engineers behind that project. People who were (at the time) young students from MIT.

These people tell stories of something that ended up being a software project, but at a peculiar time in which software was a very new thing. As such, it is evident that the study of it's contruction and the processes behind it were not a thing yet. It is in those personal stories by the developers in which the argument for the need of a study of software making study becomes evident. The tales of the developers and of the unfolding of the project are stories of hardship, of problems that software projects of today sometimes suffer too.

With the knowledge we have today it was easy to look at the problems they mention: being behind schedule, and having the role project demoted because of it's lack of readyness, as a consequence of the lack of experience and planning that they had. But it is also not hard to relate to the frustrations they underwent as precursors to these problems: not eve knowing or planning what they were supposed to do, having no clear goal or requirement in mind at the beginning and poor organization between the teams of software and hardware.

I think that those people, thosw first developers, are  to thank for the knowledge that today, to a certain extent, shields us from falling into doing the same. For the knowledge that software is just another piece of technology product of engineering, and that like any other engineering project, ends up being better if coming from processes of design, planning and careful thinking.

Intro

Hi there!
Welcome to my blog for the software design and architecture class!
I'm Gerardo, most people call me Gerry. I'm the 8th semester of the ISC program and I have the 'regular' schedule according to the program.

At the moment I do not have any particular expectations from the course other than to go through a large amount of good practices to follow when constructing larger software projects. I believe that most of them will make sense and will actually be helpful and of guidance when the time comes for us to actually work on such projects. (Hopefully, and maybe, just maybe, we'll get to play around with legos again).

 I'm generally interested in computers, programming, and what computers can be made to do for us as a species through programming. I like knowledge. Other interests of mine include videogames such as the Halo saga and Super Smash Brothers. Generally I spend time learning random stuff on the internet and watching anime and/or going out with my partner.

Recently I re-watched Netflix's Devilman crybaby and I enjoyed it just as much as the first time, it only reaffirmed my opinion that it is am true masterpiece and a modern classic. During the winter break I also watched 'Rascal does not dream of bunnygirl senpai' and Trigger's 'SSSS.Gridman'. I enjoyed both very much, although I'd take the latter one if I had to pick. When there's nothing to watch I just binge the infinite Rick and Morty stream while I do other stuff.

At the beginning of the winter break I challenged myself to read Cormen's Introduction to Algorithms. It's been tough. I'm also reading 'A Tour Of C++' by the dude who made C++ himself. I figured I should know the language before I graduate.

Music-wise I've been listening to lots of 'electro'(?) in my search for music similar to Porter Robinson's 'Worlds', with artists such as k?d, Robotaki and Illenium. I've also been listening to local jazz by 'Alex Mercado Trío'.