An Introduction to Metaprogramming (Commentary)

Metaprogramming seems to be a useful tool when one is actually able to use it to solve a real practical problem. Otherwise, metaprogramming looks like an interesting and enjoyable experiment to understand how a language works.

Basically, metaprogramming referes to the art or science of creating programs responsible of creating other programs and/or running them. When is this useful? When a program can be modified during runtime on interpreted programming languages, when a program requires a lot of repetitive code, or when a program needs to react with a solution on the fly.

For many interpreted programming languages, one of the fundamental solutions for what problems may arise when metaprogramming are the "eval" instructions. What these instructions do basically is transforming strings into interpretable statements.

How about you create a program whose only purpose is to read and execute whatever is found in a text file or even just run a part of a program's source code?

Ready Player One: Trapped in Paradise

I onced read that, since we spend almost half of our lives sleeping, dreams could be considered as an alternate reality. The interesting thing about sleep is that it accomplishes more than biological functions. I have, time and time again, gone to sleep when I feel particularily world-weary. This is another function of sleep, a shelter from reality.

Ready Player One confronts us with a very interesting idea with a most interesting plot device: the Red Herring. OASIS is presented as a paradise for geeks and freaks, the only place where your useless trivia is worth something, and for the so-called "gunters" it even presents a sense of purpose. If we look at the dystopian future where RP1 takes place, we can see the existential need of the characters for the OASIS.

RP1's world is an unusual brand of dystopia, freedom exists but not the means to pursue it. That is unless we consider the OASIS. At first sight, OASIS looks like the solution to a boring stagnant life. An alternate reality where you can be whoever you want, have the powers you always dreamt of, and pretty much do anything you've ever wished.

OASIS also represents a placebo in a very ill world with very ill people. With no semblance of ambition, hope, or purpose among most of the inhabitants of reality, the simulation proposes a way not to feel stagnant, meaningless, hopeless.

Still, OASIS is a limitant, a shackle, and a prison. It corners its users into thinking that it is the only place that matters, the only place where they can actually fullfill themselves, where they can achieve something of meaning. We need to remember that, as a simulation, the results obtained in the OASIS are completely non-trascendental to reality.

This is where the hunt for the Hallifay's Egg factors in, it offers freedom from this mindset, freedom from OASIS. The means to achieve something of meaning in the real world.

The sad truth is that this "dystopian world" is not a very warped depiction of today's world.

In our culture, our first metric for how happy people are is through their Facebook profile. We even have some sort of mental checklist, they must be happy because they have a job, a higher education, a relationship, hobbies, friends, family, and they are constantly posting about their day to day activities, reminding us that their life is full of meaning and satisfaction.

We want to at least pretend we are happy so we engage in the same behaviors, we share every little aspect of our lives in the hopes of creating a character for ourselves, a proxy of us devoid of all tragedies, demons, and problems that ultimately play a role in definning our real selves.

Ready Player One ultimately asks one very simple questions: "Do we really want to live a life of lies or are we just afraid of reality?"

Microservices (Commentary)

Monolithic development seems like a convenient solution to one-time problems. An older solution may endure the passing of time until it needs to be changed, which is the ideal situation where this design paradigm can be used. Still, with the ever growing technological culture of today, large, solid, and dense systems which are tightly entangled, are no longer a solution. Design changes, code changes, and platforms need to be updated constantly in these fast times.

Microservices serve as the building modular blocks for applications and software solution in the scale of really small, to humoungous business. It is easy to replace a defective block with a perfectly working one in little time, which makes it easy to advocate for this kind of design paradigm. When solid monoliths fall, they fall hard, and they usually take a large part of the system with them.

Decentralization is a central point of Microservices (oh, the irony), that way, when blocks fail, not many components have their operations directly affected. Each man is his own man, a philosophy very akin to the spirit of our times.

The 4+1 View Model

In the course of all my years of studying Computer Sciences, UML has been hammered religiously into my brain as the best (and sometimes only) modeling standard for Object Oriented Development. It has been a staple and core philosophy when it comes to documenting code (when it comes to documenting classes right after their coding, I am guilty as charged), so there's no other way I can imagine abstracting all the data that goes into my code.

Now, while 4+1 may seem a little more compact (less is more, right?), it actually does a very heavy lifting for the design. As far as the not so ancient tale of the 5 blind programmers go, every piece of TI-related concept or matter is subject to multidimensional analysis by different parties, but they ultimately hold water only as the dimension pertaining the eye of the beholder. 4+1 is a perfect way to analyze software components for what they represent in different fields.

4+1 presents a condensed multidisciplinary view of the components behind the design, coding, developing and planning of software pertaining software, proposals, hardware, and even makes space for user specification (the "1" in "4+1"), while delegating the corresponding responsabilities upon the acting agents.

Understanding the SOLID principles (Commentary)

We tend to get excited when experimenting an orginazed concept such as Object Oriented Programming, we want to make full use of all its qualities, quirks, and virtues without taking into mind if we are actually harming the development of the program or project we are creating.

Thankfully for us reckless Object Oriented programmers, the SOLID principles offer some guidance as to what to and what not to use. Though, at first sight some of the most fundamental SOLID principles seem to be directly at conflict with OOP guidelines, we need to take a pragmatic aproach when looking at them:

-Single responsibility principle: The swiss army knife may have been one of the most useful, iconic, and creative inventions of human history, but most of its functionalities can be singled out in several individual tools that may acomplish the job more easily. This principle advocates for single-purpose classes.

-Open/Closed principle: Open for extention, closed for modification. Instead of swaping a class' behaviors, it might be better to add new ones, specially if there are classes that inherit said behaviors.

-Liskov substitution principle: Similar to the previous principle, this one advocates for nonmodification of inherited methods, as to ensure that both classes (base, and heir) are interchangeable in most concepts. Now this is a direct affront towards inheritance and polymorphism, two of the principal ideas behind Object Oriented Programming, but it will also make the code significantly more maintainable. Remember, pragmatism trumps all.

-Interface Seggregation principle: Similar to the single responsibility principle, this concept advocates for single purpose interfaces as to not burden a class with too many behaviors it will ultimately not use.

-Dependency inversion principle: Make sure to make your classes dependable of abstracts instead of concretes. Why? Concretes tend to change while abstracts are generally idle.

May be hard to acomodate these principles with what we know of OOP, but, for the sake of good code and good practices, it is worth the try.

Software Craftsmanship (Commentary)

The term "craftmanship" is nowadays used mostly for the arts, or for hand crafted goods, nobody would really think about a programmer "crafting" code, much less a software architect.

Regardless of if software is considered an art, a science, or a craft, we cannot deny that most code we produce, inherently has something of ours in it, let's call it a personal touch. Software Craftsmanship begins with pride for one's work, much like an artist's pride, but it also comes from an idea of "whole".

A software architect cannot stay on the sidelines of the way code is being developed, they must be first and foremost coders. Otherwise, how could anyone be able to feel pride of the code that is being produced in one's project?

Software Craftsmanship also carries the notion of improving any and all code the coder participates in. "Leave the camp tidier than how you found it", as the boy scouts say. This is how craftsmanship defferentiates itself from old regular Agile Development.

This concept contains the core of several others, such as speedy development, quality assurance, Software Architecture, and proper refactoring, all based on the principle of "love for the craft".

Is Design Dead? (Commentary)

Reckless programming is a hobby of every high schooler with interests in computer sciences, or any computer sciences freshman.

We tend to think that if we know some of the quirks of the given programming language, we do not have to think too much about what goes into developing, because we are not entirely sure about how the program is gonna look like either functionally, or in code, we just do what sounds right for us.

Apparently, "reckless programming" shares its main philosophy with the more official sounding (official-ish) "extreme programming", when it comes to complete and utter disregard of design and/or planning. We know what our code's goal is, we'll know if it accomplishes it, we do not really care about how each module or part of the code works towards this goal, or how such modules will change, but we may know how we want them to change towards the goal.

Here's the thing, though, disregard for rules, although fun, also carries the stigma of messy and unmaintainable code. If no planning is done for the development, we cannot expect to have plans for when everything finally fails.

On top of this, if refactoring is not considered, well, we are gonna have to start all over.