Pen_to_paper > Code_to_editor.

Throughout my journey to become a software engineer, I’ve been blessed to have quite a few friends in this field to call upon when the going gets tough, and, oh man, does it ever. As a novice in this field, I get excited about solving problems, and I get even more excited when my solutions work. On the flip slide, when my solutions are not working as intended, I am not so happy about them.

After throwing a lot of code at my solution and finding them futile, I reach out to one of my friends or a fellow student. When reaching out to my friends, one thing became obvious to me — regardless of their working language, they are able to help me find a solution. Which lead me to the discovery: software engineering is not about how much code you can memorize, but about being able to think about a problem logically.

As an example of logical thinking, lets look at one of the labs from the Flatiron School software engineering course. This lab caused a lot of frustrations for my cohort, but for an experienced engineer, it was a matter of finding the logic behind the problem.

Our deliverable: write a method that returns all the listing objects that are available for th entire span that is inputed.

def city_openings(start_date, end_date)
end

For the purpose of this exercise, we’re going to focus on the models and associations that are of interest to us.

A city has_many :neighborhoods
A city has_many :listings, through::neighborhoods
A listing belongs_to :neighborhood 
A listing has_many :reservations 
A reservation belongs_to :listing

Going back to our problem, we need to find the listings that are available for reservation between a start and end date specifified by a user. Before we write any code, let’s look at all the dates we’re working with for a possible reservation:

a = start_date 
b = end_date 
| = reservation checkin date (this date is already provided for us thorugh the reservation schema for when there is already a checkin established for a particular listing. 
| = reservation checkout date (just like the checkin date, this is another date provided through our reservation schema)

Now let’s look at all the possible scenarious we need to account for:

ab||
-- no reservation during start and end dates. listing is available during those dates. 
a|b|
-- end_date is interrupting an already reserved listing. listing is unavailable 
|ab|
-- start_date and end_date are interupting a reserved slot. listing is unavailable. 
|a|b
-- start_date is interupting a reserved slot. listing is unavailable. 
||ab
-- no reservation during start and end dates. listing is available. 

Listing out all the possible scenarious helped us tremendously. Based on our pseudochode, we can eliminate all the scenarious where the listing is unavailable. Which leaves us with this scenario ab||||ab. In plain english: The listing is only available if the start_date and end_date happen before or after the checkin and checkout dates. In ruby, this is how we can finally write it (there are many ways to do this so do what is most comfortable to you.)

in our app/models/city.rb class folder
def city_openings(start_date, end_date)
  available_listings = []
  self.listings.each do|listing|
     available = true
    listing.reservations.each do |reservation|
      if reservation.checkout <= start_date.to_date ||                     end_date.to_date <= reservation.checkin
      else 
         available = false 
      end
      end
      if available 
         available_listings << listing 
      end
    end
   end
end

Critical thinking and writing pseudocode is by no means simple or does it come naturally for most of us, however, what I’ve learned coming out of each session with a more senior software engineer is to put pen to paper and solve the problem before putting any code into your text editor.