Kristin Reddington


A coder's diary

Whiteboarding

I think every developer can agree…whiteboarding is nerve-wracking. Standing in front of executives or senior level engineers with a given algorithm, a whiteboard and a marker, your first instinct is usually to whip out a solution to a memorized pattern in specific language. Having a couple of whiteboarding experiences now, I can say that the right way to handle whiteboarding is similar to how you would go about solving any problem.


Rails & React tips & tricks

I love building full-stack apps using rails api and react for the front end. The two frameworks were seemingly made for each other and it’s very easy to manipulate JSON with both tools, making transfering data less of a headache. Of course, without the right organization, it’s easy to get messy…fast. Learning and mastering common best practices has made developing not only easier but more fun throughout the process. I thought I’d provide a few little tricks I’ve picked up along the way that will provide ease to work flow.


a diff way

My curiosity about React components updating the UI without manipulating the real DOM was something I found peculiar…how and why? I mean, if that’s not magic, I don’t know what is. As a user, I can manipulate and interact with the browser, watch the GUI change and transform right before my eyes, all without actually changing the browser’s DOM or even making a call to an API. My understanding before doing some minor digging was that once state was updated in React, the virtual DOM updated the page starting with the root node of the document’s tree and then the user could see and interact with the updated components rendered on the screen. This was quite a thumbnail sketch understanding, of course. Of course this is just part of a well implemented and efficient algorithm known as diffing.


A Ruby on Rails Guide for building a social app

This tutorial is aimed at the intermediate Rails coder that wants a detailed, yet loose enough to make their own, instruction manual. Hopefully by the end of this tutorial, you’ll have a shiny new app to show off and have learned something new or brushed up on old skills. This tutorial also assumes you have basic Rails knowledge, but a beginner can easily follow along with an expected learning curve and some independent research on certain topics.


The Beginnings of Demystifying Javascript

These past couple of weeks, I’ve attended a few awesome meet-ups related to both vanilla javascript and AJAX. With Ruby as my first programming language, I often doubted my Javascript skills and avoided its convoluted kinks. That was until I learned what was actually going on “under the hood”, so to speak, and can begin to demystify this incredibly powerful yet initially quirky language.

I’ll be honest here- I’m guilty at using many methods at a very high level and barely knowing how they work, but that they do what I need them to do when I need them to do it. Yes, a very honest statement and very, very bad programming practice. Take for instance the fetch API used in Javascript. I knew that it was “fetching” data that I needed from my endpoint or external API but had no idea what was going on within those milliseconds it took to grab that handy data.

At the most basic level, fetch is essentially making an HTTP request that relies on a promise, which is much like a callback. A promise is a placeholder object for the eventual result value of our fetch method or reason for error will manifest. Now, what happens next is dependent on the execution context of your program. Normally, there are two different functions you can call, then() or catch() depending on the state of fetch. If it’s fulfilled, then() is chained to handle any asynch actions that need to happen with the data object fetched from the API. That then returns another promise, which is handled by synch or asynch actions once again.

One thing to note about fetch() is that we use these promises because of Javascript’s single threaded nature. We need a “placeholder” browser object to hold onto the data we need while our code executes so that way we can use this data to make another request if need be, instead of directly handling the result of the initial request.

Asynchrony in Javascript is tough because of the language’s innnate single threaded execution, but once the mystery of fancy browser APIs like fetch() can be demystified, we’re able to do cool things like make multiple data requests in a row and have our request send us the callback instead of including it in our original function parameters. Pretty cool if you ask me!