I’m enjoying the work that Kyle Simpson has done on understanding how the compiler (yes, he says JavaScript is a compiled language not an interpreted one) declares and hoists functions and values. A cool thing about it is that functions do not hoist in a stacked way, they hoist in a mutual way and he has an awesome example to prove it. “As always this is more for my sanity than yours”.

I have a huge goal of understanding JavaScript better. Digging deep into it is really helping my confidence and understanding of larger concepts. “Every thing below is my interpretation and you should do your own research”.

First there is a difference between function declarations (statements) and function expressions.

function b(){}   //function DECLARATION(statement)

var a = function(){}   //the left is a variable DECLARATION, the right is a function EXPRESSION

The code below is a great example the start with. Hoisting is really something we made up to explain a complex feature that the Engine executes. But, at the running of this code the engine will run all the way through the code identifying all DECLARATIONS and assign them positions in memory then, during execution the engine will run through the code line by line assigning values.

Screen Shot 2016-05-25 at 2.41.20 PM

So the above code basically (how we see it) runs like below:

Screen Shot 2016-05-25 at 2.46.57 PM

“Var a” and “var b” are both declared and set with a value of undefined (yes it’s a value). Then the code will run line by line. Above you can see that “a” is set to “b” while “b = undefined”, then “b” is set to “2”, “a” when logged is still “undefined”.

Now, function declarations (some call them statements) are hoisted ABOVE variables when declared and function expressions are not hoisted. Simpson talks about the LEFT of EQUALS is Declared at compile and the RIGHT is Assigned at execution.

Screen Shot 2016-05-25 at 4.07.43 PM

Above code basically hoists (how we see it) like the code below.

Screen Shot 2016-05-25 at 4.10.03 PM

From what we know about how variables hoist we would think that functions would hoist in the same manner. A function declaration (statement) hoisted below the above function declaration (statement) should not be able to be called.

Screen Shot 2016-05-25 at 4.19.16 PM

Simpson argues that if this language was a truly interpreted language that read line for line then the above would not work. Functions declarations (statements) are actually hoisted at a “MUTUAL LEVEL”.

Screen Shot 2016-05-25 at 4.22.40 PM

He proves this with a Computer Science concept called Mutual Recursion, where multiple functions are calling each other. PS. sorry if you read the link and now your brain hurts!

Here is his example (the code works fine):

Screen Shot 2016-05-25 at 4.26.53 PM

The answer should be 39. I worked the problem out free hand below.

Screen Shot 2016-05-25 at 4.46.32 PM

a() is checking for completion (foo > 20) and returns a call to b() while adding +2 to foo.

b() is returning a call to c() and adding + 1 to a stack that will grow due to closure

c() is calling a() and passing foo * 2

after 3 rounds a checks that foo(36) > 20 and returns foo which in turn will grab the b stack (3) “that b stack is sitting in memory I think due to closure, I need to do more research”

a(36) + b(3) = 39


*Side note: this might also explain why primitive variables passing to other variables are copies. eg “a = 5;”, “b = a”, “a = 1”, “log b & log a”, “a=1”, “b = 5”. Where as “function a () {return ‘car’}”, “var b = a;”– these are pointing at the same function, so if function a is changed then function b is changed. I need to do more digging.

Kyle talks about this compiler in much more detail, talking about how the compiler looks at Left Hand Statements vs Right Hand Statements among other concepts. It’s really good stuff and he has a course on Plural Sight which goes into a lot of depth.


Notes From ReactATL Meetup


Great time tonight at ReactATL Meetup hosted by Andrew Smith and Taggart Bowen-Gaddy. It was an open format where people could come in with questions or examples and just talk code. “Like always this is more for my sanity than yours”.

Andrew, talked about dealing with Redux and components the problems that come from multiple components using the same state. He talked about using Reselect and NuclearJS to deal with this with the creation of selectors. I have to be honest I need to dig into it to understand it but, both seem to have good documentation (I’ll add to the list of 45 other libraries I need to look at).

Taggart talked about FalcorJS, which is Netflix’s answer to data management between the server and client built for React.  He showed a proof of concept he has been working on for his team. It is basically a mutable  JSON file. You basically send out a call for a defined box and the server will work to fetch that data and manipulate what is in the box. This box can cache to keep from having to continuously update the whole file. I thought about the idea of “closures” for JSON data transfers (note: I could be completely wrong about this). He also talked in Redux about not using a true Action Generator file and instead holding the Actions in the Components to keep from experiencing errors due to poorly called or worded dispatches.

I showed off some simple React examples I have run up. They were good examples for the guys who had not seen Redux. You can access them below and compared the differences in main components between regular React and React Redux:

Weather App

Timer App,

Todo App w/ Redux (note: I am adding authentication and moving this over to Firebase so if you notice a functionality issue, sorry)

PS. I think Google’s Firebase is VOODOO. You can find the source code for these projects on my GitHub.

Notes From ReactATL Meetup

Journal of an Apprentice Developer

After connecting with a company here in Atlanta I was sent a set of corporate principles and resources. This was so that I could better understand who they are and what they represent. The resources are great focusing on two great works Clean Coders and Apprentice Patterns.

Inside of Apprentice Patterns was a gold mine if you are interested in learning about the life of a new developer. In chapter 2 (or 3?) there is a link to an old blog by a developer named Jake Scruggs where he details his experience in his first position (YOU CAN FIND IT HERE) at Object Mentor. I realize I am supposed to be reading the other two pieces of work but this is intriguing to dig into.

On a side note I had seen a excerpt from Apprentice Patterns in a tweet from Toby Ho who is a teacher for Digital Crafts and had already placed it on my reading list. I’ve read Clean Code and I am sure Clean Coders will be great.


Journal of an Apprentice Developer

Braving the DOM

I screwed up……. “As always this blog is more for me than you”. I get that lots of people can be great front-end devs and never really get outside of the frameworks and libraries that are so popular. I am not that guy, I am never confident unless I understand how things work. I’ve been digging through Anthony Alicea and Kyle Simpsons works on JavaSript and now I am starting to tackle the DOM with Cody Lindley’s DOM Enlightenment.


DOM Enlightenment

Cody Lindley (so the reviews say) writes the best book focused on understanding the front end environment. It’s intimidating taking my understanding of JavaScript (it’s getting way deeper) and applying it to the manipulation of the DOM. Many people will never get outside of jQuery etc… but as I’ve dug into jQuery’s source code (which is actually funnish) I am sold of better understanding how to build with the clay of the DOM.

Braving the DOM

Design Thinking Tackles A Three Headed Monster

The only way to tackle bold challenges is to accept them and dig into the real story. This is a reflection on how I engineered Design Sprints to help AFFORDABLE COLLEGE understand how to go after one of the biggest challenges facing America….. AN AFFORDABLE EDUCATION.

AFFORDABLE COLLEGE entered the Learn Launch Accelerator located in Boston Massachusetts with an ambitious goal “To disrupt the traditional path that many students take. One that leads them to lost credits and staggering debt”. How might we provide students with resources that allow them to obtain the cheapest and most efficient means to graduation?  Affordable College had focused in on helping Community College (2 Year Institutions) Students seek cheap paths to transfer in which they would not lose a large number of credits (See the problem here). At first glance that might seem like the clear path to start down but as “Presentation Day” quickly approached in January, AFC was starting to feel that they didn’t understand the whole problem.

Partnering with them we quickly realized that this problem didn’t deal with one user. It dealt with three: Students, Community Colleges & Four Year Institutions. Understanding one user or customer can be a challenge but when you have to tackle three it takes a dedicated commitment to suspend judgement and empathize.

We started our first sprint on a windy December Tuesday in Boston. Having flown in team members from across the country we dealt with a condensed schedule and the normal wrenches that go into any well planned Design Sprint (we were thrown out of one college and had to interview students as they boarded the train). We crafted a series of well thought out questions that tackled certain assumptions we had about how CC students looked at transfer, graduation, advisement, finances & work life balance. We met them where they were at inner city and suburban schools. Like most sprints, you quickly find out that your assumptions are usually off. We curated their stories that night and developed an array of personas to deal categorize their needs, wants, pains & gains. We targeted stories we wanted to dig deeper into and repeated the deep dive (iteration is a must). Day 3 led us to a long brainstorming session dealing with six key insights in 15-20 minute sprints. We crafted this brainstorming into a dozen opportunities for change and placed our different personas into storified pitches (we filmed it, it’s awesome and proprietary, sorry). We wrapped up the sprint with prototypes of different ideas ready for feedback from students over the next week and of course we finished our last meeting from a car as I was exiting to get on my return flight home. It wasn’t the finish line but it left the team invested in the lives of these students, a few team members decided to enroll in Bunker Hill Community College.


With an understanding of one side of the puzzle the team worked remotely across the country in January and February on an extended sprint. I tested change of behavior with students in Atlanta while product began refining concepts on multiple MVP’s. We then turned our eyes toward the needs of Community Colleges and Four Year Institutions. With Four Year Institutions I crafted relationships with industry mavericks such as Bridget Burns the Executive Director of the University Innovation Alliance she directed me right down my own street to Georgia State University whose new student retention initiatives were netting the school $3 million for every 1% increase retention. The same story played out over and over again as we surveyed large schools in person and at conferences, enrollment and retention matter.

Our final piece of the puzzle was to bring the team back together this time in Atlanta for a week long sprint tackling the needs of Community Colleges. We had surveyed the country and through the experience of experts had painted a picture of what the ‘less progressive models’ looked like. We wanted to focus on an institution that was a leader in tackling the challenges that Two Year Institutions face and we took a deep dive into Chattahoochee Technical College. We spent two days interviewing leadership in all aspects of the school trying to understand where we could merge our students needs. We learned about a staff who every year has to do more with less resources and where they saw needs. Thanks to the support of the Cherokee County Economic Development team and their new innovation center partnership with the school we were able to immerse ourselves in the community as we curated and brainstormed (there is nothing better than being able to get rapid feedback by walking down the hall). We left the week with what Affordable Colleges leadership felt was an effective path to step into product and partnership development.

Affordable College‘s goal is epic, but they took the time to understand the problem from more than just one point of view. This saves resources in the long run and as they go forward I am excited to see what they do with the opportunity.





Design Thinking Tackles A Three Headed Monster

Take Aways From Atlanta NodeJS Meetup

Awesome time at my first NodeJS Atlanta Meetup. I was a much smaller group than they usually have so it allowed a lot of young developers to ask questions. Having only ran up simple NodeJS servers so far it was a great experience to hear from some who sit on the backend all the time. Here are a couple takeaways:

“As always this is for my sanity, not yours”


I dig Promises, they make things simple to understand. If something resolves .then() do this next thing. New work on Promises and ES6 HERE (not sure I understand it all).

Function currying is creating a function that takes # variables and creating a copy of that function that takes a different # of variables:

Screen Shot 2016-05-20 at 11.51.11 AM


Yes, if we look at both currying and promises as guaranteeing something to be passed to the next function from a function that has finished executing (Closure).



Michael Gokey, Industry Veteran-

Fix a problem for me. Show me you can fix a problem I have in the interview. When you get in the door keep doing that for EVERYONE! The Business Dev guy had a $2 Million presentation on the line and his computer went down. Rather than shrug it off, I set him up on my computer. It took me off line for 3 hours, but I fixed a problem, helped him and I in the long run.

Also, there is a huge separation in opinions on the value of GitHUB with younger developers and hiring managers focusing on it and older developers not feeling that it has much value.



I enjoyed connecting afterwards with long time developers. Couple things on the list to check out:



Google Style Guide for JavaScript

Idiomatic JavaScript


Take Aways From Atlanta NodeJS Meetup

I’m In An Abusive Relationship: With Code Wars

Code Wars: “Hey Ryan, come here take this challenge…… you know you want to”.

Me: “You ruined my life! I hate you! But, okay, one more time.”

I am in an abusive relationship, with Code Wars. Don’t get me wrong, I love it. But, as a younger developer it can be exhilarating or depressing experience. If you don’t know Code Wars is a website that allows people to tackle different coding challenges. I right now am a Level 5 hopefully soon to be a Level 4 (Level 1 is the best).

Some of the challenges are how might I say this? “Quite absurd” Here is an example:

Screen Shot 2016-05-20 at 12.02.52 AM

The amount of things I need to google in the picture above are astounding!

Though, completing these challenges is exhilarating, as a young programmer these can also be a bit confidence rabbit hole (imposter syndrome, no doubt), particularly when you have spent HOURS on a solution and compare it to others.

(node the code above, just an example)

Me: “4 hours, 37 lines of code”

Arsky8867: “2 lines of code, using .map() .filter() a ternary operator and a regular expression!”

Screen Shot 2016-05-20 at 12.12.28 AM

Seriously? What is this? This is voodoo?….. and I admire it.

“Unreadable code = bad code” yes, I’ve heard the pitch but as a newer coder and after taking hours of time I find this both frustrating and exciting.

I want more! More pain, please!

Ergo….. I am in an abusive relationship…. with Code Wars.


I’m In An Abusive Relationship: With Code Wars