S/W Design and Arch Nat's Blog

I've never seen this movie before, and I had a great surprise, even when I did saw the "remake" form 2007 and I consider it as a meh movie, I really enjoyed this one. First of all, I was hooked at the star because of the protagonist, that is not sold to us as an unreachable super genius of the computers, but as a geeky guy that had plenty of free time, and the incorrect decision making on his childhood. Adding to this, it feels like a character that happens to be in the middle of extraordinary events, using his own skills to get out well from the chaos that is made by he trying to find the new video games form an interesting company. The plot is interesting, as my professor said, for anyone in the last decade to get interested into computer systems or programming careers and get me with the doubts if I had real expectations around when I got into computer systems engineering or I was actually expecting some kind of super hacking courses and to being sit in

I liked this podcast, it has some strong opinions from Bob Martin that even considering that the podcast is from 10 years ago, are really applicable for the industry of the software. I think that programming is very satisfying just for some of the reasons that are described as the craftsmanship, like the art that involves maintaining the readability and the refactoring always clear into the code, and not getting totally disconnected from the design even when into the Bob's preferences around the agile methodologies. One of the points that got my attention is the way he expresses himself about the design and architecture documents (and other documents as well) letting us know that the agile methodologies can produce outputs of any kind, that this mentality as programmers of not producing any kind of documents while working agile it's just wrong, and we shall just be used to get great practices into our own process of making software. Other topic that it's touch is this i

For this article there is several topics that appeared very interesting to me. For the initial themes treated, one was the difference between the traditional structured design, and the evolutionary design, and it's a matter that I've even seen as a difficult topic because of the different perspectives presented even by my own teachers, some of them teaching me that the planned design is extremely important and even forcing this practices into our projects, but in the other perspective, some professors taught me to be evolutionary, and to make incremental design based on prototypes making really confusing the decision for the design every project I've made. Also, one of the things that I've found curious into the article is the association that the author makes between the refactoring and the YAGNI's simplicity to the evolutionary design. It's not that usual to understand the "best practices" of programming as supporting any bigger concept than the co

For the start of this article, the author starts telling us about the architecture and the difficulties that you may have defining the software architecture's function. As it's stated into the first page, we can find a definition according to the IEEE's definition, but it's considered by Ralph Johnson as a bogus definition, understanding that all the terminology used it's from the developing perspective, ignoring totally about the "others perspective" and just focusing in the opinion of the developers as the most important components into a particular system. One of the most interesting parts that I've found into this text is when the author mentions that a great architecture tries to eliminate the architecture. This perspective, that we must procure for all the system to be modifiable and to be easy to change, it's not really familiar to me, because I didn't learn for the systems to be modifiable, even when sounds logical when you think in a