VCS Week Five — Active Record, Forms, and Associations
I’m finding myself struggling to write down the things that I learned this week in comparison to any other week that I’ve written about. It’s not to say that I have less of a grasp of what I learned this week than any other, but I think it may very well be the content of the things I learned.
This week was different, it seems, because we focused on singular functionalities as opposed to broad concepts. Whereas before it felt like I was talking about large concepts and the practical implications, this week felt like I learned a great deal about a couple things. Specifically, I learned a great deal about forms, associations, and how that all connects with Active Record. The week began in SQL, finishing up what we were learning last week (covering join queries, aggregate functions, and sub-queries), and then it quickly moved into Active Record, a Rails gem. Basically, the first half of the week was dedicated to Active Record, SQL, and putting the two together. Being able to send a SQL query in Rails is like taking bits and pieces of database language and smushing it into Active Record talk, which at first seemed daunting, but now feels, well, still daunting but less awkward.
From there, we moved into forms and all the helpers that comes with Rails. So instead of writing our forms in raw HTML, we learned and wrote our forms as form_tags or form_fors. I’ve never really enjoyed writing out forms in HTML (with all the inputs and whatnot) so I found form_fors great. Rails again to the rescue.
And then, associations. The idea of associations is cool, I think. It’s very real-world, if that means anything. By that, I mean, the whole idea is that we create objects, and objects associate, or relate, with other objects. So you can create a User object, and that object will have associations with other objects, like a Post object, or a House object. The whole point is that objects are not isolated from one another, and therefore there needs to be a clear and effective way of relating them to one another. In Rails, it seems the key is to make them have/belong to one another. So a User has many Posts, and a Post belongs to a User. The tricky bit is when you want to rename these associations, or how do you make something associate with another instance of its same model (like a User wanting to associate with a different User). Things like that. This stuff is still fresh in my head (I was just going through the lessons a couple hours ago) so it still hasn’t stuck yet, but it’s real interesting stuff. Another learnful week at VCS and another one ahead!
And now, to an algorithm question.
Given an unsorted array of numbers, write a function that returns true if the array consists of only consecutive numbers.
Here are some examples to work with:
[1,2,4,5,3] => true, array has consecutive numbers from 1 to 5.
[1,4,3,3,5,2] => false, 3 and 3 are not consecutive.
[89,91,90] => true, array has consecutive numbers from 89 to 91
[89,91,92] => false, I think you get it by now.
And some answers.
The naive solution to this problem, in Ruby at least, would be to sort the array and see if every number increments by one:
def consecutive?(arr)
sorted_arr = arr.sort
sorted_arr.each_with_index do |element, index|
next if index == arr.length — 1
return false unless sorted_arr[index+1] — element == 1
end
true
end
This solution solved the problem in O(nlogn) due to the sorting involved. A simpler solution in O(n) complexity is this one:
def consecutive?(arr)
arr.max — arr.min + 1 == arr.length &&
arr.length == arr.uniq.length
end
This solution runs on the basic premise that as long as all the elements in the array are distinct, if you subtract the minimum value from the maximum value and add one, if all elements are consecutive, this value will return the length of the array.