Category Archives: flatiron

My Journey Of Learning Programming Through Flatiron School #11

My name is Mason Ellwood, and I’m currently working on Flatiron School’s Online Full Stack Web Development Program. Each week, I’ll be writing about my experience, what I’m learning, and tips on learning to code.

Last week I was reading on wired that the next big blue collar job was going to be coding. I did not really know what to think of this. At first glance, programming lost its luster of being an untapped needed career, making me (a programmer) replaceable. This has always been the case but the recent boom of programmers is scary when entering a profession, competing against some of the smartest people in the industry.

On Wednesday I went to meet up with my weekly trivia team, and a new guy came who was a “full stack” developer. He used that term loosely because of the “what the heck does that entail” title that holds. But he kind of reaffirmed my fear of the article and agreed. Sure he said but this is no different than any other career now. It seems like everyone is fighting to stay ahead of the curve and automate as many processes as they can. Because technology has become such a cornerstone for many companies, automating and maintenance surly would follow. But because of this the need for “maintenance” increases especially within the dev community.

He agreed with the article, but development turning into the lusterless career path is not true. The need for developers is greater now that it has ever been. Being apart of the growing community of developers is a great place to be right now. And the need for “you” in a company setting is only going to become more prevalent.

Search Enumerables 

So picking up where we left off. Every method in Ruby must return a value. When we iterate or enumerate over a collection with #each, its return value is always the original constant. With this in mind, if we want to display the changed array values, dependent on what your method does, you may need to add an empty array ( new_array = [ ] ) to shovel ( << ) those values into.

There are many forms of #each, that can enact different outcomes. A few of the others are:

  • #select => When you invoke #select on a collection, the return value will be a new array containing all the elements of the collection that causes the block to pass a return value as true.
  • #detect/#find => #detect and #find can be used interchangeably. This will return only return the first element that makes the block true.  
  • #reject => #reject will return an array with the elements that return a false value

These listed above are all apart of the family of search enumerators whose purpose is to help you refine a collection to only matching elements.

A few that I use most often, I have found, is #each, #collect or #map (which are interchangeable), and each_with_index. A little more about enumerators can be found, and a quick reference that I have found very useful, is located here (http://ruby-doc.org/core-2.2.0/Enumerator.html). You will use these all the time, and I know how important this concept is. Locating and changing information based within your set of data is a key to programming. Essentially programming is the pushing and pulling of data and data manipulation. Being able to quickly and effectively iterate through data will increase your chances of landing a job, and becoming an officiant “blue collar worker” – as Wired so eloquently stated.

Read More at My Journey Of Learning Programming Through Flatiron School #11


Source: Web Design Ledger

My Journey Of Learning Programming Through Flatiron School #6

My name is Mason Ellwood and I’m currently working on Flatiron School’s Online Full Stack Web Development Program. Each week, I’ll be writing about my experience, what I’m learning, and tips on learning to code.

Throughout my learning to program career, it seems like all I have and will be doing is learning and never actually be able to start my carrer. That seems like a stupid sentence, but a lot of the time it seems like the list of things I NEED to know does not stop. Every job listing you need to know 20 different abstract languages to even get your foot in the door, and I am constantly under qualified or lack enough experience to even land an interview. To put it frankly; that sucks. So where is the standard, what do I NEED to know, and what will actually be used on a daily basis; because if in my head I am constantly juggling 20 different language’s syntax on a daily basis, I may be over my head… I was discussing this with one of my good friends Paul Jackson who works in IT, and he helped me set everything straight. He said “If you master a language OOP (Object-oriented programming) concepts it will show in your work. Companies just want you to contribute in a certain way rather than to be an expert in all.”

As Eli eloquently touched on, most job postings come from a “pissed off IT manager” and a human resource person who both do not really know what they want. After the IT manager dumps tons of data on the human resource manager, he then writes a convoluted list of requirements that the developer needs to meet. When in actuality they only need you to do a few tasks, not all 20 “requirements” that are listed on the job posting. Thinking about the development world in this sense has better helped me personally prepare what I NEED to know to have a better chance at landing a developer job once I have completed the coursework for Flatiron Schools.

Alright let’s get into it, what is a Command Line Application! A Command Line Application, often referred to as a CLI (Command Line Interface) Application, are applications you interact with entirely through the terminal of shell. This includes no use of graphics or visual interface beyond what you see in the terminal. This birthed the software revolution!

“Write programs to handle text streams, because that is the universal interface”

– Douglas Mellroy, creator of UNIX Operating System

They are often times the most powerful interfaces you will interact with on a daily basis. This including GIT, Learn (the software Flatiron School is founded on), and Ruby’s CLI application interface. There are many more, but we will not talk about those.

So how do you use the CLI application logic with Ruby…. All files should follow a similar file structure with the top level directory being: bin, lib, config, spec, and something like app. You may also see .learn (specific to Flatiron Schools), .rspec, Gemfile, Rakefile, or program files like ttt.rb. If you are working in your terminal you can also use the bash command ls -lah which will show the list of files in your current directory, including hidden files (files starting in a period).

You can also use ls -a which displays all files including hidden files as well.

Inside the bin/ folder we generally want to place all the code that is relatable to running our actual program.

Inside the config/ folder you will place all the application environments. This includes all required files to initialize the environment of your program. These files connect to your database, and ensures your test suite has access to the files that contain the code it is testing.

Your lib/ folder is where a majority of your code lives. Within these files defines what your program can do.

Your spec/ folder is where test files go. These are written tests that makes sure your code behaves as expected.

Within the root directory of your Ruby program you may also file, if needed, your .rspec, .learn, GEMFILE, Gemfile.lock, Rakefile dependent on necessity.

Using Ruby’s CLI Application process, you are able to create dynamic programs that are able to capture user inputs to produces an interactive program. This follows a basic workflow:

  • Greet the user
  • Asks the user for input
  • Compares and stores the input
  • Do something with the input

As you can see by my beautiful artwork, running this program will first run files in bin/ and which are the instructions of how to execute. The file workflow sounds something like this.

  • Include the files need to execute (lib/hello-ruby-program.rb)
  • Greet user
  • Asks user for input
  • Captures that input using #gets
  • Uses user input to do something else, setting it to the value of name which is in the method of greeting
  • Sends that value to the lib/hello-ruby-program.rb
  • Execute method with user inputted value
  • Display return value to the terminal.

Using this logic allow users to input a value directly to the terminal, with a return value displayed to the user.

Calling the gets method captures the last thing the user typed into the terminal, which can be set to a variable. Calling gets freezes the program until user inputs some value.

Comment below if you need any further explanation on what was covered before, and I will do my best to elaborate.

Read More at My Journey Of Learning Programming Through Flatiron School #6


Source: Web Design Ledger