DEV Community: Leigha

ABSWIATH- a little inspiration for job seekers

Leigha — Mon, 03 May 2021 21:53:08 +0000

Wait- what the heck is that? Well, it's something that I've been saying to myself a lot lately: Always Believe Something Wonderful Is About To Happen.

I'm currently searching for my first engineering job after switching careers. I really don't need to say it, but it's tough out there! Some of you are probably in a similar situation, so this post is for you as much as it is for me.

Always Believe Something Wonderful Is About To Happen

It's so easy to become discouraged when you haven't gotten that YES yet. It is disappointing to make it through the first interview, only to be rejected at the second or third. It's tough to end up as second choice, knowing that you have to start the process all over again.

You already know that it can hard not to focus on these feelings. But, let's remember that it's important not to let them take over. Instead, try to turn that energy around to make it work for you. Stay positive, treat your mistakes as opportunities for growth, and remember that it just takes one yes!

Don't take the rejections personally since there are so many reasons that decisions are made. Focus on what you can do to improve your next interview experience and avoid making assumptions as to why you didn't get the job.

In life, you get out of it what you put into it. So, this means that you not only have to do the work, you must project your desires out into the universe. Whoa, unicorn sprinkles alert! Seriously though, you have to put your energy out there to get what you want. Visualize yourself in your new role, as part of the team, contributing to the greater good of the world. You must stay positive and keep an open mind if you want good things to come.

Although you may be feeling defeated at times, try to remain hopeful about what is yet to come. You will attract good things with your positive energy and then it is just a matter of time before something works out for you.

Best of luck in your job search! Keep putting good energy into everything you do & don't forget to...

Always Believe Something Wonderful Is About To Happen

Safe Navigation Operator

Leigha — Mon, 07 Dec 2020 05:06:31 +0000

Photo by Zumberto _ from FreeImages

We can't function without operators in any language, and sometimes working with them can be a bit confusing. But, did you know that there are some lesser known operators in Ruby that can make your life easier?

In this post I would like to explore the Safe Navigation Operator a bit further.

Lately I have been going through old projects to refactor, clean up my code, and get things live. I have been noticing many places where this smooth operator would have been useful.

What exactly does it do?

The Safe Navigation Operator returns nil if a method is called on a nil object.

Why should we care?

Well, it is best to avoid throwing errors at your users. It's not very nice!

Let's take a look at a quick example:

    patch '/pizzas/:id' do
        @pizza = Pizza.find_by(id: params[:id])

        if @pizza && @pizza.user == current_user
            if @pizza.update(params[:pizza])
                redirect to "/pizzas/#{@pizza.id}"
            else
                erb :'/pizzas/edit'
            end
        else
            redirect to "/pizzas"
        end 
    end

In the snippet above, I am checking to see if there is indeed an instance of the Pizza class found by id, and if there is, does that instance's user match the current user?

    if @pizza && @pizza.user == current_user

This works just fine, but it would be cleaner to write:

    if @pizza&.user == current_user

Why not use .try? Well because that is provided by ActiveSupport as part of Ruby on Rails, which is awesome! However if you wish to remove this dependency, just use the Safe Navigation Operator instead of .try.

Getting data quickly in Ruby

Leigha — Sun, 29 Nov 2020 21:11:43 +0000

Photo by Weber VanHeber from FreeImages

This mini post is a follow up to the Hash-tastic! series.
You can find it here: https://dev.to/leighad/hash-tastic-part-one-1706

In that series, I presented a nested data structure and discussed how to extract the data within it. I did not use any built in Ruby methods, but instead I chose to write all the code out for purposes of learning.

Here I would like to show a quick and easy way to use a built-in Ruby method to pull out this data. While built-in methods are quite handy and certainly can save time and lines of code, it is really important to understand what is going on behind all that 'magic'. There are so many good ones to choose from, but for this example, we will look a bit closer at Ruby's values_at method.

Say you have an array:

arr = ['cat', 'dog', 'bird', 'fish', 'rabbit']

You could get multiple non-sequential values this way:

x, y, z = arr[0], arr[1], arr[3]

Or you could just use the values_at method:

x, y, z = arr.values_at(0, 1, 3)

This would return the values of elements 0, 1, 3 which are cat, dog, fish

You can also use values_at with a hash:

candy_hash = {gummies: 5, sours: 7, chocolate: 10}

Here you could write:

candy_hash.values_at(sours:)

This would return the value of sours: which is 7

As you can see, built-in methods can be quick and easy to use. It is tempting to grab one when you need that quick fix, but just make sure you really understand what is happening behind all that Ruby 'magic'!

Hash-tastic! part three

Leigha — Sun, 22 Nov 2020 23:21:10 +0000

Photo by Joel Dietle from FreeImages

Hello again! I hope that so far you are learning to appreciate hashes and the power of nested data structures. Let's take a final look at our awesome bookshelf hash. In case you've forgotten what it looks like, parts 1 & 2 of this series have a lovely image for review.

This time we'll be working with the last shelf, the Harry Potter bookshelf, a hash of hashes. We will go over how to output data from within this structure that is itself nested within the parent hash bookshelf.

The desired output in this example is a sentence that displays to the user the book number (1st level key) and title (2nd level key) of every volume within the ':harry_potter' shelf.

Run the repl.it below to see how it works.

Here is a closer look at the magic that makes it happen:

def print_potter_books(shelf)
  shelf.each do |volume, info|
    info.each do |k, v|
      if k == :title 
        puts "The title of #{name(volume)} is #{v}."
        sleep(2)
      end
    end  
  end
end
print_potter_books(bookshelf[:harry_potter])

Here we take the ':harry_potter' shelf, iterate over it, taking each volume, which contains info, and then iterating over that info, making a comparison against each key inside the info and if it matches, outputting the desired text containing data from two different layers of the hash.

NOTE: The name method can be found on line 44 in the repl.it

Whew! If that was a bit much, just take a moment to read the code line by line. Try to think about the nested data structure like an onion and just peel away at it one layer at a time.

For example, the code to show the user the date for Book 7 looks like this:

puts bookshelf[:harry_potter][:book_7][:date]

Puts out to the user:
2007

Here it is easy to see the different levels of the data structure. The parent hash is bookshelf and to get to the date you must reach down three levels.

Thanks for reading this far. If you didn't already know how awesome hashes and nested data structures are, hopefully now you do (at least a little bit)!

React Redux final project- the journey continues

Leigha — Wed, 16 Sep 2020 20:36:44 +0000

Photo by Bjarte Kvinge Tvedt from FreeImages

What an exciting journey this has been so far! I am really proud of how much I have learned in just a few months. Let's keep this good energy going!

I have been thinking about this final project for some time, and I have an idea I am quite excited about building. However, when project time came around, I found myself facing one of life's most difficult challenges. Before I go into the details of my final project, it is important to take a brief but sad detour. My sweet English Bulldog was nearing the rainbow bridge. We were advised to make final arrangements for her. So heavy was my mind and heart that I knew I had to change my idea- there was no other way I would be able to focus.
*see end notes for more...

Now let's get happy again and talk about React and Redux- how much fun are they to play with? After swirling around while learning JavaScript for a spell, it was nice to put it to work using React's sensibly structured components. And Redux makes managing state less complicated by keeping one tidy store. Both libraries have documentation that is well-written and easy to follow.

As much as I enjoy working with both, I would like to focus this post on some fundamentals of Redux. Although Redux is typically used to manage complex state, working with it in my final project was a great learning experience.
Let's dig into some important things to remember when working with Redux.

The three fundamental principles of Redux:

Single Source of Truth

Your app's global state is stored within an object tree 
inside a single store. This makes debugging easier.

State is Read-only

Actions are the only way to initiate a change of state. 
This prevents any unwanted changes to your app's state.

Changes are Made with Pure Functions

Reducers specify exactly how state should be transformed 
by these actions.

Note: a pure function is one that produces the same output when given the same input and is free from side-effects (doesn't alter outside state).

Another thing that is critical to understand is Redux flow.

        Action ==> Reducer ==> Updated State

Actions are passed to the Reducer which initiates a change to State.
Let's take a look at this lovely diagram for a better understanding.

https://stackoverflow.com/questions/45416237/axios-calls-in-actions-redux

Here we can see in detail the flow of state change through Redux. The Store contains the current State which defines the user interaction that triggers an Action. The requested Action is sent to the Reducer using dispatch() which takes the current State from the Store, applies the requested Action, and then returns a new, updated version of State. Please note that the State that is returned is actually a copy of the original State with the updates applied. Remember that State is never mutated- use of the spread operator allows us to make a copy, apply the necessary changes, and return this updated State to the Store. To summarize:

Action creators are functions that return actions
Actions are objects that have keys that include instructions that the Reducer uses to change State
A Reducer is a function with a switch statement inside that receives instructions about how to change State using two arguments:
currentState and action
The Store in Redux is an object with two functions:
- dispatch() initiates changes to State
- getState() gives access to the current State

*End notes: Tankie is actually doing much better- we ended up getting a second opinion and some hope. We also believe in the power of miracles. Thanks to everyone who sent good thoughts our way!

Also- my new idea is such a good one that I will be writing a post all about it once I have finished working out my stretch goals. Please stay tuned for more!

Photo by Cheryl Empey from FreeImages

Tricky bits of JavaScript

Leigha — Fri, 26 Jun 2020 15:59:21 +0000

Photo by artM from FreeImages

When learning a new language, it makes sense that some parts will seem kinda familiar while others are quite mysterious. I'm studying JavaScript now and there are a few tricky bits I'd like to review in more detail.

      var, let, const  ◆  hoisting  ◆  scope  ◆  closure

Before we go into the topics above, let's take a look into how JavaScript is working 'behind the scenes'. The JavaScript Engine actually makes two different passes over your code and in the first pass, called the Creation phase, the code is not executed line by line. Instead, a global object and an associated this are created, and variables get set up in memory. During the second pass is where the work begins, called the Execution phase because this is when your code is actually run line-by-line and values are set to the variables previously defined and stored in memory during the first pass.

Having a good understanding of how the JavaScript engine actually evaluates your code is a valuable tool. This will be more evident as we explore the topics mentioned inside the box at the top of this post.

Prior to the release of ES6, var was the only choice for variable declaration. As it turns out, var can cause some trouble in your code due to its flexible nature, and that is where let and const come to the rescue. Let's take a look at each variable declaration type a bit more closely.

Before we go over var, let, and const, it is important to review the concept of scope. Scope is defined as "the current context of execution" and is basically where a variable is available to use. In the case of var, it is function scoped when declared within a function and global scoped when declared outside a function. Function scoped means that the variable is accessible and available within that function only. This is quite different from global scoping where the variable becomes available to the entire window.
Consider this example:

   var mood = 'happy';

   function changeMood() {
     var newMood = 'curious';
     console.log(newMood);
   }

   console.log(mood);
   changeMood();

Here, the first variable declaration is within the global scope, so it is available for use anywhere within the window. When you console.log(mood), the output is 'happy', accessed from the global scope.

The second variable declaration, inside the changeMood() function, exhibits functional scope behavior. When changeMood() is called, the output is 'curious' since the variable newMood was declared within the function. It is available to the function itself, but if you tried to console.log(newMood) from outside of the function, you get: ReferenceError: newMood is not defined. The scope of newMood is only within the changeMood() function.

In the case of let and const, variable declarations using these keywords are block scoped only. This means that variable declarations can only be accessed within the block (inside the curly brackets only) from which they were declared. Keeping variable declarations out of the global scope helps to prevent bugs and issues with overwriting variables previously declared.

Now that we've briefly covered scope, let's take a look at some of the behaviors of var that led to the need for let and const. When you use var to declare a variable, JavaScript won't prevent you from redeclaring that variable, in fact it won't even let you know that you have overwritten a previously declared variable. Oh no!

  var cat = 'Coco';
  var cat = 'Beebee';

  console.log(cat);  //=> Beebee

The output for cat is 'Beebee' since var allows for redeclaration of variables. This is an easy way to put bugs into your program and should be avoided. Take a look at how let and const prevent this down below:

  let cat = 'Coco';                  const cat = 'Coco';
  let cat = 'Beebee';                const cat = 'Beebee';

  console.log(cat);                  console.log(cat);

  `SyntaxError: Identifier 'cat' has already been declared`

Also note that var and let variables can be updated, whereas const can only be defined once and may not be updated.

Remember how the JavaScript engine processes your code in two passes? Good, let's put that knowledge to use. Hoisting is defined as when variables and function declarations are 'moved' to the top of scope before execution. Well, they aren't really physically moved, but during the Creation phase they are set into memory and variables declared with var are initialized with a value of undefined. Variables declared with let and const are not initialized with a value, but are still set into memory. So if you try to use a variable with let or const before it is declared, a Reference Error occurs. Let's take a look at some examples:

    console.log (greeting);
    var greeting = "hola"

Will be interpreted like this:

    var greeting;
    console.log (greeting); //=> greeting is undefined
    greeting = "hola"

And when using let or const:

  console.log (greeting);         console.log (greeting);
  let greeting = "hola";          const greeting = "hola";

ReferenceError: Cannot access 'greeting' before initialization

An interesting note about const:
Variables declared with const must be initialized at the time of declaration.

   const greeting;
   console.log (greeting);
   greeting = "hola";

   SyntaxError: Missing initializer in const declaration

So in summary:

	Scope	Update?	Re-declare?	Hoisted?	Initialized
var	global or functional	yes	yes	yes	undefined
let	block	yes	no	yes	no
const	block	no	no	yes	required

The last topic I would like to cover here is closure. Closure is when an inner function is able to access the outer function's variables, creating a scope chain. This should make sense now that we understand scope and hoisting. The following example should be helpful:

let learn = 'learning experience! ';
let result;
function phrase(a){
  return function(b) {
    return (a + b + learn)
  }
}

result = phrase('Enjoy ')('your ');
console.log(result); //=> Enjoy your learning experience!

The innermost return of this function uses variables that have been declared outside of the inner function. This is possible because the scope chain is maintained by the inner function. When the function is executed, this scope chain allows access to the variables that live inside the outer function. This example would also work with var (but don't!) and will not work with const due to the need to initialize variables using const at the time of declaration.

Hopefully this helps to clarify some of the more mysterious parts of JavaScript functionality. Understanding these tricky parts will help you write better code!

Putting it all together...

Leigha — Wed, 10 Jun 2020 16:17:13 +0000

Photo by Luis Francisco Cordero from FreeImages

This post is all about my first project using JavaScript with Rails as API!

This was definitely the most challenging project for me so far. Up to this point, I have been using Rails for the front and back end of my apps, but now was the time to plunge into HTML, CSS, and JavaScript to do that work instead. Without too much prior practice, I made lots of mistakes and had to do a lot of refactoring (I didn't start out using Object Oriented JS initially- big mistake!). Overall, I really enjoyed working on this project and it sure has taught me a lot!

Maybe you are having a similar experience so I would like to pass along a tip that was shared with me that I found to be quite helpful as I was working along on this project. Since I had already gotten kinda cozy with the rules and structure of Rails, it did take a moment to adjust to using JS on the front end. Before I heard this little JavaScript mantra, (please see credit below), I have to say that I felt a bit lost at times.
We all know that’s no fun, so try to remember this:

When some event happens, I want to make what kind of fetch and then manipulate the DOM in what way?

Event  ➤  Fetch  ➤  DOM manipulation

So the event triggers, a fetch request is fired off, and then the DOM changes in some predetermined way. It seems so simple when you think of it like this but there is so much going on behind the scenes during this sequence.

Consider this basic example:

    static categoryFormListener() {
        const categoryForm = 
          document.getElementById("category-form-container")
        categoryForm.addEventListener('submit', 
          function(event) {
            event.preventDefault()
            const categoryObject = { group: 
              event.target.querySelector("#group").value}
            event.target.querySelector("#group").value = ""

            fetch(CATEGORIES_URL, {
                method: 'POST', 
                headers: {
                    'Content-Type': 'application/json'
                },
                body: 
                 JSON.stringify({category:categoryObject}) 
            })
            .then(res => res.json())
            .then((json) => {
                new Category(json)
                Category.addCategoriesToDOM()
            })
        })
    }

This class method is using .addEventListener to listen for a 'submit' event. So we are waiting for the user to enter some information into the Category form and then click 'submit'.

After this event has triggered ('submit' has been clicked), a fetch request is made to the CATEGORIES_URL. This returns a promise that resolves to the response of that request. Response instances are returned when the fetch() promises are resolved, successful or not.

What exactly is a promise though? According to MDN, The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value. The resulting value will be parsed into JSON so then the data returned can be manipulated on the DOM and displayed to the user. It is the json() method of the Body mixin that takes a Response stream and reads it to completion. It then returns a promise that resolves with the result of parsing the body text as JSON.

This JSON is then used to manipulate the DOM to render the desired result, in this case, creating a new Category.

This is what the Category form looks like on the front end:

->credit to Ayana, thank you so much!

A Stitch in Time...

Leigha — Wed, 06 May 2020 06:30:56 +0000

Photo by Bev Lloyd-Roberts from FreeImages

For my first Rails project I created a knitting pattern sharing app where users can CRUD patterns as well as rate and comment on patterns. Even though there are tons of gems available that can make building your app much easier, I decided to write the code myself so that I could fully understand what was going on behind this ‘Rails magic’ I always hear about. It is pretty magical, but let’s acknowledge where that magic really comes from. Rails is the product of hard-working developers who have made our app creating journeys much easier, and for that I want to start off with a great big thank you!

Working on this project has been really enriching and I’m looking forward to adding a few more features and improved functionality as well as some styling to this fun little app. At this stage, everything I have learned so far is coming together quite nicely and I am feeling more confident in my programming abilities. That being said, I still have points of total confusion mixed in with the oh-so-great feeling of getting things working successfully. But, I am smart enough to be aware that:

“The more I learn, the more I realize how much I don't know.”
Albert Einstein

Photo by Julia Freeman-Woolpert from FreeImages

There are so many amazing parts and pieces to this project that I had a tough time narrowing down what I wanted to focus on for this blog. I could certainly talk about the MVC structure, or discuss nested routes or how to write validations or even go into detail about creating views. While all of this is incredibly important, I realized that the organized approach I took with this project ended up working out really well (surprise!) and that I want to emphasize that in case anyone needs to hear it.

Before I even wrote one line of code, I made sure to clearly define my associations and the user story. I'll give you a peek here:

User story

Users will be able to:
    -sign up, log in, log out

Users can:
    -CRUD patterns
    -rate and comment on patterns

Wireframing (attributes and associations)

    Models: User, Pattern, Comment

    User attributes:
        username
        email
        password_digest 

    User associations:
        has_secure_password
        has_many :patterns
        has_many :comments
        has_many :commented_patterns, through: :comments, source: :pattern

    Pattern attributes:
        pattern_name
        gauge
        level :integer
        instructions :text
        notes
        user_id

    Pattern associations:
        belongs_to :user
        has_many :comments
        has_many :users, through: :comments

    Comment attributes:
        rating :integer
        content :text
        user_id
        pattern_id 

    Comment associations:
        belongs_to :user
        belongs_to :pattern

Having all of this clearly written out gave me solid direction for this project. What a big difference it makes! Like anything else in life, it pays to be organized and prepared. Something else I found really helpful was to break the project down into chunks that I could tackle day by day. In previous projects, I was overwhelmed at times thinking about all the pieces that needed to be done. This time though, since I gave myself reasonable amounts of work to do daily and I had some direction as to where I should be each day, I felt much less stressed and was able to focus on the joys of creating and the buzz of all that logic processing inside my brain.

Before you go, I want to share something I discovered that I will definitely be using next time: GitHub projects. Yes, I realize there are many wonderful apps for organizing your projects, but here’s the thing, you’re already working with GitHub (right?) so why not use their features? Not only will it help you stay on track and keep all your details together, you can also add GitHub functionality to your project board. Sadly I did not know about this great resource in time to use for this project, but I will be using it in the future, so I'll let you know how my experience went. Here's a tiny preview:

Thanks for reading and happy coding!

The Sinatra Project: Pizza Hub

Leigha — Mon, 30 Mar 2020 06:09:30 +0000

Ahhhh- pizza! The combination of flavors and textures makes it the perfect comfort food. I must have been craving some because when it was time to choose a meaningful idea for a Collection Management System project, the choice was obvious- I would create an app using MVC and Sinatra ActiveRecord with full CRUD capabilities that would allow a user to create, read, update, and delete pizzas.

How exciting! This was where I could put everything that I have learned so far into action. Although I would love to discuss every detail of this project since I had so much fun working on it, for the sake of time I will just highlight a few things I found to be notable.

To start, I was delighted to hear about a gem called Corneal that would help me get this project going. Until this point, I had been building everything from scratch. It was really cool that when I initialized this project, Corneal took care of the basic scaffolding for my app. And since the general framework was already created, I was really able to focus on actualizing all of the ideas that I had swirling inside my imagination.

As I was building this basic project, it was impressive that the Models are quite bare with the exception of inheriting from ActiveRecord::Base and the presence of a few powerful macros. The has_many and belongs_to relationships are established here, allowing for associations between users and pizzas as well as many methods made available through ActiveRecord. I used bcrypt for password encryption, so the has_secure_password macro was also included in my User class.

In this project, I used:

.create to create a user or a pizza
.find_by_id and .all to read users or pizzas
.update to update a pizza
.destroy to delete a pizza

Stretch goal: add .update and .destroy functionality to User

It was helpful to keep in mind the flow of a Sinatra request and RESTful convention as I was building the routes within the Controllers.

Building out the Views was quite interesting- I think .erb is really neat and I have very little HTML and CSS experience. This is an area that I used up a lot of time playing around with small visual and functional details. Also, I did run into an issue regarding the use of a textarea tag vs an input tag with type="text" inside the form used to create a pizza. In the case of the input tag, the data entered by the user will populate into the form shown via the '/pizzas/edit' route, but the data within the textarea doesn't without the use of additional code. Any ideas?

Stretch goal: figure out how to get user data from textarea

Here is a look at the home page as shown when a User is logged in. The top nav bar is not shown if user not valid or logged in.

To achieve that, I wrapped the nav bar code with the following inside the layout.erb file:

<% if Helpers.logged_in?(session) %/>
       #html code for the nav bar 
<% end %>

and the following inside the helpers.rb file:

def self.logged_in?(session)
    !!session[:user_id]
end

Stretch goal: add full functionality for Ingredient MVC

The code below was placed inside the User model to validate the presence of and uniqueness of both the User's user name and email:

validates :user_name, presence: true, uniqueness: true
validates :email, presence: true, uniqueness: true

This project is still under construction, even though at this point I have covered the basic requirements. A User can sign up, login, create, read, update, and destroy pizzas. A User must have a unique username and email, and can only update and destroy pizzas that belong to that User.

Stretch goal: improve styling and overall user experience

Stay tuned for more updates as they happen!

Photo by pixaio from FreeImages

Hash-tastic! part two

Leigha — Sun, 23 Feb 2020 02:37:40 +0000

Photo by Alessandro Cattelan from FreeImages

Welcome back! I bet you're ready to dig a bit deeper into our awesome bookshelf hash. We are going to take a closer look at accessing information from a variety of nested data structure types.

Let's get started by checking out that lovely hash again:

By now you should be pretty familiar with the primary keys and the data type of the values each key returns. If not, no biggie! Just go back to part one and browse around a bit longer- sometimes it takes a moment for new concepts to really soak into that amazing brain. It's ok.

Run the repl.it below to see how to work further with this hash.

Take some time to review the code for each example, noting how to access the desired values. We will go over each example in more detail below.

1. Print the value of shelf one, a string, in uppercase:
This really just builds off of what we went over in the first post. Access the value of ':shelf_one' directly and convert that string to uppercase.

bookshelf[:shelf_one].upcase => "ENCYCLOPEDIAS"

2. Access the value of shelf two, an array, and print the last element:
Here we are grabbing the value of ':shelf_two', an array, and returning the last element.

bookshelf[:shelf_two].last => "Star Atlas"

3. Print each item in the array from shelf two:
Using the same array from example 2 above, puts each element out to the user. Note that the return value is the original array since we used '.each'.

bookshelf[:shelf_two].each {|b| puts b} => ["World Maps", "Star Atlas"]

Puts out to the user:
World Maps
Star Atlas

4. Print each key/value pair in the hash from shelf three:
The value of bookshelf[:shelf_three] is a hash, this example shows how to puts each key/value pair out to the user. Return value is the original hash.

bookshelf[:shelf_three].each do |k,v|
   puts "#{k}: #{v}"
end

=> {:sci_fi=>"The Collection", :coloring_books=>"Mandalas"}

Puts out to the user:
sci_fi: The Collection
coloring_books: Mandalas

5. Iterate over the hash of arrays from shelf four and list the key along with each value:
The value for the ':shelf_four' key is an array, and for this example the goal is to puts out to the user each element of the array as a value of the secondary key ':sci_fi'. For this to work, we must take an additional step to grab each value and put it out to the user along with the key. As you may have guessed, the return value is the original value itself.

bookshelf[:shelf_four].each do |k,v|
   v.each do |v|
      puts "#{k}: #{v}"
   end
end

=> {:sci_fi=>["The Collection Two", "Fantasy"]}

Puts out to the user:
sci_fi: The Collection Two
sci_fi: Fantasy

As you can see, working with hashes and nested data structures isn't as scary as it seems. Analyze each layer, take it step by step, and don't be afraid to play around with the structure to grab and manipulate data as you wish.

See you next time for the third and final part in this series!

Photo by Göran Nyqvist from FreeImages

Hash-tastic! part one

Leigha — Sun, 23 Feb 2020 01:12:44 +0000

Photo by Márcia Rodrigues from FreeImages

For many of us, hashes can be intimidating. Just when you thought you had mastered arrays, here come hashes with their snazzy curly brackets and all that extra syntax. Such show-offs!

Really though, as the information you are working with grows larger, it is important to be comfortable with accessing and manipulating data stored in collections. It will be common for you to see nested data structures of many types used: arrays of hashes, hashes of arrays, hashes of hashes, just to name a few. Looking at all that data packed away inside those nested brackets, curly and otherwise, can seem overwhelming and as a newbie you may be left feeling confused. Fear not! Hashes are your friends.

Let's talk about hashes and how to break them down into understandable pieces. I like to think of hashes as well-arranged book shelves where the contents of each shelf can be organized into key/value pairs.

Take a few moments to really understand the following hash:

It looks pretty complicated, but if you break it down piece by piece, you will see that it isn't as scary as you thought!

Run the repl.it below to see how to work with the first level of this hash.

To reach into the first level of this hash so that you can view the contents of each shelf is easy! Just type the name of the hash with square brackets around the 'shelf', or key name. Like this: bookshelf[:shelf_name]

Take a few minutes to check out the repl.it again and consider what type of data each shelf returns. Feel free to explore the code to gain a better understanding of this hash as we will be discussing it in more detail over the next two parts of this series.

By the way-
That last bit about the Harry Potter shelf is quite messy! No worries! We will take a look at how to better display that data in part three of this series.

NOTE:
I did want to discuss the method on line 44 a little bit...
As the hash is written, each first-level key is a symbol that includes an underscore which is not very pretty when put out to the user. To be more user-friendly, I needed to change ':shelf_one' to 'Shelf one' so that the sentence to be output to the user would make more sense.

To do this, I first had to convert the symbol to a string with the .to_s method. Then I used .capitalize to capitalize the string, and then to take away that pesky underscore, I used .split('_') and finally .join(' ') to get the separate strings to behave as one.

See you next time for part two in this series!

How to and not to do a CLI project-

Leigha — Sat, 15 Feb 2020 21:36:29 +0000

Photo by Patataj Patataj from FreeImages

So far, the first module in the Flatiron online program has been really fun and at times overwhelming. There is just so much useful information to learn! I'm pretty excited to be at the point where we are taking everything we have practiced so far and are putting it all together in our first project: create a CLI Gem.

My plan was to get started right away, which would give me over a week to work on the project. That would be ideal and is usually my approach. Well, plans don't always go through and as it turns out, I ended up only having a handful of days to work on this due to a family emergency. So I may have started off in a bit of a panic.

Challenge #1
I was now pressed for time and feeling unsure about being able to produce a nice product. I did not take time to think about the project itself much before I just dove into 'getting it done'.

Solution
Before you approach a project, or really anything meaningful in life, you should take a moment to reflect on your intent. Try to visualize the process and focus on the final product. View any obstacles you may face as opportunities for growth.

If I had just taken the time to really think about my project before getting started I could have saved myself a few wrong turns in the process.

Challenge #2
This wouldn't have been too much of an issue without problem #1. I have no idea what I want to create! There are just too many possibilities and feeling pressed for time has temporarily clouded my creative abilities. Here is where I should have really put some thought into the design of my program. Sigh.

Solution
Take time to carefully think about what you wish to achieve with your product. Pick something that is meaningful to you. What kind of functionality do you wish to create? Really think about the design of your interface so that it is pleasant to the user and make sure the project can be produced within the required timeframe. You can always expand on what you have built after you get your MVP going.

So I decide on my lifetime standby topic: cats. I will create a CLI that scrapes fancy cats from a webpage and gives the user details about the cats.

Challenge #3
This really builds off of problem #1 as well, and since I felt pressed for time, I did not give enough thought into choosing an appropriate site for scraping. After visiting a few sites, I found one that visually looked good and I started working on the scraping details. That site ended up being 'unscrapable' and I had to start all over again.

Solution
Make sure that the site you select not only has the data you wish to gather, but also has the necessary information you need in order to access that data. The 'inspect' feature is your friend- use it to dig around on the page to make sure you can reach the data you want. I used repl.it to help visualize finding the data I needed. Taking a few extra moments at this step will save you lots of time and headache in the future!

Photo by Marcelo Gerpe from FreeImages

I wasted some time at this step in terms of progress on this project, but I did learn a lot about scraping and what it takes to make a site 'scrapable'- valuable knowledge!

Challenge #4
I really can't emphasize that most of the issues I encountered with this project had to do with a lack of planning in the initial stages. I ended up having to redesign my interface a few times, and I don't think that would have been so much an issue if I had really thought it through before starting.

Solution
The time it takes to plan your project is well worth every moment.

After a few failed approaches, I ended up taking a break, setting up a solid plan, and then got to work. Although this project certainly is challenging, I found it much easier to create with a good plan in place.

Though I am still busy at work, I have been able to create a pleasant interface with the ability to fetch a list of fancy cat names and some history about each cat. There is also a feature to generate a random fun fact about one of the fancy cats. Currently, I am working on the code to generate lists of the most and least affectionate, energetic, and shedding cats. I'll post an update when I can!