Posts

Chapter 11: Metaprogramming

Image
The last article read was “An Introduction to Metaprogramming”, an interesting article where Ariel explains the concept and some examples of metaprogramming. Starting of describing the different types of metaprograms, like compilers, interpreters, parser generators, assemblers and preprocessors, metaprograms come in many shapes and forms, which main goal is to eliminate or reduce error-prone programming tasks. I have heard of this concept as a utopic approach to things, however, I haven’t seen metaprogramming first hand. At first, I thought it was a really complex way to do things, but after reading the article, it doesn’t go that deep into weirdness. Beginning with the first example; it clarified how the concept of metaprogramming works, a script that wrote another file with the code expected. While the ruby snippet shown was not some other world stuff, but the example is pretty clear, we can write codes through code. Now, the second example goes a little bit deeper
Post a Comment
Read more

Chapter 10: The hunt is over...

Image
Done. We have read through all Ready Player One novel, and leaving all the plot twists and awesomeness aside, there are lot of ethical matters in the wind, let´s try to land them on this blog post, shall we. First; technology dependence is a real thing. While not as notable as seen in Ready Player One, technology is beginning to take an important place in most of our lives, however, a balance (or at least, limits) should exist. I do personally see systems like OASIS materializing in a distant future. The closest thing I personally know is Second Life, an online virtual world, where many people involve themselves in education, business, social, and real estate matters. Even some people make real money out of working inside the virtual world through their avatars. I don’t know if something intrapersonal has happened inside that simulation, but I think that different types of cultures may sprout from inside the system, so I believe that our value system could be altered if we
Post a Comment
Read more

Chapter 9: Microservice Architecture: A whole new Architectural world.

Image
After reading the article, I started relating microservice architecture with the activity we made when we talked about components and Lego bricks in class: This type of architecture is made of smaller and independent services that are linked together to form a concrete service. With the image below, we can see a clear representation of how this is conceptualized. However, there is a small detail that separates microservices from monolithic services; while the later gathers all functionality into a single process, the microservice separates each part of the functionality into a separate service, allowing scaling with distribution of the services, replicating as needed. This is the aspect I liked the most; low key planned modularity for software architecture (or at least that’s how I see it) There are a lot of interesting features of this type of architecture (with a heavy approach to encapsulation, as I dare to confirm), such as Componentization via Services, Organized ar
Post a Comment
Read more

Chapter 8: (+ 4 1) View into Architecture (Hooold up, that’s Clojure, that’s on the other blog).

Image
So, this blog is about the “4+1” view into architecture. Why is it called that way? Why not only 5 (as, for what I have learned, 4+1 equals 5)? Well the concept in which this type of view rose is the key. What this type of view proposes are 5 grouped different types of views; Logical, Development, Process, Physical, and Use-Case. The logical view explains us what sort of objects are we going to be building, such as classes and objects, and how this object act within the system logistics. However, the scope of this view is limited only to the implementation of the system. The second view is the development view, which is aimed towards developers explaining how the system is organized. With this in mind, the developers will be able to recognize which parts of the system are connected to which. This consideration allows the developers to work with the system under development. This view is only focused on the organization of the system development. The process view desc
Post a Comment
Read more

Chapter 7: One of our favorite state of matter´s principles.

Image
So, we are talking about SOLID in this blog post. No, not our favorite state of matter (that should be plasma, of course) but a group of five principles of object-oriented programming and design. SOLID covers how to program better and cleaner through different principles. I think that these 5 principles come together and forms a “solid” foundation on what and how needs to be done (it took me some days to think of that pun). The first principle may be pretty straight forward, however, it is often overlooked, leading to the start of some messy code; every class should have exactly one responsibility. While many people avoid following this principle and starts delegating responsibilities to functions inside a class, this can lead to confusion of how a specific class works, and the design of the whole project may start to crumble. The open/closed principle allows us to make classes ready to be extended if needed, but be closed to modifications, this avoids fragility to the o
Post a Comment
Read more

Episode 150?: Uncle Bob´s tips for Software Craftsmanship

Image
In this podcast, we heard Bob (better known as Uncle Bob) talking about Software Craftsmanship, a very interesting title for what the architects (should) do. The first argument that Bob tells us is the one I will be focusing on this article; the best kind of architect is the one who codes. So, what did Bob meant with this? As we have talked about on the past entries, there is a big distinction between a boss and a leader; being the latter the one that brings some kind of balance between directing and acting. While the boss is the one that only points at what needs to be done, the leader works with the team towards that goal. Bob points out that the separation of leaders of the team from coding is a huge problem, that’s why architects must get involved with the work that is being made. Why is this important? Because leaders that don’t get involved make critical decisions and then unbind themselves from the project. This “urge” to get everyone involved in the project is
Post a Comment
Read more

Chapter 5: Should we make a funeral for our beloved stage Design?

Image
Design; one of the stages we hate (or love) the most has became irrelevant. Or maybe that's what some people say. Is design dead? Well, the first paragraph of the article made me think that the headline was click-bait. Starting off saying "... involves a lot of design, but does it in a different way than established software processes", made me re-think of the title. A clearer approach could have been "Design is evolving", however, I agree with what the author is implying; classical design phase is being replaced by evolutionary design, thanks to the XP outburst. Later in the article, the author states the big difference between planning design and what XP allows us to do with dynamic design. As they are “counters” to each other, each has its advantages and disadvantages (the author implying that evolutionary design is better) I think that getting a balance of both should be the goal. Yes, I love evolutionary design (as it is easier and requires less t
Post a Comment
Read more