DEV Community: BigSpaces

CSS: The display property

BigSpaces — Sun, 19 Feb 2023 12:41:43 +0000

The goal of this post is to provide you with some basic (really basic) understanding of the display CSS property. Rudimentary, foundational... Advanced users need not apply.

Today I took industriousness to produce the following HTML file.

<p>Behold, a bunch of pixels</p>

I decided to go the extra mile and write two more lines.

<div>Behold, another bunch of pixels</div>

<span>Yet another group of pixels</span>

I am on a mission to understand the CSS property display, which brings me to right-clicking and the "inspect" option of my browser, and this is what I see:

p {
    display: block;
    margin-block-start: 1em;
    margin-block-end: 1em;
    margin-inline-start: 0px;
    margin-inline-end: 0px;
}

It seems that even a simple paragraph element comes with a number of default CSS properties, among them my beloved display.

First logical conclusion

display: block is a default property of the paragraph element.

Tinkering around, it is easy to discover that this is not the case for the span element, though it is for the div element.

Down the display rabbit hole

What is this mysterious thing that appears in some CSS elements?

The fact that it comes as a default property in elements like paragraph and div tells me that it is something foundational, as if putting legs under a table, even if the table has no specific use yet.

Different elements, different values

This is an experiment to run: create different types of HTML elements, and inspect which CSS properties do they incorporate.

We quickly discover that the <table> HTML element, has the display: table value.

Definitions

My suspicions are confirmed when I research w3schools.com.

First I learn that display: block displays an element as a block element (the css version of duh!)

A block element starts on a new line, and takes up the whole width.

display: table displays an element as a table element.

Now, that's useful info when it comes to formatting my CSS elements. I need my elements to behave in a specific way. So...

What other values can display take?

Short answer: a whole bunch.

All of the available display values can be grouped in the following categories:

Values that display an element as a certain type of CSS container
Values that let the element behave like a certain type of CSS element

We also have a few outliers:

display: none removes the element

display: initial sets the property to its default value

display: inherit inherits this property from its parent element.

display: contents is some David Copperfield number. Not even going to pretend I fully understand it, let alone do a decent job at explaining it.

Examples in action

Let's take our paragraph element, which comes with the display: block default, and mess about slightly. If we open the inspector and change the block value for the inline value.

According to w3schools, inline will make the element behave like an inline element: height and width properties will have no effect.

What happens if we change to display: none? It should remove the element...

...and it does!

My working definition:

The display property allows our CSS elements to be displayed as a certain type of CSS container or behave like a certain CSS element.

...it can also do a few other things: make the element invisible, reset or inherit certain properties, and modify the child-parent relationship.

Containers, elements, children, parents, and inheritances

I have only scratched the surface of the display property in this post.

In order to fully deploy the power of this property, one needs to understand the inner workings of CSS containers and elements: flex, grid, lists, columns, rows, how the properties are inherited... and the DOM.

I have just started my journey with CSS, so here is where I bow, thank you for your time, and hope that this helped you understand the display property enough just so you and I can keep layering knowledge on top.

Thank you for reading!

git add .
git commit -m "My respect to people who design purely with CSS"

Dockyard Academy. Passing the baton.

BigSpaces — Fri, 27 Jan 2023 11:21:21 +0000

I am talking to you, Dockyard Academy Cohort Newbie. This is me just four months ago. I am about to start Dockyard Academy and level up my skills as a software developer. I do not yet know this is one of the toughest things I have ever done. This is what I want to know:

- Stick to the curriculum: all you need is there. It will be tempting to find other sources of knowledge, books, videos, forums, etc. At the end of the day, all of those will be distractions and will waste your time. It will be better to accept that Brook has written the curriculum with your growth in mind: it is the only book you need for now.

- Create memory cards: You are going to be given a hundred units of knowledge per day, and your brain will be able to grasp thirty of those. Of those thirty, you are going to remember ten. If you get into the habit of writing and using memory cards, you will increase those percentages. You can write them in physical form, or in an app such as anki. This will give the information a chance to sink into the brain, and serve as a scaffold for the rest of the curriculum. Repetition simply works.

- Repeat the syntax. Tatoo it. Practice it: as per the repetition principle above, it will pay to drill and drill certain common syntaxes: declaring a function, writing Enums, nested values, maps vs tuples vs lists... Those things, if automated, will be wings that will make you fly. Drill it. Do syntax pushups.

- Multiple passes. Read the lessons several days ahead: it will pay to read lessons a few days in advance, and do so multiple times. You want to know which words and concepts are familiar, and which ones turn your brain into peanut butter. Mapping the territory before walking into it is wise, and will pay off.

- Make public ignorance a corageous virtue: get very comfortable with the following expressions: "I am lost", "I do not understand it", "Could you please repeat this?". Make understanding something more important than the uncomfortable feeling of appearing (or thinking yourself) stupid.

- Multiple passes (part 2: the return): If at all possible, repeat exercises several times. It will give you a boost of confidence to see your mind and your fingers get more and more competent with each pass.

- Help your classmates: you may think that, as a newbie, you do not have a lot of help to offer. That will be true in a number of cases. Still try and be a net positive and lend a helping hand as your default position. There is nothing to lose and a lot to gain (and learn) from it. Stretch yourself into the person that will have something to offer.

- Ride the tiger: unless you are the coding demigod I wish I was, you will surely experience some of the following joys: cognitive overload, sleep deprivation, self-concept anihilation (good old classic self-doubt), anxiety, euphoria, depression, stress... remember that they call it bootcamp for a good reason. It is meant to stretch you. In times like this, remember that the sun will rise tomorrow, and the following day, and you will surely make it to the end despite the ups and downs. Dig into your hidden superpowers. Persist. It pays off.

- Clear the deck: in as much as you can, make space for the bootcamp, the lessons, and the spectacular amount of new knowledge and concepts that is going to come your way. Press "pause" in as many things as you can press "pause" in, and allow your focus to be like a laser that has a job to do.

- Take care of yourself, pleaaaaseeee: allow your brain to assimilate stuff by sleeping as much as you need to. Get into a good routine so your system is not out of whack running on cortisol and adrenaline, go outside and allow the sunshine to hit your skin. Go to the gym, meet with friends, create a healthy life that will sustain you and buffer the demands of the bootcamp. Know your limits and respect them. Your system will thank you for it.

And finally: ENJOY IT!! You are about to go through an experience that has the potential to transform your life. It is unlikely that you will do something like this any time soon. It is the very definition of an adventure. Hone it. Savor it. Honor it. Give it your all.

git add .
git commit -m "Academy Completed. Massage at 4pm."

BigSpaces

XHR and a simple story

BigSpaces — Wed, 14 Dec 2022 14:38:40 +0000

Be forewarned. This is not a technical document...

Alas, if you want to have a nice little pause from the daily grind, have a listen to Nils and read on:

It was a mere 48 hours ago I did not know what XHR stood for (XMLHttpRequest, for those of you in the same spot I was).

It is surprising to know that a fish can go a lifetime without hearing about water. Yours truly can be programming in Phoenix and using Dev.to without knowing that absolutely everything that happens between my web browser and the server is mediated by this XHR thing.

I'll save you the Google Search: "The XMLHttpRequest Standard defines an API that provides scripted client functionality for transferring data between a client and a server."

And from your faithful Wikipedia: "XMLHttpRequest (XHR) is an API in the form of an object whose methods transfer data between a web browser and a web server. The object is provided by the browser's JavaScript environment. Particularly, retrieval of data from XHR for the purpose of continually modifying a loaded web page is the underlying concept of Ajax design. Despite the name, XHR can be used with protocols other than HTTP and data can be in the form of not only XML, but also JSON, HTML or plain text."

You may be tempted to think, as I initially did, that it was just one more concept in a long list of things I still do not know.

One of my mentors insists that I get really good at the fundamentals, at what is happening under the hood, both conceptually and technologically. So much so, he unpacked the basics of XHR by virtue of helping me create an XHR object from the browser's console, and using it to make a request to an API.

Truth be told, I was still just merely grasping the basics: "ok, javascript object that makes requests and stores responses from the server. Ok, abstract thing that always happens under the hood in a web scenario, no matter if you are using Ruby or Phoenix or what-have-you".

I understood this was at the core of every web experience I ever had, but did not connect how that could be of utmost importance to me.

The following day my classmates and I got the chance to spend some time with Dave Lucia, and we asked him about his interview process when he selects junior developers (hungry for work, we are).

I kid you not. The following words came out of his mouth: "I may ask you to tell me what happens at the level of the browser for each web request. I want to know you understand the fundamentals of what is really going on if you are going to program on top of it"

Jaw drops. And suddenly I am very interested in XHR! Fundamentals. Fundamentals. Fundamentals.

BigSpaces

git add .
git commit -m "Do, a dear, a female dear. Re, a drop of golden sun..."

Recursion - Head(aches) or Tails?

BigSpaces — Thu, 08 Dec 2022 07:36:19 +0000

Once you get pattern matching and recursion, you are set

I remember googling pattern matching and recursion, hoping to watch a couple of videos and be set with both skills in the time it takes to make coffee and take a shower.

That was a couple of months back. That should give you a clue.

In this article, I am going to leave aside the questions "what is recursion" and "why should I use it". Recursion exists and, if we are developing with Elixir, we need to know it. Period. Next, please.

Now that we need to contend with recursion, my aim is to shed light on the two types of recursion I know to exist: regular recursion, and tail recursion.

Regular Recursion

In regular recursion, a function calls itself while it is in the middle of doing something.

This is like me, when I walk into my bedroom and run the function "tidy_this_thing_up" and, in doing so, I open a closet, where I run the function "tidy_this_thing_up" again, and open a drawer, where I run the function "tidy_this_thing_up", and I find an old hard drive there, and carelessly plug it in, so I can run "tidy_this_thing_up" for the fourth time.

Two problems arise with this model.

First, we need to define when to stop. We need to call it quits at some point, because I have not yet started to tidy up my room, but somehow I am finding myself reorganizing photos of a summercamp that happened 20 years ago.

I need a base case, a place where I can tell my function: "you are done".

The second problem is memory, resources... keeping track of all I am doing. By the time I am organizing my external hard drive, my brain may have completely forgotten about my untidy room, closet and drawer. That'd be a stack overflow or a memory collapse.

OR, if I am extremely resourceful, I will finish organizing my hard drive, and go back to the drawer, tidy it up, return to the closet, tidy it up... My list of pending tasks has been growing and, if I am a man of my word (and functions tend to be), I need to follow my breadcrumbs back and complete all the pending tasks I have been leaving half-cooked along the way.

It is taxing but, if I run my functions this way, I will end up with a tidy room.

Tail Recursion

With tail recursion we do not call the function tidy_this_thing_up in the middle of tidying something up. We call it again once we have finished tidying something up and can move to something else.

Immediately this seems cleaner, easier, more elegant. The steps required do not accumulate one on top of another, with a potentially eternal list of pending tasks that were never finished and that are holding part of our resources hostage.

Tail recursion would ask us to do something, finish it, and then do it again.

In my tidy the bedroom example, I would find a way to organize the major task into sub-tasks that I can complete before I start a new task.

One potential implementation, maybe not the only one, would be to have the tidy_this_thing_up function to keep a list of sub-elements that need tidying.

I would walk into my room, notice three bookshelves, two closets and that chair with clothes (you know the one). That makes a list of five things to tidy up.

I successfully run my function on bookshelf1, then bookshelf2, then bookshelf3, then closet1, and there I find my drawer but, instead of halting the task of cleaning up my closet (Eminem dixit), I simply add "drawer1, drawer2, drawer3" to my list of things to tidy up, I finish tidying up my two closets, my chair_with_clothes, and then I go tackle the drawers one by one.

(We still need to have a criteria for when to stop and call it a day)

Final thoughts

One of my mentors at Dockyard Academy put me through the exercise of writting each step of the process of a recursive function (on paper, the nerve!).

First, he made me write out the regular version, then the tail recursive version.

Both exercises were herculean efforts: pick a pen and use it to think (on paper, the nerve!).

Kidding aside, I do recommend this exercise to anyone studying Elixir or wanting to really (really) understand what recursion is doing. It forces the brain to internalise recursion processes.

At the moment of writing this, I feel that tail recursion is elegant, efficient, economic, and regular recursion is a potential uncontrollable mess. I know I am just being dramatic (mixing feelings with coding, how dare I). There may be use cases for both, I am sure.

Who doesn't enjoy the thrill of danger of a stack overflow, anyway?

All of this makes me think of the old regular recursive fights with a certain ex-girlfriend. The stack kept piling s**t up and nothing ever got solved.

As I grow older (hopefully wiser), I prefer my conflict-resolution tail recursive: fixing one thing, and going for the next one. It actually works wonders. Sometimes even writing it on paper helps.

Perseus went coding with Ariadne

BigSpaces — Thu, 24 Nov 2022 07:27:31 +0000

Medusa is one of those ladies you do not want to mess with.

To begin with, she is pissed off, and she has reasons to be. She has been cast to the underworld by her devoted protector, for being pregnant with the offspring of her protector's worst enemy.

Also, being pregnant kind of broke her vow of chastity, and there is always a price to pay for breaking vows, either intentionally or accidentally ("it wasn't my fault, I had a bit too much to drink" doesn't cut it when it comes to vows).

If things were not bad enough, the one thing she had going for her, her beauty, is taken away from her. Her entire physical appearence starts transforming, following her internal spiritual state (ugly).

So, when your world gets turned upside down, you carry the offspring of your enemies, and are sent to the underworld by your protectors because you broke your own vows, and you turn ugly, you have reasons to be really, really pissed, because life ain't fun.

Medusa had the power of freezing anyone who would set eyes on her. That is a pain in the butt because it very much guarantees nobody is going to accept your social invitations, and the only ones coming to see you possibly want the glory of killing you and returning to the upper-world with your head claiming victory.

So many wannabe heroes showed up, attempting to kill Medusa, and one by one she froze them all with just one look.

Think of the poor hero wannabe: you want to cut her head but suddenly you see seven heads. Have you heard of stack overflow? That is it. No recursive function is going to save you a la take_head_off(take_head_off) - It is an impossible problem for the hero wannabe with no base case. You are in a loop.

Believe it or not, I was thinking along these lines yesterday evening, when I realized I have a bit of a Medusa problem with coding.

I go take my prize in the Elixir industry, and seven more doors open: Machine Learning, Phoenix, Liveview, Kubernetes, Linux, Erlang, CSS.

Funny enough I open several doors, because I am a hero wannabe: I go into more Linux, Machine Learning, CSS and Phoenix. If that was not enough, I decide to investigate music coding with Sonic Pi, but then another seven doors open inside of those universes.

The result? Medusa has me: I am frozen. I am not advancing. I am not claiming my victory. She has my head.

So now that I know I have a Medusa problem, I requested a coaching session from the man that defeated her, and see if I can, with enough mentorship, get a win on this one.

Enter Perseus. Son of the Gods.

Perseus, quite the guy. To begin with, he ain't no hero wannabe. He is the son of Zeus, which gives one certain klout, but he was humble enough to know that he could not defeat Medusa with his own powers.

Lesson one: accept that you are losing to begin with

This has been my first mistake. I thought I had it within me to learn it all. I thought, in my vanity, that if I could organize myself well enough, and if I could watch the right tutorials and take the right courses, I could take Medusa's head with the unlimited powers of my own brain: BigSpaces against all the tech knowledge in the world.

Yeah, right.

Perseus first lesson is "no, dude, don't play that game. You need to enter Medusas' house knowing you cannot win. If you go for the win, you will freeze to stone". And I did.

Ok, lesson one is counter-intuitive. Know your limitations. Do not go for the obvious win.

Lesson two: get help and tools. Arm yourself.

The second thing about Perseus is that he requested help from the gods, and he got it.

From the Hesperides he received a knapsack (kibisis) to safely contain Medusa's head. Zeus gave him an adamantine sword (a Harpe) and Hades's helm of darkness to hide. Hermes lent Perseus winged sandals to fly, and Athena gave him a polished shield. Perseus then proceeded to the Gorgons' cave.

I have no idea about my kibisis, my Harpe, my helm of darkness, my winged sandals and my polished shield, but if the son of a god needs all of that, I may need that and a bit more.
I need to ask for help and really see what tools I have, and which others can be given to me.

Lesson three: know why you want her head

I certainly believe that Perseus got the help of the gods because he was on a noble mission. He wasn't all about glory for himself and the six figure income, but he wanted to defeat the evil in his own home. He eventually did, once he returned with Medusa's head as a super-weapon.

Knowing our purpose and our motivation is crucial to defeating Medusa. Of course we are going to turn to stone by the myriad of shiney new heads that coding and tech have to offer. Didn't you know how cool Phoenix 1.7's new features are? And how amazing the performance of Elixir NX is turning to be for AI? And the amazing music that can be coded in Sonic Pi? Man, wait until you see the new 30 videos in the Elixir YouTube Playlist and THEN you'll be on top of things.

I am still working on this one. I bet many of us are. We need an aim, and a noble one, a pressing one, a non-negotiable one, to focus our mission into a specific point. I believe that, in finding that spot we are aiming at with all of our being, winged sandals and helms of darkness will be granted to us. It is a theory, but Perseus dixit.

Not only Perseus dixit: we are surrounded by countless examples of how we seem to grow superpowers once we are committed and focused, fueled by a purpose that goes beyond ourselves.

So this is my takeaway: if and when we feel distracted, or frozen to stone, dig deeper into purpose. Why am I watching this YouTube tutorial, really? Which purpose is it serving, really? Where am I advancing towards with the actions I am taking today? What am I aiming at and why?

I believe there is a correlation between the quality of those answers and our tangible results in the real world.

Lesson four: be sneaky

My good man Perseus didn't show up at Medusa during office hours. No, he caught her sleeping, and he didn't look at her face, but used her reflection on his shield to locate her and take her head.

That is: no direct confrontation. Interesting. Many martial arts use the same principle. A lot of what heroes do seem to be counter-intuitive.

I asked Perseus to provide me with a cheat sheet and "five easy steps to use reflections in shields to defeat enemies". I want method. I want systems. I want the guaranteed win.

Perseus looked at me in the eye, took a puff off his cigar, and broke it to me in no uncertain terms: "you have to become a sneaky motherf***r. There ain't no methods for it. Once you have a method, you are predictible to your enemy. You need to be a surprise to your enemy."

As coders and engineers, we may like systems, methods, protocols, predictible outcomes. But when it comes to the inner games of distraction, focus, purpose, perseverance, and progress, we can automate a few things but others play a different game: they are always there to catch us on our weak spots, in the unexpected times, in the unexpected ways. Medusa could wake up at any time.

As one of my spiritual teachers says: "Eternal vigilance is the price of freedom".

I like Perseus's preparation: he never looks at her directly, but knows where she is through her reflection. He is shielded. He approaches her while she sleeps. He has a "dark mode" helm and winged sandals so he can become invisible and get the hell out of there should things turn bad.

He approaches prepared for the worst case scenario and then he sneaks, sneaks, sneaks... He is vigilant, never looks at her, waits for the right moment.

Food for thought

I am just a guy dealing with a whole deal of new knowledge being thrown at me. The tech industry is not going to stop throwing new knowledge at us, but it is potentially turning us to stone every day.

Each time we show up at the screen to work on our thing, there are a thousand Medusa's heads waiting, and they will have our day turn to stone. This blogpost is possibly part of your medusa, and is certainly part of mine. I should be studying APIs, I'll have you know.

We need to be vigilant. Sneaky. We are not winning Medusa's game, but we can win our game. For that, we need to know our purpose, be humble, be prepared, never think that "we got this". No, we don't. We are very likely to lose. The best we can do is to know our enemy, be humble, sneaky, prepare, and do noble battle.

Never, never look at her directly. How does this translates specifically to my day is part of the adventure. I shall use my winged sandals to run the other way if I sense her waking up.

Ignoring most things

In conversation with my mentor, we reflected on how one of the skills we can develop is knowing what to ignore. When I studied software development 23 years ago it was all about knowing more and more.

It seems that one of the keys to success today is knowing what to leave aside, mastering the part of our minds that are curious and want to spend a few hours, weeks, or months on things that we know, deep in our guts, to be distractions: our progress, frozen to stone.

We need to find which Ariadne's thread to follow. Because if Perseus can teach us how to defeat the Medusa of distractions, Ariadne can teach us about navigating the tech maze.

Maybe I will write about Ariadne some other day...

For now, a prayer, or a desire: Let us not get lost, let's have our threads to guide us through the maze, our purpose which provides focus and entice divine help, tools which allow us to approach victory well prepared. Let us defeat our enemies (mine is distraction and dispersion, what's yours?).

And then, let us bring our enemies heads back home so we can do more good.

The fun bit about the whole Perseus and Medusa drama, is that after the win, Perseus retains the superpower to turn others to stone, and he uses it for noble purposes, out of goodness, not spite.

That'd be good.

And now, API encoding and decoding.

git add .
git commit -m "Looking for a junior dev who likes myths? I'm your guy"

P.s.: Happy Thanksgiving

A Job in Elixir #002

BigSpaces — Sun, 16 Oct 2022 12:04:18 +0000

Last Friday a couple of students of Dockyard Academy were invited to participate in their roundtable, in which some Dockyard-ers get together and chat about what's cooking in their projects.

https://roundtables.dockyard.com/

There was some element of awe at the contemplation of high-level developers at the top of their game. It was something similar to stepping into a conservatory or an art class as a aspirant. It is easy to develop metaphorical neck injuries after looking up to these guys.

I asked the room: "what do you see when you see us newbies? what advice would you have or give your past selves?". Paul jumped in and did an IO.puts(@lessons_learnt_from_experience) |> Deliver.NoSugarCoating()

Here are the bullet-points:

You cannot avoid burnout - Recognize the early signs of burnout, take corrective action, slay the dragon, and we'll see each other on the other side. This is bound to happen once per year or couple of years.
Make "free time" useful for yourself: a bit of a "duh" but not so much when we look at our lives and realize that many of us use free time to add screen time, study time, personal projects time... Paul pointed towards a healthy combination of progressing your own interests, which is how you craft your niche and reputation, as well as unrelated activities that are there to nurture other areas of your life. In my case: writing, music, cooking, meditating, spending time in nature... Yours?
In everything you do, try and find the lessons and stepping stones that will take you further. For example, you may not particularly enjoy being a maintenance developer, but you can approach the job as becoming really good at refactoring, or git, or project management. Collect bricks to build your castle, so to speak. Everything can be used to further your development and skillset.
Brian (none other than the founder of Dockyard) chimed in and told us that today is simpler than tomorrow. This year, the world of tech is simpler than it will be five or ten years from now. Complexity is growing and will keep on growing, so there is no way to "get ready" for the industry in the way it was ten or twenty years ago. The way to navigate this is to carve a niche where you are the business. Do not get distracted by the newness and the spectacular new things that are released every 15 minutes, but follow the whispers of your true interests and curiosity and conquer that niche. Build a skillset and portfolio that gives you a reputation and offer true value to the industry.

There was more said, but these are my main takeaways. Check the Elixir Dockyard Roundtable podcast to listen to that intervention and extrack the wisdom of those who are established in the industry. Generous souls, for sure, and experienced in coding as well as in life.

My main lesson learnt is to keep pursuing my genuine insterests, and to allow plenty of space and time to nurture other areas of my life that provide a buffer for the high-intensity, anxiety-prone environment of this craft.

...so stay tuned for my Elixir-based custom meditation app :D

git add .
git commit -m "This is for warriors"

Big Spaces

How to be a 10 out of 10 student (lessons from childhood)

BigSpaces — Wed, 12 Oct 2022 09:38:59 +0000

When I was 13 years of age I had a habit of being a B student. It was not because I did not have the brains for an A. I just did not have enough carrot or enough stick to move my goalpost beyond something merely acceptable. In other words: school bored me and I did not see the point. Why make an effort? (God, what would I do to time travel and re-parent myself...)

One day, my math teacher (Don Paco) managed to get the carrot and stick equation right for me. He scored my test below the actual results and told me that he was taking points off my final score as a penalty for "unreached potential". My face must have turned red, and my ego was on the floor. My childish strategy of "doing the bare minimum" while keeping the adults off my case had failed. Don Paco had dismantled my carefully tested algorithm for life.

This bare confession of proud mediocracy has its point. Don Paco also provided a formula for excellence: "BigSpaces, when you come to class and I explain the exercises, do them on paper while I explain them. When you go home and it is time to do homework, do them again from scratch. When you come back into class to review time, do not just look at my corrections on the board. Do them once again from scratch on paper. I promise you: you will notice the difference in the next test".

I did. The time employed was the same, because I still had to sit in class, I still had to do homework, so I did not use any extra time, but I used the time more wisely. By the time I did the exam, I had gone through each type of exercise multiple times, and I was not surprised to have an A, and a big smile from Don Paco, who had found a way to get my carrot-stick equation just right, and showed me that excellence was its own reward.

I hope this inspires you on your student journey.

So now... protocols. Again. And guards. Again.

git add .
git commit -m "This one is for you, Don Paco. Aiming for A"

BigSpaces

Humble pie or grateful pie?

BigSpaces — Mon, 10 Oct 2022 08:47:26 +0000

Three weeks ago I did not know any Elixir at all.

Today, some of my classmates, as well as yours truly, sometimes experience feelings of frustration, impatience, self-doubt, or any combination of the above.

It is theoretically easy to see the sheer amount of progress and new learnings that we have incorporated in around three weeks.

Still, there is a part of us that considers that to not be enough.

Maybe not enough speed of assimilation. Not enough amount of knowledge. Not enough amount of fluency on the use of our new tools.

It has been said that we are eating plenty of humble pie in the last three weeks, and with that I have to agree.

The other side of the coin is also true: when was the last time we learnt this much in such a short period of time? When reflecting upon this, it may be a tool to put things in perspective, and to tame the parts of us that want instant results at the pace that we determine.

We will get there, gang.

Finding work in Elixir #001

BigSpaces — Tue, 04 Oct 2022 09:33:11 +0000

Hello Elixir community (and other developers too, of course):

I will have an announcement to make in the next few weeks, but in short, I will be sharing valuable information and guidance I find from my Gandalfs and Obi Wan Kenobis on my way to finding work.

Not only work. I want to find work that puts a big smile on my face. That is different for everyone, but I am reporting from my own journey, with the hope that it valuable to others.

Not big speeches yet, just note taking. Here are some principles that I have found valuable from my search.

Shout out to Jeff, Andrew and Brook, from whom I have learnt what you are about to read.

It is not what you know. It is who you know. Be active in the community that you want to belong to. Contribute. Learn. Meet people. Ask questions. Be noticed for the right reasons. The job that fits you may or may not be on LinkedIn, but more often than not comes through a personal connection. Find your gang and play!
Your previous career experience, even if it is unrelated, is valuable. Jeff, an experienced recruiter I talked with told me that developers with a varied past professional experience bring a lot of value to the job.
Pragmatic tip related to the above: When it comes to presenting this to potential employers, possibly the cover letter is the best way to bring this up. In my case, I would write about skills and attitudes I have learnt in my forays into the hospitality industry, entrepreneurship, advertisment, freelancing, writing, traveling, content creation... even music. What is relevant? How has that shaped the person I am now? How is that useful in the job I want to have? Spell it out in a cover letter (is that still fashionable?)
Being competent in Git is essential. Apparently there are developers out there with more than 20 years of experience who keep making a mess on Git, making life messy for everyone involved, despite their great skills in coding. I do not blame them. Git is a beast I have not yet tamed, but being orderly, disciplined, and fluent in Git & GitHub is very valuable and attractive to employers.
Speaking of Git: be active in projects you love. Have well populated Readme.md files. I didn't know this, but employers actually check your GitHub to peek into your life as a developer. Git your house in order and make it beautiful (apologies for the lame joke. It was low hanging fruit, and it looked tasty).

Bonus material on Readme.MD profiles (shout out to Stephan for providing these):

Even MORE bonus material on finding work:

GREAT Citizen Coder podcast episode with Andrew and Brooklin: https://www.youtube.com/watch?v=WghWvI5qfFU

Thanks to the Dockyard Academy community for sharing some of these below. I will be listening to them and... God only knows where the breadcrumbs will lead to:

Ben Orenstein - How to Stand Out When Applying for a Job at a Small Company - https://fullstackradio.com/152

Top End Devs... Adi seems like an interesting guy: https://topenddevs.com/podcasts/elixir-mix/episodes/getting-hired-as-an-elixir-programmer-with-adi-iyengar-emx-184

A podcast for freelance developers: https://www.dreamclients.io/

I will keep bringing these type of articles and resources to the community, and my job will be to summarise and extract the bullet points. If you have more wisdom about job-finding & career-building, please do let me know.

Also, if you know any Elixir recruiters, or projects that are looking for Elixir developers, I want to talk to them to understand their needs and challenges, as well as "what's cooking!". Mapping the territory I am.

Keep riding towards the sunset in the Elixir Wild Wild West!

Git add .
Git commit -m "Leave the cave. Kill something. Drag it home."

Big Spaces

Master Enum (metaphors galore)

BigSpaces — Fri, 30 Sep 2022 06:26:59 +0000

This is a tool that is aiding my brain in the Elixir journey: metaphors.

I find much of the documentation out there is rich in details for the initiated, though it may be a challenge for those of us who read through them as one would read through Sanskrit.

As I learn new functions every day, my brain needs mental shelves where to place these new concepts, and metaphors are providing those mental shelves.

Mastering enum seems to be akin to mastering the light saber for a Jedi. My superhero mentor insists that, if I get Enum.map, Enum.reduce, and Enum.filter, I have a good foundation to move forward.

These are the metaphors that are helping me as a starting point to understanding those three functions.

Enum.map is akin to going through all the beads of a rosary.

Enum.filter is akin to looking for a specific book in the library.

Enum.reduce is akin to placing your shopping into the bag.

They do not represent a perfect description. We have the technical documentation for perfection. Alas, when I am learning, they do the work. When I need to decide which function to use, those visuals help me decide which function has the best shot.

Git add .
Git commit -m "Whatever gets the job done..."

BigSpaces

What got you here? Where are you going?

BigSpaces — Tue, 27 Sep 2022 10:13:38 +0000

As I mentioned on a previous post, I had not written a line of code in 23 years, and now I am in the eye of an Elixir hurricane.

Emotions abound. I feel a giddy excitement everytime my brain starts to grasp something fully, that light at the end of the mental tunnel of knowing one is about to get it. Progress can be addictive. It seems we are hard-wired to figure things out, master things. We get rewarded from inside.

Other feelings are not as friendly, and I have made it a zen-lixir practice to notice them but not be informed by them. Those would be frustration, self-doubt, boredom, and laziness.

I am parenting my inner rebel to just sit, study, and go through the entire marathon, both intellectual as well as emotional, and come to my conclusions once I have a good grasp of the languange and the industry.

Other good emotions are the promises of the future. As someone with a bit of a creative, entrepreneurial, and adventurous mind, the thought of becoming nailed to a chair and spend a good portion of the gift of life interacting with a screen makes my stomach cringe. Simultaneously, there are many things in life that are not easily accessible unless they are supported by a firm foundation in the form of a job and/or career.

Some of those things are also adventures, creations, opportunities, expansions which tickle the soul and dreams. Many things in life are possible when you become really good at something, contribute abundantly, and get fairly compensated for it.

For me, some of those are taking my musical production to the next level, building a decent studio on the way. Moving to a less urban environment and be closer to nature, hopefully the ocean. Take care of my parents as they grow old. Travel to see my friends (who have a habit of settling far, far away)... There are things I would love to study, projects I would love to build. I leave the door open to finding a woman crazy and brave enough to create a dinasty with me, old-fashion style. I will need a small bus as well as a reasonable-size abode for that little army.

Those dreams fuel my motivation to becoming an asset to this industry, and serve as pacifiers whenever the inner rebel struggles with understanding maps, structs, and other (still) difficult concepts.

How about you? What do you dream about as you code? How did you end up here? What juices you about all the hours you spend on the screen? What is that you like the most about this industry and makes you feel alive? What is that frustrates you or wish was not part of the deal?

git add .
git committ -m "there is a dream behind every line of code"

BigSpaces

Truthy, Falsy, Confusy

BigSpaces — Mon, 26 Sep 2022 04:36:17 +0000

It is 5:24am - I have been up since 2am (this is not me at all) - I've already had TWO coffees.

Given those attenuating circumstances I take no responsibility for what is coming. Read at your own risk :)

My goal is to understand the logic of the comparison operator "&&"

First, my brothers and sisters, we need a firm grasp of the concepts "truthy" and "falsy".

That one is easy. It is just a brain tatoo. The values "nil" and "false" are falsy. Everything else is truthy.

It feels like a dogma to me and it is better if I do not fall into the rabbit hole of trying to get it. Just have faith: Everything in the Elixir universe is truthy but "false" and "nil". We do not ask questions... yet.

Now that we are believers, my next step is trying to get into the mind of whoever invented the "&&" as a comparison operator.

Such mind came up with "if left is truthy then right and if left is falsy then left"

In other words, "&&" does not give an atom about the right, just the left... unless it has to return the right, based on what is on the left, right?

You may ask "why such logic?", and I repeat: we do not ask questions. Drink the Elixir. At least that is why I am doing.

So to drill it down:

"Ex-girlfriend" && "My dog" should return "My dog"
False && "My dog" should return false
Nil && "My ex-girlfriend" should return nil

And that is correct.

Just for reference's sake... behold my dog, who now lives with my ex-girlfriend. He is bound to her, and she shall not return him, and that shall not change. That is called immutability.

But I digress.

Now I need to tatoo the logic behind "||", which is easier: "Return the first truthy value."

Of course I had to try what happens should both values be falsy. Here it goes:

false || false returns false (no shock there)
nil || nil returns nil (so far so good)
nil || false returns false (interesting)
false || nil returns nil (why? who knows!)

From this I draw two conclusions:

My life is very, very sad.
It seems that ||, unlike &&, does have a bit of a preference for what is on the right. Why? Mysteries keep piling up. José, where are you?

I need to get to the end of this... please indulge me. So:

"My dog" || nil returns "My Dog"
false || "My dog" returns My Dog
"My ex-girlfriend" || "My dog" returns My ex-girlfriend (we don't want that returned).
"My dog" || "My ex-girlfriend" returns "My dog" (she ain't returning him. Immutability).

If I want to keep retrieving my dog, I have two options now:

"My dog" || "My ex-girlfriend" (because || is first truthy value)
"My ex-girlfriend" && "My dog" (because && is if left is truthy then right)

5:57am

And now for the final shebang. What do we make of this expression? What should it return?

"this" == "this" && "The Same" || "Not The Same"

I see that Elixir breaks it down, though a million times faster than me (it is only taking me a week to get this one). I assume Elixir reads from left to right, though I am not sure what is going on under the hood. But, what I know is...

"this" == "this" is true

true && "The Same" (if left is truthy then right, so right: The Same)

"The Same" || "Not The Same" (first truthy value)

Returns "The Same". Turns out that "this" and "this" are "The Same".

We need to finish this. We do. Let's try changing one value.

"This" == "That" && "The Same" || "Not The Same"

False && "The Same" (if left is falsy then left, so false)

False || "Not The Same" (first truthy value, so "Not The Same")

Turns out that "This" is "Not The Same" as "That".

I wish I could tell you that I have it. I do not. But I am one step closer... Not too sure closer to what, actually. Elixir mastery? Needing therapy? Both?

I take solace in knowing that, despite my brain having a few thousand braincells less, my dog is actually very happy living with my ex-girlfriend, I am very happy living without my ex-girlfriend, and we are both very happy about all of that. In good terms.

(I had to clarify that, for the record.)

If you are at all attracted to seeing yourself in the same type of mental stretch that enticed me to write this blog post, and reach the same pinnacle of Elixir wisdom that I am displaying lately, I could put you in touch with my superhero mentor. You can tell my brain is doing push-ups, and sweating buckets.

You see... he thought I was capable of solving the following exercise:

I wasn't. Hence the mental stretch, the post, and two coffees :)

Gladly, a companion on the path with more knowledge (and possibly a more rested brain than mine), came up to the rescue, replacing dogs, ex-girlfriends and wordy confusing things with numbers.

So, for the number-oriented, here is another way to look at the same conundrum.

iex(1)> 1 == 2 && 3 || 4
4

All we are doing is recreating an if expression!

iex(2)> if 1 == 2 do
...(2)>   3
...(2)> else
...(2)>   4
...(2)> end
4

Thank you, @czrpb, for that.

git add .
git committ -m "I will get this. No matter how long it takes me"

BigSpaces