Mando is { Coding }

It’s been over a year since I last wrote anything on here. I’ve been super busy being a full-stack developer @wizarddev and working hard on my craft everyday so I can reach the next level.

There are times when I’m designing or developing that I feel that my work is not good enough.

If you personally know me, you know that no matter how good my work is or how much props you might give me, I’m never satisfied.

I’m never satisfied because I feel I’m not where I should be skill or experience wise. I like pushing myself and don’t like being in comfortable state. Once you are comfortable, I feel like there’s no more room for growth and this is one of the main reason I love programming and designing. There’s always a problem to be solve and a challenge to take on.

One of my main goals is to become a unicorn. A unicorn in the tech world is someone who is equally good at designing and developing. Being the best of both world will take time to achieve and master and that’s ok because it will keep me busy.

No matter what obstacles are in front of me, I will continue to work hard and continue to grow.

With that said, I will leave you with one of the most motivating videos that I have watched countless of times.

The Gap by Ira Glass

According to wikipedia: "A hoist is a device used for lifting or lowering a load by means of drum or lift-wheel around which rope or chain or chain wraps" From this definition we can say hoisting is to raise by mechanical means.

In JavaScript, hoisting has the same meaning but instead of lifting or raising a device, we are lifting a variable to the top of the scope. To understand this let's look at this example:

var foo = "Hello"; var bar = "World"; //outpus "Hello World" console.log(foo + " " + bar);

As you can see the code above prints "Hello World" to the console, but the way JavaScript interprets the code is the following:

var foo; var bar; foo = "Hello"; bar = "World"; console.log(foo + " " + bar);

The JavaScript interpreter moved all the variables declarations to the top of the current scope. Only the actual declarations are hoisted and any assignments are left where they are.

Let's look at a different example to see how hoisting works.

If we typed to the console:

console.log(name);

we will get a reference error stating that this name variable is not defined.

Now if we typed:

console.log(name); var name = "Armando"; console.log(name);

For some odd reason we will get an undefined output for the first console.log(name); and then "Armando" for the second console.log output. You may be asking why? and this is where hoisting comes in. The way JavaScript is interpreting the code is like this:

var name; //This is going to output: undefined since nothing is assigned to name console.log(name); var name = "Armando"; //This is going to output: "Armando" because it is now assigned. console.log(name)

JavaScript interpreter looks ahed to find all the variable declarations and hoists them to the top of the function.

Let's look at another example dealing with using variables inside and outside of scope:

var location = "outside the function"; (function () { // outputs: "Where am I? undefined" console.log("Where am I?" + location); var location = "Inside the function"; // outputs: "Where am I? innerscope" console.log("Where am I?" + location); })();

In this case you would expect scope to retain it's value from the outer scope until the point the scope was declared in the inner scope. But due to hoisting, scope is undefined instead because this is how JavaScript interpreted the code:

If you ever worked on a D3.js project you may have noticed that you are able to method chain many attr() methods to add attributes to your selection(s). After a while it gets tiring typing attr() over and over again. With multivalue maps you are able to refactor all those attr() methods that are chained together into a single attr() statement. 

Let's say you want to select a 'rect' svg element and add three attributes (x, y, and fill) you would write it like this:

svg.select("rect") .attr("x", 0) .attr("y", 0) .attr("fill", "red");

To refactor this code we can just use one attr() statement and create a property/value pairs object.

svg.select("rect") .attr({ x : 0, y : 0, fill: red });

No matter if functions or styling is used, you can include it on a single attr() statement.

Another example (using functions and styling)

.attr("text-anchor", "middle") .attr("x", function(d, i) { return i * (w / dataset.length) + (w / dataset.length - barPadding) / 2; }) .attr("y", function(d) { return h - (d * 4) + 14; }) .attr("font-family", "sans-serif") .attr("font-size", "11px") .attr("fill", "white");

refactored version

On friday our instructors at Flatiron School mentioned that we are going to begin lectures on JavaScript (JS). I was excited because JS is the language I was trying to learn during the time I first decided to learn coding and was applying to the Flatiron School.

For the weekend we were assigned to read some material on JS and write about some of the similarities and differences between JS and Ruby. 

Even thought I programmed my Interview project in JS, I can honestly say that I forgot the little bit of JS that I knew before becoming a fellow at the Flatiron School.

What’s great about learning how to code, is that once you learn the basic concepts you can always adapt to other languages. Programming languages concepts are going to be the same as long it belongs to the same paradigm. 

According to Wikipedia:

Javascript (JS) us an interpreted computer programming language. As part of web browser, implementations allow client-side scripts to interact with the user, control the browser.

In short, JS is a programming language that adds behavior to your web pages and runs on your browser(client-side). JS is also part of the three musketeer of front-end world; HTML, CSS and Javascript.

Just like Ruby, JS syntax was influence by C and it’s object-oriented. One of the difference between JS and Ruby is that JS is a Front-end/Client side language while Ruby is a Back-end/server-side language. 

Another difference is that Ruby has a block-level scoping of local variables, while JS has a function-level scoping. When it comes to objects,  a JS object is a collection of properties that reference other objects while Ruby object contains a hash of instance variables that reference other objects. Ruby enforces a level of data encapsulation, every object in Ruby has an associated class.

Below i have outlined how to create variables, arrays, hashes and classes. How to create methods, which are functions in JS.

Arrays 

# Ruby array = ["A", "B", "C"] array.push("D") array # ["A", "B", "C", "D"] array.reverse! # ["D", "C", "B", "A"]

// JavaScript var array = ["A", "B", "C"]; array.push("D"); console.log(array); // ["A", "B", "C", "D" ] array.reverse() // ["D", "C", "B", "A"]

Hashes

# Ruby Hash hash = {} hash['A'] = 1 hash['B'] = 2 hash['C'] = 3 hash.each { |key, value| puts "#{key} #{value}" } # A 1 # B 2 # C 3

// Javascript Hash var hash = {} hash['A'] = 1 hash['B'] = 2 hash['C'] = 3 for (key in h) { console.log(key, h[key]); // A 1 // B 2 // C 3

Functions (Methods)

#Ruby def greet(name) puts "Hello #{name}!" end greet("Armando") # Hello Armando!

//Javascript function greet(name) { return "Hello " + name + "!"; } greet("Armando"); // Hello Armando!

Classes

# Ruby class Person attr_accessor :firstName, :lastName def initialize(firstName, lastName) @firstName = firstName @lastName = lastName end def fullName @firstName + "" + @lastName end end armando = Person.new("Armando", "Amador") armando.fullName # "Armando Amador"

# Javascript function Person(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } Person.prototype.fullName = function() { return this.firstName + " " + this.lastName; } var armando = new Person("Armando", "Amador"); armando.fullName(); // "Armando Amador"

A few days ago we started to work on our first big team project at Flatiron School. The thought of working on big projects both excites and terrifies me. I always have to remind myself that this is the reason why I wanted to be a Developer, So that I'm able to work on new and exciting projects all the time.

We were assigned new groups of four at the beginning of the week and what's great about changing groups weekly is that you always get the chance to work with different people. On most projects so far we always ended up working with the person next to you, but this time around it's different due to the scope of the project. In the real world, applications are developed in teams and being able to get this experience early in our learning is beneficial to our future as developers.

I usually don't have a problem working with other people, but when you have to work with a group of four, things get more complicated. It's not a bad thing working with more people, but i feel you have to be more patient and agree/disagree with two extra people. When working with a bigger group there are some pros such as, having more ideas and discussion. Some cons in working with a bigger group is dealing with different work ethics and personalities.

Working with my group so far has been great. We have been taking a slow and steady approach towards developing our application. We have broken down the projects into smaller task and making sure we are all on the page at all time. We are taking turns in discussing ideas and making sure we are all contributing. We are taking each other accountable by assigning reading and homework so that we are prepared to contribute on the following day. 

Today we were given an assignment to debug a Rails app. The problem with the app is that when you go to the new action and hit submit button, it seems like it creates a game but it's saving blank names for the games name.

The first thing I did was forked the app from my instructor GitHub and opened up my terminal to cloned the repo. I did a bundle install ran the rails server. After running the server, I opened up the browser and checked http://localhost:3000/games. I received this error:

This error is basically stating that it cannot find the 'games' table. So I ran the single migration created. After refreshing the page, the error went away and I was able to create new actions and this is where I ran into the error the instructor wanted us to debug.

As you can see, no value is being shown for the new games. I had this similar error before on a tutorial i was following to create a simple blog app on Rails. The problem was that the game create method didn't have the correct parameters. In the game controller I went to the create method and changed the params[:games] to plural so it should read params[:game]. While i was already at the controller page, I noticed that there was no destroy method, so I went ahead and created it. I went back to my browser, refreshed the page, deleted the two blank values and created a new game to check if I debugged the bug correctly and it worked!

When I found out that we were going to learn Rails this week I was truly afraid. I was afraid because I felt my Ruby skills were not strong enough,  my HTML/HAML was not semantic enough and my CSS was not SASS enough. I was freaking out because I didn't get the chance to do any Rails tutorial when I was doing pre work for the Flatiron School back in October/November. I had to tell myself to relax, you have been dealing with new material every day, this is just another obstacle to overcome. 

Rails is a web application development framework written in the Ruby language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. Coming from working with Sinatra framework for the past couple of weeks, Rails seems like Sinatra on extreme steroids. 

According to Wikipedia, Sinatra framework is a web application library and domain specific language written in Ruby. It's considered as an alternative to other Ruby web application frameworks such as Rails. Sinatra is small and flexible, it does not follow the typical MVC (model-view-controller) pattern used in other framework such as Rails and it focuses on "Quickly creating web apps in Ruby with minimal effort.

If I could compare Sinatra to Rails i would say Sinatra are regular headphones that gets the job done by providing audio to your ears while Rails are big Studio quality headphones that provide more audio than you can bargained for. 

Today i learned something interesting when it comes to creating layouts in CSS. When creating a layout with a defined width, padding and border your computed width is not what you originally defined as width on your css.

Your computed width is actually width + padding + border you defined in your css file. This becomes a problem if you wanted to create a box that it's 200px wide and when you see your rendered layout it's actually wider since padding and border were added to your defined width.

When creating layouts, the default box model the browser uses is the box-sizing property with the content-box value. If you wanted your computed width to be exactly what you set, you would have to use the box-sizing property with border-box set as it's value. You can set your document to follow the 'box-sizing : border-box' model with this code at the beginning of your CSS document:

/* apply a natural box layout model to all elements */ *, *:before, *:after { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; }

When using border-box value the computed width equals to the content + padding + border. For example:

* { box-sizing: border-box; } .box { width: 200px; padding: 20px; border: 20px; }

The computer width for the code above will equal to 200px wide with padding and border applied. This means your content will be around 140px wide.

if we use the default box model example:

* { box-sizing: content-box; } .box { width: 200px; padding: 20px; border: 20px;

The computed width for the code will equal to 260px wide since your content is defined at 200px wide and both padding and border are added to your total computed width.

Today in class we were given a real world CSS interview exercise to work on. The exercise was recreating a button using CSS properties alone with the image provided. This exercise is meant to give employers a way to test a candidate's CSS3 skills and how they work through problems in a live setting. 

Here is the button:

At first i was excited about doing this exercise since i felt i have a great understanding of basic CSS and HTML, but when i found out i couldn't use any HTML elements such as my all time favorite <span> element, I started to believe that this exercise was not so simple anymore. 

Since we couldn't use any extra HTML element i had to change my approach and break things down to smaller objectives. Even thought i broke things down, I noticed i was taking way to long to recreate the button and ran out of time. 

Our instructor decided to create a new challenge by making us form into two teams and going against each other. The rules were: 

Only one person can be at the computer at a time.

The team may no speak while a team member is at the computer

The person may add, remove, or edit a single property and/or write a new selector.

No person can go twice in a row.

Every person on a team must go once before someone else goes.

Each person's turn is a point.

The team with the least points at the completion is the winner.

The first thing we did as a team was review each other code and see who recreated the CSS button the best, we then refactored that teammate's code and get a better overall understanding of the solution so that we can be able to recreate the code when the game began.

When the game began we lost many valuable turns because we went and wrote things we tried to memorize instead of writing things we truly understood. We change our approach by taking more time trying to see what was written and what needed to be fixed. After many turns passed we had a great replica of the button and even thought we lost due to many turns we were happy with the button we created.

I really enjoyed working with my team on this project because everyone gets really involved and you always learn from different approaches to the same problem. I also enjoyed the exercise because these are the types of question i will get on a interview, so my goal is to try to tackle as much of these problems so that when i do start to interview i won't be caught off guard when they ask me to solve a problem in front of them.

I recently read Cecily Carver’s medium.com post "Things I Wish Someone Had Told Me When I was Learning How To Code" and was surprised on how much her words were hitting home. Mostly everything she stated were things that i have and currently experiencing as someone who is learning the craft of coding. Her seven main points in her article that she wished someone had told her were:

1. Before you learn to code, think about what you want to code. 2. There’s nothing mystical about it. 3. It never works the first time and probably won’t the second or third time. 4. Someone will always tell you you’re doing it wrong. 5. Someone will always tell you you’re not a real coder. 6. Worrying about “geek creed” will slowly kill you. 7. Sticking with it is more important than the method.

A few months ago when i wanted to start to code I had this dilemma about not knowing which language to start with. When searching online on what language to start with, websites and developers will give you the it depends answer or have a bias or hate towards a language because they think is cool or uncool. No one tells you at first that it does not matter which one you start with as long as you start and learn the basics. Cecily states that someone will always tell you’re doing it wrong and I agree because if you go by what people tell you, you will be discouraged before even starting. One of the best advice I read when figuring out where I wanted to start was from Zed Shaw’s Learn the hard way web site. He states “Which programming language you learn and use doesn’t matter. Do not get sucked into the religion surround programming languages as that will only blind you to their true purpose of being your tool for doing interesting things.”

As a beginner you are paralyzed by fear of what developers might say about you or about your code and might even try to discourage you for not having a ‘Computer Science’ degree or for being apart of a Web Development Bootcamp school. The only way to combat that fear is to mute all those comments and stay positive through your journey. They are many famous programmers that never went to college and even dropped out of High-school and have contributed in countless ways to the tech community and humanity. 

One of the best advices that Cecily points out is that ‘sticking with it is more important than the method.’ There is no right or best way to learn how to code. You can learn from books, videos or from other people. Even though I’m a beginner, my advice to those who want to learn or are currently learning how to code, is that the fastest you realize that learning how to code is not an overnight thing and that it’s a craft you have to work hard to improve, the less rocky your journey will be. You need to have the patience while improving your craft and have to constantly have your goals in sight in order to keep learning and not be discouraged. There will be times you will ask yourself ‘am I cut out for this?’ or ‘am i good enough?’ but you have to fight hard to keep those negative thoughts out of your head. You have to keep in mind that everyday you learn something new, you will be better than the day before and eventually the previous  week and then you will be surprised on how far you have improved compare to where you started. 

"Your goal is to model your application, using classes, such that it does what it supposed to do right now and is also easy to change later." - Sandi Metz

Recently i read chapter 2 of "Practical Object Oriented Design in Ruby" by Sandi Metz and i can surely say that is has opened my mind in how to plan, write and structure future applications/programs that i write. I had many misconceptions of how to approach things as a beginner learning how to code in Ruby. One misconception i had was that when refactoring methods with long code was that i had to find short and clever ways to condense the code. That approach is totally wrong when the times come to adding new features or fixing some of your code. After reading chapter 2: "Designing Classes with a Single Responsibility" I got a better understanding on how a class should do the smallest possible useful thing; that is, it should have a single responsibility.

Sandi Metz goes on to show a small application dealing with Bicycles and Gears and explain why Single Responsibility Matters. She goes step by step building a sample application and showing how a method with more than one responsibility can hurt your application when adding new features in the future. She also states that applications that are easy to change consist of classes that are easy to reuse. An application that is easy to change is like a box of building blocks; you can select just the pieces you need and assemble them in unanticipated ways.

The problem we get is that when a class has more than one responsibility it becomes difficult to use. This is because methods and classes start becoming tangled with one another and when it comes to fix or add something new you are stuck on cleaning up more than you bargain for. You can always duplicate code but that will lead you to additional maintenance and increases the bugs in your program. When structuring your class you want to be able to access the behavior you need.

This thought process helped me understand on why one should not rush to write code and actually sit down and plan what my application need and how can i create methods and classes that are easy to add changes later on. This chapter also answered what approach one should take when refactoring code. When you have a method with many responsibility, you are stuck writing comments and going to through previous code just to find a bug. When you have a method with just one job, your code basically writes your comments it self because it becomes self explanatory.

As a newbie in the programming world, i tend to write super long methods and then try to refactor the code by having less lines but losing readability in the long run. Sandi Metz explains that the methods and classes we create will affect how you think about your application forever. With this in mind i'm making a disaster every time i make a long method and when i want to make a small change i have to go through everything and change code just to add a feature.

This is a big no-no in the real world. One should be able to add a new feature without breaking the existing program. When it comes to single class responsibilities the main objective is to create methods and classes as it's name applies to have A single function that it's only job is to do one thing. Breaking your program into small single function methods can save you time and relieve you from a future headache when designing your next program.

After finishing the chapter I came into the realization that refactoring code was not always about using fancy and clever ways to typing less code, it was about breaking code into smaller chunks that work both independently and Interchangeably with one another. This makes the process of writing cleaner and easily upgradable code for later use.  Sandi Metz does a great job in teaching new programmers and old alike about the power of keeping things DRY and simple when thinking and planning your next program. Writing application with future features in mind even if you don't know what they are can help you or whomever works on your application on a future date.

When it comes to ruby .each method there are countless analogies to explain the thought process behind the hood. i like to think you use the .each method to anything we do in real life. For example when you do laundry and you're sorting socks you take one sock and check all the other socks to see if they equal so that you can fold them. example

socks.each { |sock| if sock == "match" then fold socks end}

Ok so maybe that was not the best example but lets say if you're going out and you are looking for the best pair of shoes or the best looking tie. You will try to match the tie to the suit your wearing. So the example code can go like this:

ties.each { |tie| if tie == "match" then return tie end }

Good example? no you say? Ok how about when you're in the car and you're looking for a radio station to listen to. When you press scan that will iterate through all the available radio stations until it reaches the condition of you liking the music at that particular radio station.

radio_station.each { |music| if music == "good" then return music end }

Another example of real life iterating is when you are reading a book. Reading a book you have to iterate through each page to move on to the next, when reading pages you have to iterate through each word and when you reading words you have to iterate through letters. An example of what i just stated using .each method would be

books.each do |pages| pages.each do |words| words.each |letters| letters.each end end end end

Last thursday i met a few people at the Flatiron school manhattan campus meet-up, I met a few people that are interested in applying into the 'Flatiron School NYC Web Development Fellowship' program. They asked me about the process towards getting accepted into the program. FIrst thing i stated was that everyone's journey towards getting accepted was different, to be really serious about wanting to apply to this program and to not be someone who thinks they want to learn how to code. 

I know that last statement sounded a little harsh but the reality is coding is not easy and it's not for everyone. At the flatiron school we have all types of people with interesting stories and people who truly want to learn how code and are driven everyday to be better than the day before. 

To do this program you have to cut out many things from your life. There is no staying up all night watching Netflix, there will be many times you won't be able to have quality time with your significant other and times you won't get to see your kids since by the time you get home they would be fast asleep. *Note: I don't have kids just stating some hardships some of my classmates go through*

Everything i stated above is for 18+ weeks. Once the program ends it doesn't mean you are good to go, you still have to dedicate countless amount of hours on working on your craft. You should always be working on your craft if you eventually want to be the best at it.

My advice to anyone who really wants do this program is that you have to really be dedicated and ready to pour your heart and soul at every step on the way. The stars will align in your favor if you apply that much dedication to anything and everything you put your mind to.

One of the things i’ve been doing for a few months was write that i was inspiring to be a web development magician. What’s funny about that term is that when i use Ruby, i feel like i’m typing magic with my fingertips. There are times you use methods that do exactly what you want but have no idea whats going on behind the scenes.

A few days ago at the Flatiron School my instructor Blake was lecturing about loops and iterator. What’s interesting about the Ruby language is how easy they allow you to iterate through code. The problem is that you become dependent at how easy it is but you sometimes have no idea why. At one point in the lecture my instructor Ashley starting to explain loops and iteration by using JavaScript For loops example. In a JS for loop, there is a state, condition and increment.

for (var i = 0; i < 100; i ++) { //Code goes here }

Var i = 0 would be the state of the loop, i < 100 is the condition of when we want our loop to end and i++ would be our increment. In Ruby there are many ways to do this without realizing that you are declaring a state, condition and a increment. For example if you want to print something 100 times all you need to do is

100.times { |i| puts i }

compared to javascript

for (var i = 0; i< 100; i++) { console.log(i) }

As you can see in the Ruby example the condition and increment is done behind the hood without you knowing how it works. What’s great about it is that if you come from learning another language like JS into Ruby, you appreciate those methods and how easy Ruby make things look like magic. What’s great about my instructor Ashley explanation is that i can see how programmers take the previous knowledge they have learned in other languages and apply them to new languages.

At Flatiron School we were given the task to solve a programming challenge that is usually given to people new to programming. The challenge was to solve 'FizzBuzz'. For those who don't know FizzBuzz is a classic children's game where you count upwards from 1 and each time the number is divisible by three they have to shout 'Fizz' and each time it is divisible by five they have to shout 'Buzz'. When a number is divisible by both three and five they have to shout 'FizzBuzz'

In class the challenge involved us printing the numbers 1 to 100, when the number is divisible by three, puts Fizz, when the number is divisible by five, say Buzz and when the number is divisible by three and five say FizzBuzz.

My approach to the problem was solving each task one by one. I went ahead and printed the numbers 1 to 100 by using the times method in ruby. This method prints integers how many times you want starting from 0. At first you would think that doing 100.times will print 1 to 100. What that actually do is print from 0 - 99 since the method starts from 0. To solve this i wrote a base case in the beginning of the loop stating 'next if the current integer equals to 0' and having the times go 101 times so that i get 100 at the end of the loop. This solution took care of the first task. I went to the next task of finding the way of printing Fizz, Buzz and FizzBuzz. I did Fizz first by writing if the current integer % three equals to 0 then that means that number is divisible by three and so it should print Fizz. I did the same thing for Buzz by replacing the equation with the number five. After you complete those two task then you have to figure out how to find a way to print out Fizz Buzz. to do that you have to use the and && conditionals. This allows you to say, if the current integer is divisible by five and (&&) divisible by three then print out FizzBuzz. Below is my simple solution to the challenge.

As you can see i took the simplest beginner approach to the solution towards this classic problem. After completing this i asked my instructor if she's seen any cool minimum solutions to this problem and thats when she assigned us to search the web and write about a cool solution we found and kind of compare to our own solution. After searching the web i found a cool minimal solution to the problem.