Vir sapit qui pauca loquitur
Brevity reigns supreme
: concise and exact use of words in writing or speech.
I often come across articles that are convoluted, making otherwise stimulating discourse inaccessible. Why cant these articles be easy to read? One’s thought, regardless of how complex it is, can be effectively conveyed using well-researched diction, instead of taking the tortuous path of multiple sentences and esoteric literary techniques. We value succinct communication, and we need to see more of it.
You must be pondering about my fascination with brevity, and how it relates to coding.
My fixation on brevity stems from my previous life, in which I was trying too hard to be someone I am not, a ‘Policy Wonk’. Policy Wonks are Millennials with backgrounds in International Affairs. During my undergraduate and graduate years I was relentless in my pursuit to become a Policy Wonk, but everything I read Policy-related I found gratuitous. And it aggravated me these pieces were so complicated, they really didn’t need to be. Nevertheless, I accepted what I thought was the industry norm and pushed on. The tipping point came when I found myself writing and speaking in ways that made little sense even to myself. I was petrified by how hard I was trying to sound like everything I was reading. Thankfully, at that point I was introduced to coding, and everything changed. I accepted that I was not a Policy Wonk, and reveled in the fact that I didn’t have to subject myself to taxing arcane pieces relied upon by the Policy world. I found my calling in code, technology, and business, and in these industries brevity reigns supreme.
In code I meet people articulating thoughts plainly and clearly. No one is trying to prove anything to anyone, there’s no ego, just an abundance of selflessness and benevolence. They want to help you to the best of their abilities, and they do that by articulating thoughts plainly and clearly. I think brevity is paramount in code, and that is what led me to fall in love with it.
I vow to myself and those following my work that I will speak plainly and clearly. Effective and democratic communication is gravely underrated and taken for granted. This reminder came to me rather poignantly during a series of exchanges I had with Gallaudet (a deaf university) students. What is the point of expressing things most folks cannot understand? We owe it to our friends with impaired hearing to speak plainly and clearly, they would want that. So let us expend words sparingly, and express ourselves in ways that can be heard by all.
In keeping with what I preach, there will be a succinct weekly blog on my coding progress. I intend to share breakthroughs and other things which could be beneficial to coders like me just starting out. Accountability is a defining part of me, so if you find that I’m deviating from the ‘philosophy of brevity’ please let me know.
If people don't either love or hate your work, you just haven't done all that much. - Tinker Hatfield
I just watched an episode of the new Netflix design documentary ‘Abstract’. This episode was based on the life of Tinker Hatfield, the most influential sneaker designer of all time. He's been at the helm of Nike's sneaker design for decades, and is to be thanked for classics like the ‘Air Max’ and the entire ‘Jordan’ range.
Right before the ending credits he says, "If people don't either love or hate your work, you just haven't done all that much". That really resonated with me, because just a couple of days ago I finished making this blog and personal website, and when I shared it with a close friend he said he hated the color scheme. He understood that I was going for the color scheme of the Bangladesh flag (green and red) but he thought the use of green, red, and shades of light red made the pages look unprofessional. I wasn't upset with what he said, I was proud of my work. But I was subconsciously searching for a little validation, and I found it in what Tinker said. :)
We shouldn't feel let down when someone criticizes our work, because the fact of the matter is; our work has stirred them enough to provoke an emotional response, albeit negative. The provocation speaks to our achievement. Their opposition is a testament to our hard work, and their apathy would be disconcerting.
Now, let’s talk code. I covered Ruby topics in Arrays and Hashes this week, really nailing the concepts of Destructive methods. I used to think that adding the bang operator (!) to any method makes it Destructive, glad to report that I no longer think that. I’ve learnt that the bang operator alone is not the sole determinant of whether or not a method is Destructive. There are methods like Array#pop that Mutate the Caller (Destructive) and does not have a bang operator. It’s crucial to know that we cannot just append the bang operator to any method to make it Destructive.
I also worked on manipulating Files in PRY. I didn’t know that the File class was a Standard Subclass of IO, and that led me to realize that we can use a lot of IO methods with File. Previously, I did most of my File management in the CLI (Command Line Interface), but now I can do some of those functions in PRY. Actually PRY allows for more expressivity. For example, in PRY, I can create files and set accessibility (r, w, w+, a+), I can add content into these files that I just created, and I can even copy content from other files and paste them into these new files.
Before ending I’d like to talk about CSS. A friend of mine opened my world to ‘divs’ a few weeks ago, and once I got the hang of it I thought it was god’s gift to the world. I initially used divs exhaustively when designing this blog and personal website (I might still have a couple hanging around but…shhhh). Divs are fantastic because you don’t have to create new classes every time you want to add a style to an element, you just “div” it, as my friend would say. In my mind divs were great, until I spoke to folks who are in boot camps doing Front-End. They taught me that divs should only be used as a last resort, one person even told me that their Front-End instructor barred them from using divs. You could imagine how I felt at that point, but after the ramifications of frequent div use was explained to me I understood why it’s best to use them sparingly.
It’s better to create new classes - instead of div’ing - for purposes of CSS targeting and tracking. Now that I understand why we ought to avoid divs, I’ll be more diligent, and will create new classes when looking to make small tweaks and changes in my code.
I was having issues with my navigation bar, links would be unresponsive when the bar was over certain parts of the page which were text heavy. Links worked fine over white space, but they weren’t working over text. I had no idea what to do, until someone on the CodeNewbie Slack Channel provided me with the remedy. My issue was related to the ‘Z-Index’, and it was explained to me as the ‘position on the z-axis of an element, I.E. the depth.’ They went on to offer further insight, saying that ‘navigation links might be under another container that happens to have a higher Z-Index due to the hierarchy in the HTML markup, or their positioning, I.E. absolute’. Based off of the guidance, I investigated, later to find that I needed a Z-Index of 1 in my ‘ul’ class, which acts as my navigation bar. After adding the Z-Index property to the class my navigation bar became responsive over all parts of the page. Visualbear, if you’re reading this thank you so much for the help. :)
With respect to Ruby, I came close to fully understanding the difference between Instance and Class Methods. This is what I know so far:
Class methods, denoted with ‘::’ in documentation, is called directly FROM the class. An example of a class method is String::new, and if we were to call it from the class ‘String’ on PRY, say we did String.new(‘examplestring’), the return value would be the new string ‘examplestring’. With class methods we aren’t calling the method from objects, we are calling methods from the class itself. Instance methods, denoted with ‘#’ in documentation, is called ON the object. Here it’s worthwhile to explain what I consider ‘objects’. (I’ve yet to start Object-Oriented-Programming) Given what I know so far, it seems to me that objects are things like strings, arrays, and hashes. My friend recently told me classes are objects too, and it blew my mind. Still, I prevented myself from probing further to avoid a rabbit hole entry. Ok, so back to instance methods. Instance methods are called on the object, an example being String#split. If we called the ‘split’ method on the string ‘hello’ we would see, ‘hello’.split(‘’) => [‘h’, ‘e’, ‘l’, ‘l’, ‘o’,].
Interestingly, while ‘::’ denotes class methods, ‘::’ also defines a ‘namespace’. We will run into namespaces in class/module names. So what is a namespace? Namespaces are used to group classes in Ruby, they differentiate a class from other classes with the same name. ‘ActiveRecord::Base’ refers to the ‘Base’ class in the ‘ActiveRecord’ module, the ‘::’ is used to differentiate this from other classes in Ruby also called ‘Base’.
‘Exception Handling’ is another foray I explored this past week, it’s just a technical way of describing ways to deal with exceptional conditions (errors) in Ruby. And I’m really glad I came across this, because now I have the ability to write programs that won’t crash! LaunchSchool describes it as, 'a way of handling the error by changing the flow of control without exiting the program entirely'. Key to formulating a program with exception handling capabilities are the reserved words ‘begin’, ‘rescue’, and ‘end’. FYI, when we encounter an error in Ruby we say “an exception is raised”.
A very common occurrence of an error is when we get a ‘nil’ value, but instead of having our program crash as result of the ‘nil’, we can circumvent the problem by using the reserved words. Check out the example below:
The block iterates through the array until it faces the ‘nil’, and at that point our ‘rescue’ reserved word, well…comes to the rescue, executing the code below it. After the code below ‘rescue’ is executed, the iteration continues and works its way through the rest of the array. How great is that?
Oh and another thing, if you are hosting your site on GitHub, like me, use JPG instead of PNG. The image above wasn't working for me as PNG. PNGs will work locally, but not off the repository, so use JPG. Happy Hacking!
In this week’s blog post we cover ‘Variables as Pointers’. This is a very interesting concept that may not come naturally to many, especially if you’re thinking algebraically.
Over the course of the past couple of months I’ve learnt that it’s futile to reason with Ruby concepts using mathematics we picked up in High School and/or University. I learnt this the hard way while trying to understand ‘Variables as Pointers’.
Disclosure: The diagrams you see below are from LaunchSchool, and I highly advise you to check out their free Ruby book if you’re looking to learn, or just need a refresher.
So from the outset we have to acknowledge that variables act as pointers to a place in memory. Well ok…but what does that mean? Let’s look at an example to understand this.
In PRY if we assign variable ‘a’ the string ‘hi there’, then assign variable ‘b’ the value of variable ‘a’, we can be sure that both variables ‘a’ and ‘b’ will be assigned to the value ‘hi there’. Ok, now let’s REASSIGN variable ‘a’ the value ‘not here’, what happens now? Variable ‘a’ is now assigned the value ‘not here’, so variable ‘b’ should also be assigned value ‘not here’ right? NO! Variable ‘b’ REMAINS assigned to value ‘hi there’ because it was NOT REASSIGNED, variable ‘b’ is still pointing at the address space in memory ‘hi there’. Look at the screenshot below of what was done in PRY for confirmation of this.
So what exactly happened here? Before explaining let’s reiterate that variables are pointers to physical space in memory. In other words, variables are labels created to refer to some physical memory address. Ok, now let’s explain what happened above, and we can do that using the diagram below.
Line 3 of code, a = ‘not here’, REASSIGNED the variable ‘a’ to a different physical memory address, variable ‘a’ is now pointing to a whole new string. Variable ‘b’ remains pointing at ‘hi there’, as was established in the second line of code, b = a.
It’s imperative here to also understand that different memory spaces can hold the same value, they’re just in different places in memory. IE If the last line of code was a = ‘hi there’, instead of a = ‘not here’, then variables ‘a’ and ‘b’ would be pointing to the same value, but in DIFFERENT ADDRESSES in memory.
We’re not done yet! To really understand this concept we have to explore another example. Let’s look at what was done below.
So we’re back in PRY, and just like the previous example we assign variable ‘a’ the string ‘hi there’, then assign variable ‘b’ the value of variable ‘a’, so we can be sure that both variables ‘a’ and ‘b’ will point to the value ‘hi there’. But in this example, we are using the shovel operator to append ‘, Bob’ to the value of variable ‘a’ which is ‘hi there’. So what we’re doing here is mutating the caller on the value of variable ‘a’. Ok, so variable ‘a’ will now point to the value ‘hi there, Bob’, but what about variable ‘b’? Will variable ‘b’ also point to the value ‘hi there, Bob’? Yes, variable ‘b’ will also point to the value ‘hi there, Bob’. How did this happen? Let’s look at the diagram below to understand.
Line 3 of code, a << ‘, Bob’, did NOT REASSIGN variable ‘a’ to another string, it simply mutated the caller, modifying the string that variable ‘a’ is pointing/assigned to, which is also the string variable ‘b’ is pointing to. Now we understand why variable ‘b’ reflects the changes made to variable ‘a’, it’s because both variables are pointing to the same physical address in memory, and that physical address in memory was modified. There were NO REASSIGNMENTS in this example.
The main take-away from this second example is that some operations will mutate the caller on the actual physical memory address, and that will affect ALL variables pointing to that address. For operations that DO NOT mutate the caller (like in the first example) variables are REASSIGNED, or re-pointed, to a new physical memory address.
Before ending, we must keep in mind that this applies not just to strings, but to other objects that have destructive methods like arrays and hashes.
I’m pleased to announce that I have completed LaunchSchool’s Introduction to Programming with Ruby book. I just started Codecademy’s Ruby course, and upon its completion will begin LaunchSchool’s advanced coursework. This has been a huge milestone for me, and while I’m proud of myself for coming this far, I know I must pick up the pace and work harder to be prepared for The Iron Yard in May. I only have about two months before I begin, what could be, the most challenging 12 weeks of my life!
So what did I achieve this week? A solid revision of key concepts and exposure to some new things. Codecademy’s Ruby track is great for someone needing a refresher of the basics, but I don’t think it’s suitable for absolute beginners. While I’m revisiting concepts familiar to me, I’m also learning new things, and I’ll be sharing two of those in this week’s post.
The first thing I’d like to share is ‘Redaction’. In terms of Ruby fundamentals, there is nothing new here, but what was new to me was the whole concept of Redaction. My understanding is that Redaction is something that can be implemented to hide parts of a string from being printed. It can be used, for example, to hide profanity. I can see this being handy in a children’s forum, where you want to encourage open dialogue but want to shield young ones from online predators, or those with a natural tendency to use inappropriate language. So let’s see this in action below.
This code should appear to be quite self-explanatory, however, it’s worth mentioning that my code is different from that on Codecademy because I was bothered with the fact that their code would NOT end with a new line. Therefore, I added conditionals with the ‘puts’ method in lieu of ‘print’, to ensure that whatever the outcome of the iteration, there was ALWAYS a new line.
So, what happens above is that every time the code finds the word the user wants to redact, it gets…well redacted. Subsequently, what is printed to the screen is the user’s text but redacted, we see the word replaced with ‘REDACTED’.
The second and final thing I’d like to share this week is ‘Histogram’. A Histogram is essentially a way for us to count how many unique parts of a string there are, e.g. string ‘hello bye bye’ has one ‘hello’ and two ‘bye’s, and a Histogram can tell us that PROGRAMATICALLY. Below is an example of what I was working on. While I understood the basics of it all, some things were new to me.
The code above first gets a string from the user, then begins a series of executions to finally output the frequencies of each word in the string. Initially, it was quite challenging for me to grasp why we needed a default value when creating the hash. After pondering for a while it dawned upon me that we needed a default value ( more importantly, for it to be 0) because to calculate the frequency of each word in the string we will need to INCREMENT by 1.
Another thing that took me by surprise (and perplexed me a little) was how you can insert a key-value pair into a hash using code that increments. Up till this point I only knew that key-value pairs could be inserted into a hash using: `hash_name[key] = value`, now I know that you can insert values using code that INCREMENTs based off the default value!
Lastly, I learnt that the method Enumerable#sort_by can be called on hashes, and what is returned is a nested array with keys/values in ASCENDING order. This method is NOT destructive, and that’s why we assigned the block to variable ‘frequencies’, it was to capture the returned value.
Oh what a week it’s been! I picked up a lot of new things on Codecademy, chiefly around refactoring. Codecademy is fantastic because their course adds on to concepts I gained familiarity with in LaunchSchool, and is also teaching me to write more succinct code. I’m also being exposed to alternate ways of writing certain code, e.g. a program heavy on if/else conditional statements can be rewritten using just one case statement. Case statements are much easier to follow along, and guides us in writing more efficient code.
All in all I am very happy with everything I picked up on Codecademy.
A new concept I found really interesting is the Conditional Assignment Operator. The Conditional Assignment Operator is comprised of the || (OR logical operator) and = (NORMAL assignment operator), resulting in ‘||=’. The Conditional Assignment Operator is used to assign a variable if it hasn't already been assigned a value. E.G. if a variable is assigned 'nil' ‘||=’ can be used to assign that variable some value. However, AFTER THAT, ‘||=’ cannot be used to assign that variable a new value, since that variable already has a value. If that variable is to be reassigned it must be done using the normal assignment operator (=). The Conditional Assignment Operator is useful when we don’t know whether or not a variable has been assigned a value.
The example below should help understand this.
Although I fell in love with Ruby I need to be realistic, and accept the fact that knowing JS will increase the likelihood of having an offer right after completing the boot camp in August. It’s imperative that I find gainful employment immediately after the boot camp, and the probability of that happening will be much higher with JS proficiency. (It’s worth mentioning that I am by no means abandoning Ruby, I’ll continue to work on Ruby whenever I can, but I will allocate the majority of my time to JS.)
Take a look at the chart below, it illustrates demand for developers by languages, while also informing us on the most widely used languages.
It’s absolutely clear that JS has the highest demand and use. Conversely, we find Ruby to be in the bottom regions. (This chart is from Stack Overflow Talent’s ‘2017 Developer Hiring Landscape – United States’ report. It’s incredibly revealing and I urge everyone to check it out.)
Another chart that also stood out to me is this one:
Once again, JS frameworks, libraries, and tools dominate both what is in demand and used the most.
As I conclude this post I feel trepidation, largely in part to the profoundness of this shift over to JS. For the past couple of months I’ve only known Ruby syntax, and the thought of transitioning to something with different syntax is beyond terrifying. But I have mustered up the courage, and I am taking the plunge today. Also, there’s no denying that I’ll need to learn new languages quickly and efficiently in the future, so this move was, in essence, inevitable. I guess it’s frightening because it’s the first time I’m doing something like this, but I know it’ll get easier over time.
I signed up for FreeCodeCamp, and may consider paying for Codecademy’s JS course. I look forward to sharing my JS insights with you over the course of the coming weeks and months!
Before ending I would like to offer a tribute to my good friend Andrew, the language Ruby, and the online boot camp LaunchSchool. Andrew is has been my mentor in this journey, and is the only reason I began coding with Ruby and LaunchSchool. Thank you Andrew, for helping me solve problems and explaining concepts someone like me with no computer science background found hopelessly esoteric.
I would also like to express my sincerest gratitude to the amazing folks at LaunchSchool who took me in as an aspiring developer, and taught me everything I needed to know to embark on the journey towards Full-Stack Web Development. LaunchSchool provides a fantastic free platform for those interested in starting web development the right way, which is the path of mastery.
Also, I would be remiss if I ended without extolling Ruby. Matz’s Ruby is SIMPLE and FORGIVING when compared to other languages, and that’s why I consider it to be the ideal language for beginners. I can’t emphasize its simple and forgiving nature enough, that’s what helped me in this process and kept me sane! Ruby is a phenomenal language to understand the foundational concepts in programming.