Flatiron Coding Adventures

So got a fun interview question today. Didn’t actually end up solving it, but felt like it was a cool question that I wanted to write about. Here it is: 

“Write your own debounce function”

Before I jump into the solution, if you’re unfamiliar with what debouncing is as a concept, it’s essentially a way to prevent the over-invocation of any given function (I totally made the word over-invocation up, but I think it works here). 

For example, for a typeahead search, rather than making a call to get new search results upon every key stroke, debouncing is often used in order to limit the rate at which API calls are made to retrieve those results. E.g. if you type 5 letters in a matter of 2 seconds, we'd only call the API endpoint once when 2 seconds has passed from the last keystroke as opposed to five times.

So back to the question. I was given this function definition and an example of its usage as the following: 

const debounce = (fn, delay) => { }; const sayHi = () => { console.log('yo!'); }; const debouncedSayHi = debounce(sayHi, 100);

So what should debounce look like? At first glance, I knew in the back of my head this was going to involve a closure somehow... The first clue was the the return value of debounce was another function, which implies that a closure exists, whether there is state held outside of the function that gets used within the returned function or not.

Before we get started it might help to know that whenever you call setTimeout(), a reference to that specific timeout is returned. You can later cancel that specific timeout using that object that was returned, i.e.

const timeout = setTimeout(someFunction, 100) clearTimeout(timeout)

someFunction will never be invoked.

So what did the solution end up looking like? Check this out:

const debounce = (fn, delay) => { let timeout; return (...args) => { setTimeout(() => { clearTimeout(timeout); timeout = setTimeout(() => { fn(...args); }, delay); }, delay) } }; const sayHi = () => { console.log('yo!'); }; const debouncedSayHi = debounce(sayHi, 100);

You'll notice that we're constantly overriding our timeout variable declared in the closure scope of the debounced function that we're wrapping. Pretending that timeout's have ids for a second, lets look at what happens when you call the debouncedSayHi function four times:

debouncedSayHi(); // => adds a timeout with id = 1 debouncedSayHi(); // => removes timeout with id = 1 and adds one with id = 2 debouncedSayHi(); // => removes timeout with id = 2 and adds one with id = 3 debouncedSayHi(); // => removes timeout with id = 3 and adds one with id = 4

The magic lies in adding and removing timeouts using the closure scope variable, timeout. Keeping track of the timeout variable in the closure scope allows us to constantly remove the last timeout that was set and effectively restart our 100ms timer every time that we invoke the function again. This is the behavior we're looking for, since debouncing a function makes it so that function is called only once X seconds after the LAST call.

This is where I got tripped up.

In my mind I was thinking that we were trying to invoke sayHi only once after 100ms from the first invocation of debouncedSayhi().

This, is actually a concept called throttling, which is effectively limiting the number of times you can invoke a function. within a time-frame.

The funny thing is that both of my friendly interviewers warned me of this misconception before we started and I STILL fell for it! Sigh...

Oh, also, there's some interesting places to improve this function. If your debounced function uses the keyword this at all, you're kinda screwed depending on where you end up calling debounce(). For example, if defined within an object:

const sayAge = () => { console.log(`I am ${this.age}); } const cooper = { age: 22 sayAge: debounce(sayAge, 100) }

when we invoke cooper.sayAge(), you'll get:

I am undefined

It's cool that Cooper is trying hard to be artsy and unique by saying he's undefined---were definitely all our own unique lil snowflakes---but this isn't exactly the behavior that we want.

This is due to the fact that using the new arrow definition syntax () => {} actually automatically binds this to the location of where the function is defined, as opposed to where it is invoked. This means two things for us:

our debounce function actually needs to use the old function definition syntax to get the desired behavior we'd want (i.e. to bind to this where debounce is invoked)

We need to make sure to grab this within debounce and manually bind it via .apply to the passed in function fn when it gets called

Check it out:

const debounce = (fn, delay) => { let timeout; return function() { setTimeout(() => { const context = this; clearTimeout(timeout); timeout = setTimeout(() => { fn.apply(context, ...args); }, delay); }, delay) } };

Now when we invoke

cooper.sayAge()

we get

I am 22

Thanks for being a sport Coop!

Hello Tumblandia. I come with more tales of awkwardly answered technical interview questions! (And an attempt to regain some of the lost dignity from wrong answers via figuring out the solution after-the-fact)

So I went in to my first technical interview EVER with a company this weekend (I'll leave it up to you to guess which one... hint: check the title of this post), and, well, I have mixed feelings about how it went. I thought everyone I met at the company were super friendly and really understanding when I needed a little bit of a nudge to understand the problems they gave me. 

Anyway, I wanted to write a brief post about the very first whiteboarding problem they gave me because, well, three days after I'm still kicking myself for not getting it right away. 

Here it is, with the examples used for class and module names changed a bit:

Lets say you have a class Car, a module Engine and a class Vehicle from which Car inherits. In each one, you have a function 'run' which prints out different things. Check out the gist below. 

So what do you think myCar.run prints out? 

For some sad, sad reason, my knowledge on how to invoke module methods once they had been included in a class is fairly limited. I remembered from when I was learning Python that modules we're used primarily as method of name-spacing and preventing namespace pollution. In Ruby, modules are often used to add additional functionality to classes or instances of a class that don't semantically make a whole lot of sense being in the class--these often end up being things like utility methods. 

In any case, I started rambling about namespacing, which I could already read on my interviewers face was totally not the right direction to be going in, at which point I felt like making this face:

and calmly stating "I KNOW THE RUBIES."

After realizing behaving like this wouldn't really do me any good, I began to think back to the last time I had included a module or called a method from a module... I had remembered instantiating an instance of a class that was wrapped in a module in Sinatra by doing 

MyModule::MyClass.new

But I knew that this wasn't going to really help me. What my interviewer was asking me was really "Hey, how does the Ruby interpreter look up instance methods in Ruby classes?" 

Sadly, I failed to come up with a good answer. After coming home and experimenting with the code I put in the above gist, I was kicking myself after finding out how simple it was: 

The order in which Ruby looks for the instance methods of a class are the following: 

1. First it looks for direct instance methods that belong to a class. 

2. It then looks for the module methods that have been included in the class. 

3. Failing that, it climbs up to the immediate parent class and scans for the method there.

4. Not being able to find one in the parent class, it looks for methods in any module included in THAT class. 

This pattern continues until finally Ruby's BasicObject from which all objects inherit is reached. Such a simple, logical answer. Yet my brain failed to be of any help on that day. It is interesting to note that if the method lookup fails, Ruby will actually repeat the above process looking for a method called method_missing. This is basically a "catch" method that will be run whenever you Ruby class doesn't have the method that is being called. If it exists anywhere in the parent hierarchy or any module that has been included in the chain, it will be run. 

Also a quick note for those of you who need a refresher on the difference between include and extend: 

Include: the module's instance methods become instance methods on the class

Extend: the module's instance methods become class methods on the class

Well, it's been a while my fellow tumblizens. I thought I'd stop by to write a little post on my experience doing my first technical interview and the strange/interesting/sadistic challenges I encountered along the way.

So lets rewind to about three weeks ago. Picture a strangely dressed kid with a green complexion who's fiddling with a half-full bottle of 5 hour energy sitting across from you on the Q train. That's me, a nervous, nauseas wreck 20 minutes before my interview. 

Having heard plenty of horror stories about technical interviews before, I show up at my interview expecting to be taken to a fluorescently lit room with whiteboards covering every inch of available wall space, where there are three intense looking programmers with furrowed brows sitting at a long table. The moment I walk into the room, however, I'm greeted by the same guy I had a coffee with the first time I got introduced to the company, and led to two small artsy armchairs that sat in the middle of an open room where everyone was working. At this point, despite realizing my imagination had gotten the best of me, my adrenaline is through the roof. I still had no idea what to expect in terms of questions. 

The first interviewer sits down, asks me about my background and other questions that I'm used to being able to hit the ball back on. Then we start talking about the projects I've worked on at Flatiron: 

"So tell me about the last project, and some of the challenges you faced while working on it?"

"Why did you decide to use angular in your project?"

"So tell me a bit about your database schema. Why did you set it up like that?"

"Lets take a look at your Javascript"

The entire time I was answering these, in my head I couldn't stop asking: "Wait... are these the technical interview questions? When am I going to be handed a whiteboard marker and be asked an algorithm question? IS EVERYTHING I'VE BEEN TOLD UP TO THIS POINT A LIE?"

As it turns out, yes. Well, for this interview anyway. 

The technical interview actually ended up feeling a lot more like a casual conversation about frameworks and gems and libraries than a brutal gauntlet of algorithm questions. It was possibly the most relieving feeling in the world to have finished the conversation and realize that I wasn't going to end up having to touch a white board marker. Instead of feeling like I was taking the SAT again, I felt like I was just talking with a fellow coder about something I had been working on.

I knew I hadn't gotten off the hook that easy though. They still needed to test my coding ability somehow. What I found out after the interview was over was that I'd be getting a "take home" assessment--two mini projects that would test my ability to work with APIs and use frameworks outside of my zone of comfort. Which, believe me, was a huge relief to hear after a week of pulling my hair out trying to understand big O notation and hash tables.

Here are both of the questions:

1. Build a landing page with custom form validation

Fields: Name, Email

Requirement #1: The email field needs to check to make sure the user submits a company email address. If the user tries to submit the form with a gmail, hotmail, etc. address, trigger a form validation error and tell the user they need to submit a company email

Requirement #2: Split the name field into first_name and last_name delimited by a space

Requirement #3: Post the form to a MailChimp email list

2. Retrieve and format data from MixPanel's Data API

Requirement #1: Solution has to be done in 100% javascript

Requirement #2: Final output data should be in a csv or comma-delimited file

Requirement #3: from_date: '2014-01-01', to_date: '2014-03-10'

API host: 'data.mixpanel.com', path: '/api/2.0/export/?' + params

So, the first project was pretty easy. You can check out my solution here. After reading Sandi Metz POODR, I've been obsessed (perhaps a bit to a fault in that I'm always distracting myself from the task at hand) with eliminating dependencies on external gems or libraries by wrapping their methods in my own methods. If methods ever change in a library/gem and you need to update to a newer version of that library/gem without completely messing up your application because method names have been changed **ahem ActiveRecord ahem** , you can simply go back and change that gem's method inside your wrapper class and it is instantly fixed throughout your app! Yay for reducing external dependencies! 

(kicking external dependencies in the face)

So as you can tell by the fact that I went on this huge tangent, my decision to approach the problem this way did take some extra time, but I think it was worth it. At this point I'm just hoping that they'll take the time to notice that I put in the effort to make the wrapper class for the gem I used (gibbon, a ruby gem wrapper for MailChimp).

Anyway, the real difficulty came in when I approached the second project. Can you guess why? I'll tell you why. Because JavaScript (and sadistic API's)

Fortunately, I had the opportunity recently to take a class with the nodeschool peeps on the basics of node, which made getting started with making a HTTP request to an API in Node a lot easier. This is simply done using Node http module

In any http request, you need to specify an .on("end"...), since the request is made asynchronously. If you don't know what that means, you can read my last blog post! An interesting aspect of the way Node make's requests is that it actually gets "chunks" or what are called packets of data at a time. The packets are retrieved in the .on("data"...) block above. As you can see, I concatenate the data (which is a Buffer object and a way that node deals with and stores binary data. You can read the docs for the class here) that is converted to another string called body every time node retrieves a new packet. At the end of the request, I do some magic stuff with the data and convert ultimately call a method which converts it to CSV format. THIS was the hard part of the project.

So for some god forsaken reason, the particular route I was given to request data from Mixpanel was one in which the data returned wasn't REALLY JSON: 

While it LOOKS like JSON, you can see that the JavaScript objects aren't actually contained within an array. After some toying around with it, I realized that they were in fact separated by return characters. While this isn't a huge deal, it did take some finagling just to get it back into JSON format... I'm not entirely sure if this particular API request was given to me because they knew that it was a tough one to work with in terms of formatting or not, but the story gets a bit worse... 

After managing to get my data into JSON format, I realized that the event objects weren't all consistent with one another. Event event objects of similar types didn't always have the same amount of properties. This meant that getting them into a format which I can use to export to CSV was going to be a bit more of a challenge (I needed an array of arrays, where the first array were the column names, and all the arrays afterward were rows in the table). 

Ultimately these are the steps I took to do that:

1. Flatten the event objects so that none of them had nested objects as attributes. (I was fortunate enough to have found a gist that did just this. )

2. Iterate over the first object's properties and create an array of column names based on its properties

3. Iterate over the rest of the objects. For each object, iterate over their properties and the value of each property to an array of values. 

4. Push the column_names and object_values arrays to an outputToCSV array. 

I THOUGHT this would be a foolproof plan. After quite a bit of hard typing labor, I found out that there was something wrong with Step 3 that was going to cause my value arrays to be inconsistent in length. Can you guess what it was?

...

......

.........

OK here it is: 

I was iterating over each object's properties and adding their values to a new array each time, whereas what I should've been doing is iterating over the column names I had for each object and calling each column name property on each object. If the property didn't exist for that particular object, I would just get an 'undefined' value returned, and wouldn't end up with an array that was a different size than other value arrays. 

Anyway, you can take a look at the result here:

It was definitely an interesting project to work on, and I did enjoy working with an entirely new server side language. Probably the most valuable thing I learned from this project was how to deal with API data that isn't always consistent. 

So this weekend I got the amazing opportunity to participate in the traveling nodeschool experience, where I was able to learn about some of the basic functionality of node.js, the only server-side language written in JavaScript to date. I wanted to take some time to write about what I learned there because, well, it kind of blew my mind--and because I'm hoping it will help me better process the hurricane of information that flew at me that day.

So to participate in the school we had to download the command line tutorial that nodeschool made, which anyone can download by following the instructions here. This is the basic, introductory tutorial to node that they give to all the students that show up to the in-person classes.

The first couple of tasks were relatively easy, starting off using some synchronous node functions to console.log hello world, or to take command line arguments and parse through them when a javascript file is run.

After that, things got a little bit crazier. Around the 5th lesson, we were given the task to build our own module--an encapsulated bit of code that we could require (using node syntax) in our other files and use. For this task, we would take code that we had previously written and encapsulate it in a module. In a language like Ruby, this is relatively easy to do. All one does is the following:

Back in Nodelandia, however, things aren't as straightforward. Because Node uses what is called asynchronous functions, it is structure in a way that seems awfully recursion-y. And, well, it's that way for a reason. One of the reason Node seems to be so unique is that it doesn't need to run scripts line-by-line, which most programming languages like Ruby and Python do. If you have some familiarity with JavaScript/jQuery, you've probably heard the term callback function before. Callback functions are the core of what makes Node.js its crazy weird self. Here's an example of a callback function you often come across in basic jQuery:

The jQuery here binds an event listener to an element on your page which sits and waits and waits and waits until the user clicks on the DOM element that it's binded to. When the user does click on that element, what happens? That's right, the callback function, which is the second argument of the .on() jQuery method, gets run. 

So asynchronous functions are very easy to come by in JavaScript. These qualities have been used on the client side to make all the interactivity were so used to coming by during our day-to-day internet use. But it was not until 2009 that someone had the ambitious idea to use this asynchronous quality of JavaScript to build a unique server-side language.

So, I was talking about the module that I created for one of the nodeschool lessons earlier. Now that we've reviewed the idea of what an asynchronous function is, I think it's safe for me to show you what it looked like:

Woah there. I know it's a lot at once, but don't worry, we can break this bad boy down.

So lines 3-4 are simply importing built in Node.js modules which were the tools I used to make what I did: a simple program that, when given a directory path for the first argument and an extension name as the second argument, spits back at you a filtered list of the files in that directory with the given extension. 

The code I had written before trying to make it it's own module is wrapped in the filterDirFiles function. This is the function that I wrote with the same functionality before I put it in this module: 

They look very similar, but there a few key differences here. The first and foremost important difference is the presence of a mysterious callback argument which exists only in my module version of the code. This argument is fed into the function filterDirFiles as the last argument. Because this callback argumnet is what blew my mind, this is what I'm going to talk about most here. If you'd like to hear more about the other stuff that's going on in this script, just message me! 

So with this callback, we do the same process to list our directory (by calling fs.readdir and passing it the path and a...you guessed it... callback function, which is what contains the code to do something with that path data). BUT, now, instead of filtering that list and iterating through it at once, we simply filter it, and return it as the second argument of this callback function that we passed into our function. We will take care of iterating through the list and console.log'ing each in our main js file, where we import the module: 

  In the first line, you can see that I imported my custom module by calling require() and feeding in my module's filename as the argument. By storing that module into a variable name, I can then call it again on line 5 and pass it the argument it needs-- a directory path, an extension which it should filter the files by, and, YUP, a callback function. So this function is what gets passed into our module and referred to as callback. When our module function executes correctly and doesn't hit an error, it returns the final result of its calculation via the arguments in the callback function. It does this with the first argument set as null, because the first argument of all node callback functions are always going to contain returned errors if there are any. In the file that we call  our module in, we refer to the returned data as filteredList, and iterate through it on the callback. 

It took me a VERY long time to get even a glimmer of understanding of what's going on here. The idea that you are passing in a callback function that gets returned with the value of the data you want to return in its arguments kind of blew my mind. No other language I've encountered thus far does anything like this.

Anyway, this turned out to be a super long post. I hope that this shed some light on the way that Node works. If not, try staring at it for a bit longer. That's what I've been doing. I'm hoping that my brain will just absorb all this strange knowledge via subconscious osmosis, though so far I haven't had much luck with that.

Well, it's been a while Tumblandia. It feels good to be back wielding doge memes.  

For a while I’ve been wondering how the hell so many sites these days feel so quick and smooth. I think I finally found the answer: JavaScript frameworks.

 What is a JavaScript framework you ask? Let me explain…

When I first began learning about how websites work, I kept hearing the terms Model, View, Control. MVC, MVC, MVC. The way that these things work together in a traditional server-based application is an interesting process that took me quite a while to fully understand. Basically the idea of the MVC is to separate your bulky data from the flow of your route requests from the view that your users ultimately get to see. Your Model(s), often existing in their own files in a folder called “lib” are prototypes of all the data entities that you have in your database. They communicate between your database and the language you’re writing your app in (Ruby, Python, etc…) and ultimately hand stuff over to the Controller, which exists in a separate file. The controller then possibly does some stuff with that data (although not too much stuff because, well, putting a ton of logic in your controller is just bad practice) and then hands that data to the View (usually in ANOTHER file in another folder), which is HTML in which you can embed the data that you are handing to it.

A lot of handing off, eh? What this results in is an application that allows you to communicate with your server using HTTP requests. These are like handshakes that your browser has to make every time you want to see a new page on a website. It’s often the equivalent of clicking on a link on a page that leads to your browser to another page on the same website.

 JavaScript can often be used to make this way of navigating a server-heavy application a bit easier using things like AJAX, which make requests to a server asynchronously. This means that content can be loaded to a page without that page ever having to refresh.

But what if there was a world in which navigating through your application never required making any of these clumsy requests? What if when you search for something on a website, the content you were searching for appeared below dynamically (like the suggestions that google gives you whenever you google something). THIS is where a JavaScript framework like Angular.js can come in handy.

 Angular.js works in such a way that your Models and your Views are no longer separated.

 Here is a super useful diagram of how this scoping with ng attributes might work.

  Using other Angular.js HTML tags, you can iterate over your models by declaring ng-repeat on any element that you want to be made for every object in your model that you want to display to the view.

So, I had an interesting night. I decided to go to a hardware hacking Meetup tonight, where I met a bunch of fantastic people and got to play with none other than *drum roll* a pair of google glasses and *second drum roll* the oculus rift virtual reality headset. I spent the night there just trying to get a Rasberry Pi device up and running with Gus and Amine (which we managed to do!). Our end goal is to create a device that constantly measures the weight of the shelf in the fridge that holds our beer, and display on a website whether more beer needs to be purchased. A tad bit ambitious for people who haven't even made an LED light up yet, but a great goal. 

So while we did get the Pi set up and ready to go, downloading Rasbian (the operating system that most people use on the Pi) and formatting the SD card ate up pretty much all the time we had there. Here are some pics of us playing around with all the cool gadgets that were there while the Pi stuff was downloading:

Once we got the Raspberry set up and displaying on the screen, we called it quits because it was already 10pm and none of has had even eaten anything since lunch (aside from the delicious snacks that Gus and I got from raiding the fridge at ThoughtWorks).

So we headed out after cleaning everything up, thanking the hosts, etc… and went in search of the train, and, in my case, a place to appease my angry stomach.

On the way to the train, we stopped at a Sbarro’s that was so empty we could almost hear crickets chirping throughout the place when we entered. We struck up a conversation with the guy who was in charge of the pizza section (bear with me here, the details are important, I promise). Out on the counter there were 10 whole pizzas that looked pretty fresh, though way over priced. Amine asked “so what do you guys do with all these pizzas when you close?.”

Guy: “we throw them away.”

Me: “so can I just have this one for free?”

Guy: [jokingly] “maybe if you wait until 11 when we close”

Me: [sighing after checking my watch and finding out that its 10pm] “fiiiiiiine”

I go to the counter with my pizza, pay the overpriced $5 for it and get the hell out of there.

I’d like to interrupt here to say, I’ve worked in multiple cafes and restaurants before. I’ve known about the fact that restaurants have to throw away food for a while. I’ve tried once or twice to take the leftover food to homeless shelters, but it was just always so damn hard to find a homeless shelter that was close enough to where I worked to be a reasonable trip for me to make, especially after a long day of work. Anyway, the next part of this story is what made me pounded it into my head just how messed up this moment in Sbarro was.

I was walking along the platform for the F when I hear “sir, are you going to eat that?.” I looked to the bench that I was walking past and saw a fidgeting homeless man who had such a genuine look of anticipation on his face that his face stuck with me as I walked a couple more paces ahead after telling him “I’m sorry.”

Then it struck me. I’ll just tell him that Sbarro is closing in half an hour, and that if he just went outside to the store, he could ask them for the food that they were going to throw away at 11pm.

I turned around, walked back to him and told him about this ‘brilliant’ plan. What he told me:

“They don’t even let me use the bathroom there. As soon as I try to go in they kick me out”

Suddenly it hit me that this guy not only has to deal with the fact that he’s starving, but also all the social prejudice he’s up against as a homeless person which inevitably makes the struggle to be fed every night an impossible task. I couldn’t not give him my pizza.

After handing it to him, I walked away, stunned. Stunned at the illogical wastefulness of our society. The absurdity that those 10 pizza pies in Sbarro which are now probably sitting in a black plastic bag on the street for rats to feed on could’ve fed up to 80 homeless people.

That. Well that, is just fucked up.

I began to think about the problem. Really, the source of the issue is that there is a middleman missing from the picture. Yes there are shelters, but like I explained before, the painstaking process of getting leftovers to a shelter is one that turns many restaurants away from donating their left over food at the end of the night.

But what if there was at least some sort of pipeline of information, where those with the intentions of feeding the homeless could know about when a restaurant or café is going to throw away their left overs? What if an employee at a restaurant or café just had to hit a button on a website and input their closing time to post that information along with their location to a board or table where a middle man (or woman) could see it? Ideally the middle man could look at this table and find all the restaurants or cafes near him/her that are giving away their left overs at late hours of the night.

It may be naïve, crazy, ambitious, whatever you want to call it. But the idea sent shivers down my back when it first popped into my head. I haven’t felt anything like that since the day I began to learn to code. I could use technology to do something that could possibly have a positive impact on not just one homeless person’s life, but on the lives of many, many people. It was a beautiful realization. Technology asserts itself into our lives in so many ways yet how could such seemingly simple app not have been thought of before?

Every doll knows about its containing element. Every doll knows about its "innards," e.g. all the other dolls inside it. But how can a doll know about the doll that is containing the one that it is currently in? In a world where you envision yourself as a Russian doll, the dolls inside you as perhaps your internal organs and the doll containing your doll a box that you've been shoved into, this kind of makes some logical sense, right? How the hell would you know what's outside the box that you're currently in or even interact with the world beyond 'the box'? 

Well it turns out Russian Dolls are perfect examples for scoping in JS. A function in JS is declared in the following way:

function <functionName>(<someArgs>) {

    do some stuff with the args, or perhaps instantiate a new variable.

}

Basically, whereas in Ruby variables within a function block weren't accessible from outside the scope of the function, JavaScript is more forgiving. Every function block's context is that of the blocks nested within it and ONE above itself. In other words, if I create a var outside of a function 

var x = 10;

and alter it in some way inside a function

function () {

    var x = 5;

};

console.log(x) // => 5

x was changed from within the function! 

Nesting functions allows you to provide context to functions. Check this out:

function makeAddFunction(amount) { function add(number) { return number + amount; } return add ; } var addTwo = makeAddFunction(2); var addFive = makeAddFunction(5); show(addTwo(1) + addFive1()); (stolen from Eloquent Javascript)

So today we were given an assignment to fix a bug causing attributes of a rails resource called games to not save. Check out the repo we had to fix here.

There was only one bug which was causing this, and it turned out to resemble the bugs I tend to come across in my own code way too often:

It was one character. 

To debug I first took a look at the view for the games/new route. When everything looked fine there, I moved on to see if maybe the table games had something going on that was preventing any name entered from being validated (though I realized later that that would take a significant amount of effort to screw up, so it was probably unlikely unless you were some sort of... coding masochist?) 

Anyway, all was swell in the games table. Finally, I moved on to my controller, and took a look at the action for show. Everything looked fine: the @game instance variable was equal to Game.find(params[:id]), which is the game object with the :id that the user is requesting via the URL. After puzzling over this line for way too long, I finally realized I needed to move on to the POST action of the page, which was create. 

Everything in the action looked fine, he was creating a new game object, passing it the params hash for the form, and then calling save on the object and redirecting to the show page for the game.

Was I going crazy? No. I couldn't let the code gaslight me any longer. I decided that the params hash was something that always seems to have a trick or two up its sleeve. So with that, I stuck a debugger gem in my gemfile and put 'debugger' in my create action. 

Taking a look at the params hash, this is what I saw:

{"utf8"=>"✓", "authenticity_token"=>"otfMUfyrB2X7N6nQVccgpOXwlHs1OpteiMv+dlD+x0Q=", "game"=>{"name"=>"test"}, "commit"=>"Create Game", "action"=>"create", "controller"=>"games"}

and what I was calling from the params hash was:

params[:games]

.....

.......................

..................................

I give you.... The S.... FROM HELL. 

When I learned we'd be starting rails this week at the Flatiron School, I had a mini panic attack.

Had we already covered more than 50% of the topics in the course? Yup. Did I feel ready to move onto what I thought was the be-all end-all of the course? Well, not exactly. 

I was pretty overwhelmed going over the file structure alone of Rails earlier today, but not NEARLY as overwhelmed as I would've been had I not learned about how to use the micro-framework Sinatra earlier in the course.

What I've begun to realize is that learning Rails is pretty much like learning a new language. While Sinatra had its quirks and little jigs you needed to abide by, I still felt that you didn't have to do a whole lot of semantic dancing before getting to some of that good ol' fashion ruby code we're oh so used to (Classes, Objects and Methods galore). 

With rails though, it seems as though the seemingly enormous infrastructure framework (I say seemingly because I can imagine that as time goes on, it becomes less overwhelming in size) and the new grammar make it so that I begin to miss the good ol' ruby code that I'm used to. Almost all the methods that I used today were these long phrases written by the Rails developers that just, for a reason that I can't explain, seemed clunky writing out. Perhaps its something that I'll get used to. Not having used any other frameworks in other languages aside from Flask in Python, it can imagine that Rails is among the more verbose of the frameworks out there, which is something I can definitely appreciate. 

Hey all, thought I'd check in once more to show you guys a couple of codepens that I've made to fiddle around with the CSS transition attribute. 

Here's the codepen to some text sizing stuff I did with transitions (simple, but has a cool effect).

And here's the second codepen I made to see how div resizing looks using transitions. I'm super excited to delve into more complex transition, and am definitely adding this blog post by Alex Maccaw to my CSS reading list.

...Who am I kidding. I don't even have a generic reading list. I'll probably just end up leaving it open in my browser so I read it in the morning before I start getting distracted by teh internetz.