DEV Community: Claire Muller

4 Job Search Tips

Claire Muller — Sun, 01 Sep 2019 23:16:19 +0000

Happy Labor Day Weekend! This week I thought I would gather up some of my favorite tips when it comes to looking for a job in the webdev / software engineering world.

network

The first tip that I hear all the time is to just put yourself out there! Go to meetups and events where you can meet people who are doing what you want to be doing. I've met so many people and gotten great leads on jobs just by going to a meetup or two a week.

It can feel a bit awkward at first, but I always try to get someone's contact information, usually by connecting on LinkedIn. Doing this allows you to keep the lines of communication open, and they'll be much more likely to think of you when they have an opportunity.

have an online presence

When applying for jobs, I feel like it's very important to have a good presence online. Writing a weekly blog is a great way to get your name out there and employers love to see that you're engaged in the community. Similarly, Twitter has become a wonderful place to interact with other devs and get advice from people all over the world.

Check out my previous blog post about perfecting your online presence!

Tips for Perfecting Your Online Presence

Claire Muller ・ May 13 '19

#beginners #career

follow up

The hardest part about looking for a job is when you don't hear back about a job application or connection. But I've learned to embrace the awkward and just follow up! People are busy, and we all get so many emails that it can be easy to miss things.

Following up can lead to opportunities! Sending a kind 'great to meet you' message will remind them of who you are and the (hopefully) great conversation you had. People love to be thought of and in turn will think of you.

code every day

My final tip is to work on some code every single day. It's easy to get overwhelmed with all the other aspects of the job search, and forget to keep working on your skills. I started the 100 Days of Code challenge on twitter and it's been a great way to keep myself accountable for coding a little bit each day.

Don't forget to commit your changes to your GitHub, as employers definitely look! As for what to work on, I like doing LeetCode problems, or here's another blog post I wrote about project ideas!

What Should I Make Next? Quick Project Ideas

Claire Muller ・ Aug 25 '19

#beginners #webdev #projects #ideas

Thanks so much for reading and I'll see you next week!

What Should I Make Next? Quick Project Ideas

Claire Muller — Sun, 25 Aug 2019 23:16:36 +0000

Ever since I finished up at the Flatiron School at the end of May, I've been trying to come up with a cool, new project idea. But here I am, almost three months later and I haven't started one. I've been stuck in decision paralysis and it's time to break free!

I've heard from a lot of people to just start something, especially when you're a junior dev. Instead of trying to reinvent the wheel, make a simple site that has some functionality. The point is to get practice and learn a new thing or two.

So for my blog post this week, I'm just going to make a big list of project ideas! No longer can I complain that I don't have an idea!

todo app (just kidding!)
clone of a popular social media site
site that gathers and displays news about a specific topic
site to order food from a local restaurant, with a shopping cart
clock that you can change from analog to digital
simple chat room
bill splitting app like Splitwise
site that changes colors based on the weather
funny name generator
site to save and display articles you want to read later
date suggestions
bio site about someone famous that you like
copy a simple game, like tic-tac-toe, hangman, or snake
chatbot
counter to log how many glasses of water you've drunk
site for cute pictures of your pet
simple quiz game
place to keep track of all the shoes you want to buy
web scraper
net worth tracker
calculator
music suggestions based on a given song/artist
site that simply tells you if it's going to rain or not
spoiler alert browser extension - notifies you if the page contains certain keywords
e-commerce clone
a site that just plays Mariah Carey music videos
word-a-day site
recipe generator

There we have it, no more excuses! I hope this inspires you to start something new today!

3 Productivity Tips

Claire Muller — Mon, 19 Aug 2019 02:10:09 +0000

Happy Sunday! I'm taking a break from the algorithms this week to write about something near and dear to my heart: productivity. As someone who's currently looking for a job, my days are wide open and thus I have to hold myself accountable for getting work done. It can feel a little overwhelming to be faced with a new day and no plan of how to fill it. So with that, my first tip:

schedule everything

Like a lot of people these days, I have a virtual calendar. I use it to keep track of the many events, meetups, dinners, hikes, etc. that happen in my life. A few weeks into my job search I realized that a whole day could go by and I would wonder, 'what did I even do today?' Or I would wake up with no real plan of what I wanted to accomplish.

I will say, I'm a born planner; I briefly considered becoming the next Marie Kondo. So I decided to start planning out my days ahead of time, in (possibly excessive) detail. I created a separate calendar and add blocks of time, usually 1 to 2 hours, to work on various tasks. Some examples from my own calendar include: LeetCode, clean kitchen, admin, slack bot.

I'm always moving tasks around, adjusting times, and adding new ones. Now I can have a clear idea of what my day looks like, and no longer look back wondering what I even accomplished. Productivity win!

take breaks

As I schedule everything now, that means I also schedule time to relax. We all know it's important to take breaks, but sometimes it can be hard to remember, especially when you're deep in the coding zone. Now, if it's on the calendar, I can look forward to it, which makes me more productive!

I also like to schedule 'admin' time, which is a fancy way of saying 'check every social media site 5 times'. It's usually about an hour of time for me to check my finances, socials, and watch a Gourmet Makes video (you're welcome).

if it takes less than 5 minutes, just do it now

A final tip that I find very effective is to just do the small things now. There are so many little things that might not be super urgent and thus are easy to keep putting off. Some examples from my own life include taking out the trash, putting away my laundry, or cleaning off my desk. All simple things that once completed, make me feel great!

Well there we have it, my top three tips for keeping up your productivity. Thanks for reading, see you next week!

Breaking Down DSAs: Count Primes

Claire Muller — Sun, 11 Aug 2019 21:00:45 +0000

Welcome back! All week I've been trying to think of a blog post idea that wasn't another algorithm breakdown, but yesterday I encountered a crazy cool one that I just want to talk about! The problem comes from the LeetCode collection that I've been working through, and it's called count primes.

Here's the problem: return the number of prime numbers less than a given integer, n. So given 10, the function should return 4, as there are 4 prime numbers less than 10: 2, 3, 5, and 7.

First, I had to refresh my memory on what a prime number even is (don't judge me). A quick google search told me that a prime number is a whole number greater than 1 whose only factors are 1 and itself. I also learned that a non-prime number is called a composite number! Fascinating.

My first attempt (in JavaScript) was pretty straightforward. I created a helper function, isPrime that simply accepts a number and returns a boolean. This function uses a for loop to iterate through every number from 2 up to the given number. I used the modulo/remainder operator to check if the given number divided by the current number in the loop has a remainder of 0. If it does, that means the number is not prime so we can return false. Otherwise, the function returns a boolean from n > 1, to weed out 0 and 1.

function isPrime(n) {
  for (let i = 2; i < n; i++) {
    if (n % i === 0) {
      return false;
    }
  }
  return n > 1;
}

Now my countPrimes function can use my helper to, well, count the primes. I initiated a counter at 0, and since we want to count all the prime numbers less than the given number n, I subtract one from n before I start a while loop. The loop passes n into the helper, and if it returns true, I iterate the counter. I then decrement n, and do it all again, returning the final primesCount at the end. Here's what that all looks like:

function countPrimes(n) {
  let primesCount = 0;
  n--;
  while (n > 1) {
    if (isPrime(n)) {
      primesCount++
    }
    n--;
  }
  return primesCount;
};

Phew! I was feeling pretty good, but I knew there had to be a better way. It's just not efficient to check if every single number is prime, as doing so involves dividing the number by every single number less than it. That's a lot of checks! After failing to think of a more efficient solution, I turned to my trusty friend, Google.

So here's where it gets crazy cool! I learned about the Sieve of Eratosthenes and my mind was blown. This algorithm essentially starts at the first prime number, 2, and marks its multiples as composite (not prime). It then moves onto the next prime, and so on, until reaching the given limit.

I understood how the algorithm worked but I still wasn't sure about the best way to implement it in JavaScript. Some more googling led me to this great post from Nic Raboy.

The idea is to create an array of booleans with a length of the given integer n. Initially, every element will be marked as true, except for 0 and 1, which are not prime.

let primes = [false, false];
for (let i = 2; i < n; i++) {
  primes[i] = true;
}

Now, we can start marking the prime multiples as false. I give all credit for this code to Nic, as this was pretty hard for me to wrap my head around. He creates a limit variable which is the square root of the given integer n. After a lot of thought, I realized that this avoids checking the array for multiples of numbers that are greater than n. For example, if n = 10 we only need to look at the prime numbers less than its square root, which is 3.16. There's no need to look at the multiples of 5 and 7.

let limit = Math.sqrt(n);
for (let i = 2; i < limit; i++) {
  if (primes[i] === true) {
    for (let j = i * i; j < n; j += i) {
      primes[j] = false;
    }
  }
}

Finally, our array is complete and we can simply iterate through it, counting every true instance, returning the final count!

let count = 0;
for (let i = 2; i < primes.length; i++) {
  if (primes[i] === true) {
    count++;
  }
}
return count;

Thanks for following along and I hope this was helpful to someone. I had a lot of fun learning along the way! Again, big thanks to Nic Raboy for his post. See you next week!

Breaking Down DSAs: Two Sum

Claire Muller — Sun, 04 Aug 2019 17:21:11 +0000

Another week, another blog post! I really enjoyed writing my last post about solving a popular coding problem, valid anagram, and I thought I would try another this week. So today I'll be walking through my various solutions to the popular two sum problem, using JavaScript.

There are a few different variations of this problem, but the one I'll be doing comes from LeetCode. The problem: Given an array of integers, return the indices of the two numbers that add up to a given sum.

Input: nums = [2, 7, 11, 15], sum = 9
Output: [0, 1]
Because nums[0] + nums[1] = 2 + 7 = 9

I always like to start out with the most obvious brute force solution in order to make sure I have a good understanding of the problem. So my first solution was to simply use two nested for loops to check each combination of numbers. If adding the two numbers together equalled the given sum, then return the indices of those two numbers. If there's no combination, return an empty array.

var twoSum = function(nums, sum) {
  for (let i = 0; i < nums.length; i++) {
    for (let j = i + 1; j < nums.length; j++) {
      if (nums[i] + nums[j] === sum) {
        return [i, j];
      }
    }
  };
  return [];
};

Now I learned long ago that nested for loops have a runtime of O( n^2 ), which is not ideal. There's pretty much always a better, more efficient way, and it usually involves an object/hash table/dictionary/whatever your programming language of choice calls it.

After thinking on this for a minute, I realized that I can iterate through the array and save each number and its index in an object, giving me this:

// given nums = [2, 7, 11, 15]
obj = {2: 0, 7: 1, 11: 2, 15: 3}

While building this object, I can check to see if the current number's complement (the sum minus the current number) already exists in the object. To make it a little easier to read, I saved this target number to a variable.

let target = sum - nums[i];

if (obj.hasOwnProperty(target)) {
  return [obj[target], i];
}

This way, if the two numbers are near the beginning of the array, we don't even need to check the rest of the array and can return. This solution gives us time and space of O(n), which is twice as fast as using nested for loops. The final solution looks something like this:

var twoSum = function(nums, sum) {
  let obj = {};

  for (let i = 0; i < nums.length; i++) {
    // save target number to variable, easier to read
    let target = sum - nums[i];

    // if the object has a key of the target number
    // return its index (the value) and current index of nums
    if (obj.hasOwnProperty(target)) {
      return [obj[target], i];
    }

    // otherwise, create key value pair of the current number and its index
    obj[nums[i]] = i;
  }
  return [];
};

Thanks for tuning in, and I'll catch you next week!

Breaking Down DSAs: Valid Anagram

Claire Muller — Sun, 28 Jul 2019 21:36:33 +0000

Since graduating from the Flatiron School two months ago, I've been hard at work learning all I can about data structures and algorithms in preparation for the dreaded technical interview. I found a great collection on LeetCode of the top interview questions and have been slowly making my way through them.

Anybody who's done these kinds of coding challenges knows that there are always multiple approaches and solutions with varying runtimes. I thought it would be helpful to me (and maybe someone else) if I talked through my different solutions to one of the first problems I did, and what I learned along the way. So today I'll be going through a classic question: valid anagram.

The problem is this: given two strings, s and t, write a function to determine if t is an anagram of s. For example, if s = “anagram” and t = “nagaram”, return true. I'll be using JavaScript.

My immediate thought was that if the strings' lengths aren't the same, then there's no way they can be anagrams, and thus we can quickly return false.

if (s.length != t.length) {
  return false;
};

Obviously, two strings can be the same length but contain different letters, so our function continues. My next (naive) thought was to turn the strings into arrays and sort them.

s = s.split('').sort();
t = t.split('').sort();

Then I could easily compare each letter by iterating through one array and checking it against the other. If the letters aren't the same, return false.

for (let i = 0; i < s.length; i++) {
  if (s[i] != t[i]) {
    return false;
  }
}

If every letter passes this test, then the two strings are confirmed to be anagrams and we can return true! After submitting my solution and feeling pretty smart, LeetCode decided to crush my spirit by telling me that my solution's runtime only beat 47% of other JavaScript submissions.

The great thing about LeetCode is that you see other people's solutions, and thus I fell down a rabbit hole. I discovered what some might call a 'sick one liner' that was similar to what my solution was doing.

return s.split('').sort().join('') == t.split('').sort().join('');

From this solution I learned that my final step of comparing the two arrays using a for loop could be made easier by simply turning the sorted arrays back into strings using .join(). This is because strings can be compared using an equality operator while arrays cannot.

['wow'] == ['wow'];
// returns false;

'wow' == 'wow';
// returns true;

Further research led me to learn quite a bit about optimizing my code's runtime. I learned that using .sort(), while quick and easy to type, is pretty inefficient under the hood. Additionally, in a technical interview, you likely won't be able to use a method that does so much for you.

I then learned a very important lesson about writing efficient functions: objects are king. Objects, or dictionaries in other programming languages, have a constant lookup time, O(1), and thus can be very helpful in optimizing code.

So I set out to try solving this problem again using an object. I determined that I could iterate through one of the strings, using the object to keep track of the number of times each letter appeared. So given the string 'anagram', the object would become:

count = {a: 3, n: 1, g: 1, r: 1, m: 1}

Then I can iterate through the other string, checking first that the letter appears in the object, and if it does, subtracting one from its value. Here's what that looked like:

// create empty object
let count = {};

// iterate through one string, counting letters
for (let i = 0; i < s.length; i++) {
  count[s[i]] = (count[s[i]] || 0) + 1
};

// iterate through other string, checking the object has letter key
for (let i = 0; i < t.length; i++) {
  if (!count[t[i]]) {
    return false
  } else {
    // if letter is in object, subtract count
    count[t[i]] -= 1
  }
}

My solution worked and was faster than 95% of other JavaScript submissions! But there was one final thing I wanted to see if I could refactor. I knew there were other potentially cleaner ways to write my for loops so I did some digging and discovered for...of. I refactored my two for loops and the result was a lot less typing and clearer code!

// original for loop, iterating over the string, checking the object for each letter
for (let i = 0; i < s.length; i++) {
  count[s[i]] = (count[s[i]] || 0) + 1
};

// same loop using for...of syntax
for (letter of s) {
  count[letter] = (count[letter] || 0) + 1
}

I should note that for..of and the similar for...in are newer to JavaScript and thus aren't fully supported everywhere. But for my purposes, it wasn't a problem. So my final function looked like this:

var isAnagram = function(s, t) {
  if (s.length != t.length) {
    return false;
  };

  let count = {};

  for (letter of s) {
    count[letter] = (count[letter] || 0) + 1;
  }

  for (letter of t) {
    if (!count[letter]) {
      return false;
    } else {
      count[letter] -= 1;
    }
  }
  return true;
};

And that's all folks! I had a great time refactoring and learned a lot along the way. Catch you next week!

Tips for Perfecting Your Online Presence

Claire Muller — Mon, 13 May 2019 18:56:52 +0000

As I start my last three weeks at the Flatiron School in Seattle, the pressure of starting the job search is mounting. Having never applied for technical roles before, I’ve been asking anyone and everyone for their advice and any tips they have to make the search smoother. The number one thing I hear is that your online presence should be immaculate. So I thought for my blog post I would gather up the best advice I’ve received on this topic!

Private or Professional?

The quickest way to assess your online presence is to simply Google your name, because recruiters and hiring managers surely will. If you have a fairly common name, try adding your location to the search for better results. Any social media accounts you have should either be private or otherwise display general professionalism. When in doubt, go private.

Facebook and Instagram are good examples of accounts you might want to make private; you shouldn’t need to worry about every post coming across as unprofessional. Twitter is a bit of a grey area; lots of developers use it as part of their brand, as it’s an easy way to connect with companies and keep up to date with trends in tech. Make the decision that feels right for you, or consider creating a separate private account solely for following your friends.

Clean It Up

Specific to developers, a solid GitHub profile is key, as it is the main place that hiring managers will look. Your profile should have a clear picture, location, and a link to your personal website or blog (if you don’t have either, read on). Take a few minutes to pin your favorite or most impressive projects to your profile. These should all have a clear name, description, and README. Bonus points for images or gifs of the project in action.

LinkedIn is another important tool that recruiters will absolutely look at. Make sure everything is up to date, follow everyone you know and ask them to endorse your skills. There are tons of things you can add to your LinkedIn: links to projects, images of said projects, links to your blog or personal site, recommendations, and other achievements. The more robust your profile, the better you look to hiring managers. Tons of people get jobs through LinkedIn!

Set Up a Personal Site

Finally, if you don’t have a blog or personal website, get on it! It’s probably obvious, but I like dev.to as a blogging platform mainly because it’s specific to developers. There’s a wonderful community here and most people are supportive and welcoming. I’ve gotten some great feedback and connections with just a few blog posts!

A personal website is definitely a bigger endeavor, but having your own dedicated space on the internet will set you apart from those applicants that don’t. Your website can be a one-stop shop for all of the information you want a hiring manager to see: your resume, links, and project walkthroughs, all laid out how you want. For quick and easy set up, I like Squarespace, but there are plenty of other options out there.

You should absolutely buy a domain name that’s your first and last name, or some variation. If yourname.com is taken, try .me or .io. I bought my domain name, clairemuller.me (still working on it) through Squarespace for $20; after paying for this and hosting, the total cost was around $140. This might be a bit much for some people, but I think it’s a worthwhile investment that will pay off in the long run.

Conclusion

I hope these tips help you get ready for your job search, and feel free to comment with any tips you might have :) Happy coding!

4 Things I Learned From Building My First Site Solo

Claire Muller — Wed, 24 Apr 2019 20:34:28 +0000

Last week me and my fellow cohort mates at Flatiron School Seattle finished our module 3 projects; the assignment was to build a single-page application using vanilla Javascript and a Ruby on Rails backend. The rest was pretty much up to us, and I decided to make Jeoparody! This was the first website I built all by myself, and I learned a lot from it. So for my blog post I thought it would be helpful to write about the top things I learned.

CSS is weird

Going into this project, I felt fairly confident in my CSS skills. I’d worked on the Codecademy CSS Course and tinkered around in the console, so I thought it was pretty straightforward. When you don’t know what you don’t know…

My biggest struggle was figuring out how to vertically center text inside a div. ‘Why is this so hard?’ I asked myself after spending at least an hour adjusting the padding, margin, height and width. I finally discovered that simply wrapping the text in a p tag will do the trick! Unless...the text is longer and wraps to become multi-line. Still haven’t figured this one out.

Seed smart

While we’re on the topic of things I thought I had down pat: seeding my database. I found this awesome API, jService, that has every clue and category from every season of Jeopardy. That’s roughly 185,000 clues! I was pumped! I set up my Clue and Category models, figured out the best way to iterate through each page of the API, and the seeding began.

Fifteen minutes in, seeding failed! I quickly learned that one shouldn’t assume an API with 100,000+ entries is perfect. Tons of clues were duplicated, there were empty strings, missing values, you name it. After a lot of trial and error, the solution was to create two if statements that check each clue before it’s added to the database. The first one makes sure that the clue actually has the keys I want: question, answer, and category. The second if statement ensures that the values aren’t just empty strings.

clues.each do |clue|
  if clue.key?("question") && clue.key?("answer") && clue.key?("category")
    if !clue["question"].empty? && !clue["answer"].empty? && !clue["category"]["title"].empty?
      create_clue(clue)
    end
  end
end

Event listeners are picky

I haven’t had a lot of experience using event listeners, but they’re obviously an important thing to master. The first one that I implemented on my website was pretty straightforward. When a user first comes to the page, they put in their username and click the submit button. The event listener hears the ‘click’ and does its thing:

document.getElementById('submit').addEventListener("click", function(e){
  e.preventDefault();
  username = document.getElementById('username').value.toLowerCase();
  findUser(username);
})

There was no need to ‘remove’ this event listener because the div that it’s inside is hidden once the user logs in. Easy! The next event listener I used was for each of the clue divs. I had figured out how to remove the dollar amount from the div once a user had clicked it, but the event listener remained. I tried a few things and eventually asked for some help. My instructor gave me the very simple solution of simply adding a class of ‘clicked’ to a clue div that had been clicked. This allowed me to write the following inside the event listener:

if (clueDiv.classList.contains('clicked')) {
  return;
}

So once again, the event listener still exists on each clue div, but if a user clicks on one that they’ve already clicked on, it will simply return. Easy! My final event listener is the one that gave me the most trouble. Once a user has clicked on a clue, a div appears that asks if they got the question right or wrong.

I added an event listener that listens for a keydown of ‘Y’ or ‘N’ and went on my merry way. I soon realized that a user could continue to press ‘Y’ long after they’d finished the clue, and their score could increase forever! Thus, I finally had to tackle removing an event listener. After much trial and error, I discovered that removeEventListener is picky. Until now, I had been writing the whole function inside of the event listener, instead of referencing a separate function. This doesn’t fly when you try to remove the listener! In short, this was the only solution:

document.body.addEventListener("keydown", yesOrNo);
document.body.removeEventListener("keydown", yesOrNo);

Comments are necessary

I’ve always been pretty good about writing comments in my code, but it wasn’t until I started this project that I realized just how necessary they are. After I had my backend all set up, I wrote that first fetch request and it began...I was in the zone.

When I’m in the zone, coding my little heart away, it’s easy to forget to write a quick comment to help out my future self. But it’s so important! Because even if I think I know exactly what all my code is doing, I’ll eventually be going to sleep. And the next day, when I’m reading my code, I have no idea what’s going on. So don’t forget to leave yourself some notes to save future you from future headaches.

Conclusion

To conclude, I learned a lot from building my first website. If you’re new to coding, I would highly recommend building a single-page application. It’s great practice and helped solidify my knowledge of HTML, CSS and Javascript. Happy coding!

What is a Gem? Part 2

Claire Muller — Mon, 01 Apr 2019 23:28:43 +0000

Welcome back to my series on gems in Ruby! Last time I went back to the basics, and learned that a gem is Ruby's version of a package, which is simply a collection of files. Gems are frequently used to add functionality to a Ruby application or the CLI. RubyGems is the package manager for Ruby - there's currently 10,023 gems to choose from!

Gem Structure

A gem’s structure should look fairly familiar; most come with lib, test/spec, and bin directories, as well as a README, Rakefile, and gemspec. Here’s a tree breakdown of the gem tux:

lib

The lib directory contains all of the code that makes up the program. Standard practice is to create a file with the same name as the gem just inside the lib directory. This file is considered the ‘root’ file, and contains the main module for the program. This is the file that is loaded when you ‘require’ the gem.

Since this root file can easily get crowded, it’s common to create a directory inside lib, also with the same name as the gem. This folder will store all other files related to the module, and will need to be required at the top of the root file.

test/spec & bin

The test or spec directory is pretty straightforward, it stores all the test files! A marker of a good gem is the inclusion of these files; other developers will trust your code more if it has solid tests. With this we need a Rakefile, which allows us to run ‘rake test’ or simply ‘rake’ to run the test suite. The bin directory contains an executable file that’s loaded into a user’s PATH; the standard is to give this file the same name as the gem.

Gemspec

The .gemspec file contains all the information about the gem, including its name, version, files, author(s), and a brief summary. While these fields are required, a gem creator can choose to add additional information, like a contact email, license(s), required ruby version and other metadata.

Useful Commands

Here are a few commands that I found useful in my learning:

gem install <gem name>

Does what it says on the tin, installs the gem! i can be used as an alias for install.

gem list

Shows every gem that is installed locally, with their versions.

gem update

Also pretty straightforward! If you run this command without a specific gem name, it will update all your gems to the newest version.

gem cleanup

This one's great if you're a little OCD like me. It removes all but the latest version of each gem, unless that version is required elsewhere to meet a dependency. You can also run this command on specific gems.

gem environment

This command gives you some useful information, like your RubyGems and ruby versions, as well as where gems are installed on your computer. env can be used as an alias for environment.

Conclusion

To summarize what I’ve learned about gems: they’re essentially bundles of code that can improve your projects by adding functionality or cool features. There are a ton of helpful gems out there, and RubyGems is definitely the best resource. Thanks for reading!

What is a Gem? Part 1

Claire Muller — Tue, 19 Mar 2019 16:03:20 +0000

Ruby gems, like a lot of things in ruby, can seem pretty magical at times. How is it possible that I can type ‘gem install rails’ into my terminal and be able to create a web application in a matter of minutes? What is this sorcery? I’m on a mission to find out!

Back to the Basics

To really understand a gem, we have to take a few steps back. Basically every aspect of computing involves files; a single file can contain a little or a lot of information. For us to make programs and do cool stuff, files have to be used together. It can quickly get very confusing to keep track of what every file is doing. Enter: packages. A package is simply a collection of files and metadata (data that describes other data).

Gems

In Ruby, these packages are called gems. Gems contain code, documentation, and a gemspec. One of the most widely used gems is bundler, which is able to look in your Gemfile and download the correct version you need for your program. Another popular gem, rails, is an entire web application framework that makes building web apps quick and easy.

Package Management

Just like files, packages can get messy to deal with. A package manager, as the name implies, is software that manages these packages for you. A great example of a package manager that we’ve all used is an app store. A user can easily search for, install, or delete an app without having to do the dirty work of checking dependencies or manually installing each file within the package. Everything is handled for you, so you can get to the good stuff! With the release of Ruby 1.9 in late 2007, the package manager RubyGems became Ruby’s default package manager.

Conclusion

There is a lot more to be said about gems! For my next post, I’ll dive deeper into what makes up a gem, including the structure and gemspec file. But to summarize for now: gems are packages used in ruby to make programming easier for us. Catch you next time!

Refactoring My Old Ruby Code

Claire Muller — Mon, 18 Mar 2019 15:54:09 +0000

For my first blog post I thought it would be fun to look back and refactor some code I wrote when I first started learning Ruby. It’s from a lesson that any Flatiron School student will remember well: Hashketball.

First, you’re given a bunch of information about two basketball teams and told to build a nested hash. Then, you’re instructed to write methods that return certain information about a player or team. For example: player_numbers takes in an argument of a team name and returns an array of the jersey numbers for that team.

At the time, this lesson was really hard for me. I’d never worked with such a big nested hash before and was pretty new to the idea. You’re instructed to use .each and binding.pry to get comfortable with iteration. This was great at the time, as it helped me learn what to expect from iteration and I got really comfortable using binding.pry.

There are seven methods to write, and my original code came out to 128 lines, with tons of repetition and if statements. Now that I’m a few months into learning Ruby, I know there are much better, more efficient ways to write this code. So I’m going to take my knowledge of helper methods to shorten it!

The first thing I want to do is create some helper methods to make everything easier on myself. My previous code had me iterating through the game hash, then through that data, then through that data… but now I know the programming rule DRY, don’t repeat yourself.

I’m going to write a method, all_players, which simply takes the home team’s players and the away team’s players and merges them into one.

def all_players
  game_hash[:home][:players].merge(game_hash[:away][:players])
end

Now I can access all of the players and their stats in one method, no more repetitive iteration. I’m going to use this method to refactor the player_stats method. This one takes an argument of a player’s name and returns only their stats.

def player_stats(name)
  all_players[name.to_sym]
end

This method is part of the test but is in itself a helper method. I can use it to simplify num_points_scored and shoe_size, making them much easier to read. They both take an argument of a player’s name and return one of their stats.

def num_points_scored(name)
  player_stats(name)[:points]
end

def shoe_size(name)
  player_stats(name)[:shoe]
end

How beautiful! How clean! Next up we have some methods that take an argument of a team name, so I’ll create two more helpers for this. One that returns both team’s data, and another that takes an argument of a team’s name and returns only its data.

def all_teams
  game_hash.values
end

def find_team(team_name)
  all_teams.find { |team| team[:team_name] == team_name }
end

Wonderful, now I can refactor the team_names method. This one simply returns both team’s names, so I can use my all_teams helper method.

def team_names
  all_teams.map { |team| team[:team_name] }
end

So satisfying! Now I can use my other helper, find_team to shorten both team_colors and player_numbers.

def team_colors(team_name)
  find_team(team_name)[:colors]
end

def player_numbers(team_name)
  find_team(team_name)[:players].map {|name, stats| stats[:number]}
end

Finally we have the monster method big_shoe_rebounds, which is just painful to look at:

def big_shoe_rebounds
  shoe_sizes_w_names = {}
  game_hash.each do |location, team_data|
    team_data.each do |attribute, data|
      if attribute == :players
        data.each do |name, stats|
          stats.each do |k, v|
            if k == :shoe
              shoe_sizes_w_names[name] = v
            end
          end
        end
      end
    end
  end
  player_w_big_shoes = shoe_sizes_w_names.key(shoe_sizes_w_names.values.max)
  game_hash.each do |location, team_data|
    team_data.each do |attribute, data|
      if attribute == :players
        data.each do |name, stats|
          if name == player_w_big_shoes
            stats.each do |k, v|
              if k == :rebounds
                return v.to_i
              end
            end
          end
        end
      end
    end
  end
end

Yikes. That’s 34 lines for one method! The big problem here is that this method is doing two separate things:

finding the player with the biggest shoe size
finding that player’s number of rebounds

There’s a philosophy in programming: a method should do one thing, and do it well. With this in mind, I decided to first create a method that finds the player with the biggest shoe size.

def player_w_biggest_feet
  all_players.max_by { |name, stats| stats[:shoe] }
end

Now I can use this method to find their rebounds, and pass the final test. However, I could also use it to find any other data about the player with the biggest feet, if I ever wanted to.

def big_shoe_rebounds
  player_w_biggest_feet[1][:rebounds]
end

And that’s it! In the end, I took my code from 128 lines down to 43, and every method is only 3 lines. The result is the same, but now the code is much easier to read and understand.

To summarize, I learned a lot about the basics of Ruby the first time I did this lesson. Knowing how .each works is really important and builds a great foundation for understanding more abstract methods like .map and .find. Refactoring and working with it a second time around was a lot more fun than I was expecting! It can be a little cringe-inducing to look back at your early code, but a lot can be learned from it. Thanks for reading!