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
