Participating in gSchool and my goals for 2013

I recently wrote a short set of goals that I wanted to accomplish to become a web developer. The first goal was to secure an internship, apprenticeship, or some type of program where I could fully immerse myself in learning how to become a valuable software developer. Well after a lot of research into different programs, coding challenges, and interviews, I can now happily check that off my list as I’ll be joining gSchool at the end of January 2013!!! gSchool is a 6 month-long training program created by Jumpstart Lab and Galvanize that aims to turn people like me into skilled web developers that can add real value to employers. The program will focus on learning Ruby on Rails as well as other web technologies such as HTML5, CSS, and JavaScript. If you’re not familiar with Jumpstart Lab, check them out. They have experience in training web developers and successfully created Hungry Academy  (a similar program) for LivingSocial last year. This is definitely going to be a life-changing experience for me, I’ll be living in Denver, CO for the next 6 months and working my ass off to learn as much as I can to become a productive web developer. With these new set of challenges 2013 will bring, there are a whole new set of goals that I’d like to accomplish by the end of this year. I decided to write some down.

1)  Become a web developer that can add real value to my employer

  • Be productive with Rails, HTML5, CSS, JS, PostgreSQL, MySQL, and Git.
  • Learn how to work in collaborative projects (Communicate ideas & problems effectively).
  • Actively participate in open-source projects.
  • Improve my problem solving skills by always looking for new & challenging problems to solve.
  • Learn how to read and write docs correctly.
  • Pair-program often.
  • Work for a company that excites me, that I can be proud of and want to evangelize about.

2)  Become an overall better communicator

  • Write more!
    • As you can tell from my blog posts, I suck at writing. The first paragraph of this post took me longer to write than I’d like to admit. Its a little hard for me to express my thoughts verbally and in writing. But just like anything in life, practice makes perfect!
  • Explain one thing I’ve learned verbally.
    • Once a week, I’d like to explain one thing I’ve learned verbally to someone as if I were speaking to a non-technical person. A friend suggested I do podcasts and submit them on my blog. Hmm… still thinking about it.

3) Establish meaningful and lasting relationships 

  •  2012 was a year of self-awareness and self-reflection, where I took a step back to look at who I am, what would make me happy, and who I want to be. 2013 will be a year of action! I want to surround myself with people who are smarter than I am, more ambitious, and harder working, so that I’ll constantly be pushed outside of my comfort zone and become better for yet. 

One of the things that excites me the most about gSchool are the people that I am going to meet and the relationships that will be built. To think that I will be spending most of my time with other like-minded individuals who are also willing to sacrifice 6 months of their lives to accomplish their goals is pretty awesome! I’m gonna kick this new year’s ass!

Tagged , , , , , , , , , , , , ,

The Locker Problem

I was recently given a puzzle to solve in Ruby called “The Locker Problem”. Hearing it for the first time kind of made me feel overwhelmed, but that’s what motivated me to try to solve it. After a lot of thinking, I’ve finally figured it out. The solution actually ended up being a lot simpler than I made it out to be in my head. Here’s the puzzle, as well as the solution and my thought process in solving it:

In front of you, there are 100 open gym lockers in a row.
You walk around the entire row 100 times. The first time,
you stop at each locker and close all the opened ones. The
second time around, you stop at each 2nd locker and open
the ones that are closed. The third time around, you stop at each
3rd locker and close the ones that are opened and open the ones
that are closed. You continue this pattern until you’ve done it a
total of 100 times.
At the end, which lockers are opened and which are closed?

Did reading that puzzle make your head hurt? This is actually pretty simple to solve after breaking it down piece by piece. First, I’ll show you my solution:

Ruby

As you can see, it doesn’t take a lot of code to solve this puzzle but there’s a lot going on. Let’s break it down.

First we create an array representing 100 opened lockers (true == open). For our loop that will represent walking around the lockers 100 times, we use 'i' as a placeholder and assign 1 to it. This will represent the first time walking around the lockers, stopping at each locker. Therefore, 'i' will represent the rounds we take around the lockers. At first glance, it may seem to you that we’re only walking around the lockers 99 times but remember that we’re already starting at the first round (i = 1) and therefore adding 1 to 'i' 99 more times. Totaling 100 times that we’ll walk around the lockers.

(0..open_lockers.size - 1) is a range from 0-99 that represents the index positions of all 100 lockers in our array. .step is a method that iterates through a range and passes every nth element to the supplied block. For example, lets say we’re walking around the lockers for the 2nd time. This means that 2 will be supplied to the .step method as a parameter. .step will then start at 0 and pass each 2nd element to the block, including 0. (0, 2, 4, 6, 8,…). If this made you notice a potential problem with properly identifying the lockers, then you’re doing great (I figured it out the hard way). The problem is that if we’re trying to identify every 2nd locker, the 0, 2, 4, 6, 8,… index positions are actually going to identify the 1st, 3rd, 5th, 7th, 9th,… lockers. This is why we subtract 1 from the index positions to properly identify the correct locker that we’re trying to access within the array. So in actuality, the index positions we’ll be accessing are [-1, 1, 3, 5, 7,…]. This will properly identify every 2nd locker (100th, 2nd, 4th, 6th, 8th,…98th). Now we can be certain that all 100 times that we walk around the lockers, we’ll be closing or opening the correct ones.

We then use a boolean expression (or flow control) that represents closing a locker if it is open, or opening a locker if it is closed.

Lastly, we pass the each_with_index method to the open_lockers array that iterates
through the array, grabbing each locker and it’s index position. We then use string interpolation to add 1 to the index position to properly display the locker onto the screen. i.e. Locker #1 instead of Locker #0 (that wouldn’t make much sense). We also use string interpolation to display “Opened” onto the screen if the locker is ‘true’ or “Closed” if ‘false’.

Tagged , , , , ,

Ruby Blocks, Procs, and Lambdas

I’ve always had a hard time understanding the differences between a block, a proc, and a lambda and an even harder time understanding when to use which. A friend of mine recommended reading a simple tutorial cleverly named “Understanding Ruby Blocks, Procs and Lambdas” written by Robert Sosinski. So far, this has been the most straightforward explanation of closures in Ruby that I have found, it doesn’t get too complicated and Robert provides detailed examples of the differences between these different types of closures in Ruby. Here are some of my takeaways:

  1. Block: A block is essentially a proc but cannot be saved as an object or assigned to a variable and is therefore a “one time” use solution. Also, a block itself cannot be passed to a method as an argument.
  2. Proc: A proc is a block that can be saved as an object, stored in a variable, and passed to a method as an argument. Since procs are objects, they can be reused in your code over and over again. Besides this obvious benefit, the real benefit comes when you need to pass more than one block to a method. Because procs are objects themselves, you can pass as many procs as you want as method arguments.
  3. Lambda: A lambda is like another way of writing methods, but anonymously. When writing code or going through the tutorial above, you’ll notice that using a lambda looks almost exactly like using a proc; at first it will seem like there isn’t any difference at all. This is why it is important to remember the conceptual differences between lambdas and procs; a lambda is like an anonymous method and a proc is a procudure, or a drop in code snippet, as Robert describes them. If this still doesn’t help you understand what a lambda is or what the differences are between a proc, don’t worry, it didn’t help me much either. Robert Sosinski provided some great examples describing the subtle differences though. Here’s what I took away from it all:
      • Because lambdas are like methods, they check the number of arguments passed (unlike procs) and return an ArgumentError in the case that the wrong number of arguments are passed. Procs on the other hand will simply set any extra arguments passed to nil.
      • A lambda will return it’s value to the method and let the method continue to process the rest of the code. However, if you instead had a proc within that same method, the proc will stop processing the rest of the method once it hits it’s return keyword. Here’s the code snippet from Robert Sosinski’s tutorial:

Ruby Procs & Lambdas

        • Lastly, because a lambda acts like a method, you can pass a lambda containing a return keyword as an argument to another method. A proc containing a return keyword however, cannot be passed as a method argument.

Conclusion: When to use

  • Block: I’ve concluded from reading this tutorial that a block should be used over a proc when you simply want to break an object down and manipulate those elements in some sort of way.
  • Proc: A proc should be used over a block when you want to reuse a block of code multiple times and when you have a method that needs to take more than one block as arguments.
  • Lambda: I’ve concluded that the benefits of using a lambda over a proc (argument checking and return values) are minor and what you use will depend on your preference and what makes most sense to you.

What are your thoughts?

Tagged , , , , , ,

My Goals to Become a Web Developer

I’ve been trying to learn how to code by myself since March 2012 and though I now know a hell of a lot more than I did then, I still feel like I don’t know much at all. It isn’t easy learning web development by yourself, especially when you don’t come from a programming background. I’ve gone through almost every tutorial you can think of and I frequently find myself thinking “Damn, it would sure be nice to have someone next to me or that I could e-mail or call whenever I get stuck learning something”. This usually happens when spending hours scouring through StackOverflow and Google when stuck on how to do something or learning a certain concept that could easily be explained in a matter of minutes by someone who’s been down the same road before. I, however, will not let this stop me or slow me down. Now that I’ve decided to become a software developer, there is no safe place code can hide in. I will find it and I will conquer it! I therefore wrote a small list of goals I will accomplish to make this happen, as well as a list of things I need to do to get there. Please feel free to add to this in the comments section  and provide any advice you may have. Any changes, additions, or advice will be greatly appreciated!

What do I want to accomplish?

  1. Get an internship or Apprenticeship with a web developer to learn, grow, and to ultimately get a job as a developer.
  2. Get a mentor that’ll lead me in the right direction, provide constructive criticism, and teach me the stuff you can’t learn through books/tutorials.
  3. Network and meet new interesting and smart people.

What I think I’ll have to do:

  1. Blog *consistently* about what I’m learning (maybe once/twice a week), not sporadically like I’m currently doing.
  2. Write to other people learning to code, as well as experienced developers. Also, try to help other people learning to code if they need help with things I’ve already learned (great learning opportunity).

What I know I’ll have to do:

  1. Reach out to decision makers in tech companies to explain who I am and *why* I’m doing this, the goals I’m trying to accomplish, and the value proposition of hiring me as an apprentice/intern.
  2. Continue to work my ass off everyday learning software development.
Tagged , , , , , , , ,

The cancellation of BritRuby and Why I love the Ruby community

While trolling through the internet, I’ve noticed some people stating that gender and race are real issues in the Ruby community and that the recent cancellation of the British Ruby Conference reflects poorly on the entire Ruby community as a whole. As a young, male, Hispanic American, I can tell you that this is complete B.S. As someone new to the Ruby community, and programming for that matter, you could say I have a pretty steep learning curve to overcome. And though I work hard everyday to learn Ruby, I wouldn’t have gotten as far as I am if it weren’t for the great people in this community. I’ve never met such smart and passionate people who genuinely love what they do and truly enjoy teaching others what they know. In the last few months, I’ve made friends with people in the Ruby community who regularly push me to get better and learn new things, folks who won’t hesitate to help me understand a new concept I may be struggling with. The point I’m trying to make is that as a non-white male new to the Ruby community, I have never had any problems with racism or with narrow-minded individuals such as those who state that the Ruby community has problems with race. The Ruby community is a supportive one, filled with great people who love learning and teaching others what they know. This is the Ruby community that I know and love.

Tagged , , , ,

What I learned today: Not All Methods Are Created Equal

Today I wrote a script in Ruby that, among other things, receives a text file as input and calculates the word count. One of the things I love about Ruby is that there’s always more than one method for doing things. But what I learned today is, not all methods are created equal. Let’s say we wanted to count the words in the following text:

What an excellent example of the power of dress, young Oliver
Twist was! Wrapped in the blanket which had hitherto formed his
only covering, he might have been the child of a nobleman or a
beggar; it would have been hard for the haughtiest stranger to
have assigned him his proper station in society. But now that he
was enveloped in the old calico robes which had grown yellow in
the same service, he was badged and ticketed, and fell into his
place at once–a parish child–the orphan of a workhouse–the
humble, half-starved drudge–to be cuffed and buffeted through
the world–despised by all, and pitied by none.

One way to accomplish this task is by using the scan method and passing the regular expression /\w+/ as an argument. scan iterates over a string and looks for a certain pattern passed to it as an argument, then outputs any matches into an array. So let’s say we store the Oliver Twist text above in a variable named text, and use the scan method to search for any word character using regular expressions, then ask to return the number of words found. Here’s how that would look:

Ruby scan method

Here, the scan method searched for all alphanumeric characters then returned the results into an array. The length method returns the number of words found. In this case, 113 words.

Another method we can use to count how many words are stored in the text variable is to use the split method. When no arguments are passed to the split method, it will automatically split the string by whitespace and return the results in an array. Passing the length method to that result will also return the number of words stored in the text variable. This is what that would look like:

Ruby split method

The split method returned only 107 words. Do you know why this may be? The reason is that by passing the regular expression, /\w+/, as an argument, the scan method counted the hyphenated words as two words, when they should have only been counted as one. So it seems to me that using split can provide a more accurate method to determine word count.

What do you think? Do you agree that using the split method can provide a more accurate word count, or can you use regular expressions to achieve the same result? Leave a comment below, I’d love to hear your thoughts.

Tagged , , , ,

Tutorial: Event Manager – by JumpstartLab

Today I built a program in Ruby called Event Manager that takes a CSV file containing ACTUAL attendee data from a political conference and manipulates that data based on certain instructions. If you’re new to Ruby or programming for that matter, I highly recommend it. Among other things, you’ll learn how to work with the CSV library and how to access a web-based API. The data file contains attendee names, addresses, phone numbers, emails, and the date and time they registered for the event. Problem #1 to solve was removing a lot of junk (incorrect street addresses and phone numbers). Here I learned a lot about string manipulation techniques. Then I learned how to output the cleaned data to a new CSV file. The fun part started when accessing the Sunlight API from the Sunlight Foundation, here I learned how to create a method called rep_lookup that looks up legislator data for each attendee based on their zipcode. I also learned how to create a method that pulls an attendee’s name and address from the original CSV file and creates a custom form letter in HTML. Awesome! Lastly, I learned how to do some analysis. I created methods that determined which days of the week and hours of the day most people registered for the event. This can be useful when determining the best times to run ads for a future event. All in all, this is a great tutorial for those wanting to learn Ruby. Check out the source code on my Github and the tutorial here.

Tagged , , , , ,

What I learned today: The for iterator

I was playing around with some practice exercises in Ruby today when I came across this sample code:ruby rails

This defines a method called parks_per_city which takes in an array of hashes as an argument and maps a city to the number of parks located within that city. Example :

ruby

This is done by looking at the value associated with the us_city key – which will be some city, supplying that value to the city hash as a key, and setting the value equal to 1 if that city doesn’t already exist, or adding to the value ( the number of parks ) if a city already exists as a key within the hash.
What I had not seen before is the line before the do..end block:

for park_city in parks

Even though it becomes obvious what this code does by reading the 11 lines of code above, I decided to google it to understand HOW this works. After researching different resources online, I found myself asking “Is it a loop method? Is it an iterator method? Is it both?”. According to this great blog called Snorks, it is a loop method that acts like an iterator without actually having to take a block. Here’s an example taken directly from the Snorks blog post:

ruby

However, when looking at the first screen-shot above, we see that the for loop is passed a do..end block. Then I read Chris Pines’ “Learn to Program” book – which I highly recommend if you’re a beginner like myself trying to learn Ruby and Rails. In chapter 7, he mentions that iterators are always followed by blocks such as do..end or {...}. He also goes on to mention that these blocks are only used with iterators. Hmm… So which is it, an iterator or a loop? I’m sure this probably won’t bother most people, but not being able to figure this out is bugging the hell out of me. So to better understand how this code works and hoping it would provide some insight on whether it’s a loop or an iterator, I decided to re-write the code using an iterator method I’m already familiar with and testing the parks_per_city method to see if it works. I used the each iterator. Here’s the code I wrote: ruby

As you can see, by replacing: for park_city in parks do... with parks.each do |park_city|... I was able to accomplish the same task. This each iterator method is pretty straight forward. It grabs each hash in the parks array and assigns it to the park_city variable as a hash. It then checks to see if the us_city in question is supplied to the city hash as a key. If not, then it’ll include the key to the hash and set the value equal to 1. If the city hash already has the us_city as a key then, it will add to the number of parks in that city.

I therefore can’t help but to conclude that:
for value in iterable do
...
end

in this context is an iterator method that executes whatever is in the block; just like:
iterable.each do |value|
...
end
.

Am I correct in my conclusion? What are your thoughts? Leave a comment below and let me know what you think!

Tagged , , , , ,

Ruby on Rails Tutorial: Validations

I’m currently going through the Ruby on Rails Tutorial by Michael Hartl and learned something important about the uniqueness validation argument on the validates method. First of all, the validates method is provided by Active Record and allows you to impose constraints on model attributes. For example, let’s say you have a User model and one of it’s attributes is a user’s email address. Well the uniqueness validation argument enforces that every email submitted to the database must be unique. It’s obvious why this is an important constraint to enforce when creating a web app. But there’s a problem; If a user mistakenly submits a sign-up form twice, Rails will still create two different users with the same attributes despite the uniqueness validation. What I learned is that in order to solve this you must also enforce uniqueness at the database level by creating a database index on the email column and require that the index be unique.  Going through the tutorial, I first generated a migration to add structure to the existing User model:

I then opened up the migration file and included the add_index method to add an index on the email column of the users table and enforced uniqueness:

Don’t forget to run the migration when you’re done:

 

 

There’s still one more step; we have to make sure that the email attribute gets saved into the database as all lowercase in order for this to work. This is because not all database adapters use case-sensitive indices. So the way to do this is by writing the before_save callback method in the User model and pass a block that sets the user’s email to all downcase using the downcase string method:

 

Now we can rest assured that the uniqueness validation will enforce that each user has a unique email address!

Tagged , , , ,

What I learned today: REST

Rails implements the REST architecture when creating web apps. This means that many components of a Rails application (ie. blog posts and/or users) are modeled as resources that follow CRUD operations that correspond to the four fundamental HTTP request methods. CRUD stands for Create, Read, Update, and Destroy. These are the major functions that are implemented in relational database applications that allow for resources (such as blog posts) to be, well, created, read, updated, and deleted. Now the four fundamental HTTP request methods are GET, POST, PUT, and DELETE. These request methods, or verbs, indicate the desired operation (CRUD) to be performed on resources. Here’s a table illustrating these operations and their corresponding HTTP requests.

REST

 

Tagged , , , ,
Follow

Get every new post delivered to your Inbox.

Join 42 other followers

%d bloggers like this: