Friday, May 22, 2015

First open source contribution!

Our instructor at NSS has been having us concatenate our Bower dependencies for site deployment using a handy program called "bowcat" (Bower-concatenate..?). Check it out here:

and here:

Some confusion arose when we started including the Firebase package as a Bower dependency, however-- it took a while to get at the root of the problem, but it boiled down to: we'd been running sh scripts that ran bowcat with its --min option, which will concatenate minified versions of the dependencies it finds. Turns out that Firebase doesn't have a minified version, and so bowcat hadn't been including it in the concatenated file it was generating.

Npm packages are written in Node ("Node Package Manager"), and Node is Javascript. So hey, seemed like I could probably figure something out.

Four lines and a pull request later, and I've made my first open source contribution! I just had bowcat rerun its filename-gathering procedure sans the --min option if it wasn't coming up with any files for a particular package (it does this on a per-package basis).

It's pretty thrilling to have contributed something (albeit small, but gotta start somewhere) that really gets used by people. I hope that one day I'll be able to say that it was the first of many such contributions.

Thanks to AjayMT!

Tuesday, May 5, 2015


Sure enough, today's work involved making the stock page delete entries from both its table and the database that it uses to make the data persist.

Finished that part before lunch!

The rest of the time I worked on using regular expressions to check for bad user input, made some elements fade in/out, etc. All around a much better make-believe investment experience.

This one is actually at a different codepen URL from the last entry; I wanted to start working from a new copy in case I broke something. I should really make proper files and put these on github... will get on that soon.

In other news, I went to an introductory Internet of Things workshop tonight and learned to collect temperature/magnetic switch information using a Raspberry Pi, which I then (paid for and) took home! So I'll be looking to get into some interesting or perhaps just silly hardware stuff soon. Big props to Nashville's own Initial State and Jamie Bailey for putting on the workshop.

setting up

Bonus pic from Hack Tennessee:

Your very own Q, of the eponymous Dev Dive on the left, talented classmate James on the right.

Hack Tennessee 7

In addition to the aforementioned apps that I worked on last week and today, I also spent my weekend at Hack Tennessee. It was a tremendous experience and did a lot to make this all feel more "for real"-- I worked with employed developers and contributed to a complete Rails project that is now finished and on the web:
Many NSS students and former students were involved in its creation. The concept came from Ayumi Bennett, an NSS cohort 8 student (I'm cohort 9)-- it's a way to browse and learn about local foods made in Tennessee. The backend (Ruby on Rails) was handled by Robert Fryman and he also served as the project manager-- really knew his stuff, made sure that the rest of us were able to follow along with what was going on with the backend, and made absolutely sure that everyone had something to contribute to. Great experience working with him and the rest of the group.

I enjoyed working with Rails given that it was what I was studying before diving headfirst into all the frontend tech. at NSS (after which we'll do Node.JS); I'd hoped that I'd be able to remember enough to be useful, and ultimately, I was! I made the layout & buttons that appear when you click one of the four main buttons or "view subcategories"-- basically, wherever you see the blue boxes that grow a bit when you hover over them.

The big learning experiences for me were getting all the gems installed, working with postgresql and using git for a project with this many contributors. These were all pretty new to me and definitely things that I need to get familiar with. I also wrote html.erb files for the first time in quite a while, which took some time to remember but was ultimately quite straightforward.

Had a great time! The winner of the event was a virtual-reality psychedelic unicycle game. Which, I mean, was inevitable from the moment it was announced. Also its presentation was fantastic-- I don't remember the gentleman's name, but he had a Jobs-esque way of making me feel that I needed his product in my life.

Monday, May 4, 2015

App work

I'm really happy with how much work I'm getting to do; we've been going at a pretty good clip in class and have either made or iterated on a front-end web app about once per day.

My creations so far are the renamed ArMoleGeddon:

A weather app that makes a JSON request to the Weather Underground API to retrieve info for a particular ZIP code, or can detect the user's geolocation via the browser and include it in the JSON request instead of the ZIP:

A stock application that I amused myself with by naming "Stocksbocks", etc. This one pulls quotes for particular stock symbols, and then pretends to let you buy shares while generating a table that tracks your imaginary investments. That was the first part-- today we needed to have the table save itself to a Firebase database and then re-write that data with each new pageload. So any stocks you "buy" will remain there unless I go in and delete the data through Firebase. Have fun! This was an interesting exercise in that the quantity attribute for each stock purchase doesn't come from the markitondemand (stock price) API-- it's entered in by the user, so in order to save *all* of the table's data to Firebase, I had to generate a new data object, include the quantity, and write it.

Which becomes a problem given that the writeTableRow function that I'd written wants to pull that quantity value from the text input HTML element, but we now need it to pull quantity from the data object written earlier and pulled from Firebase upon an intial pageload. Nothing too heavy, but it involved short-circuit evaluations in order to deal with edge cases (if there's no data in the database, there's no object to check for a quantity attribute and Javascript will throw an error; need to use && to make sure there's an object, and if there is, check for its quantity attribute) and to choose what kind of data we're writing (check for the presence of a data object passed in as an argument, using && as above; if we have it, use its quantity attribute, and if we don't (ie, it evaluates to falsey), it means that we're writing in info that the user has requested instead of loading/writing data from Firebase, and we should include/write the quantity as specified in the HTML input.

Then we changed all of the Javascript selectors and methods (that we could) to jQuery in order to learn more about jQuery.

Whew! In any case it all worked out, which you can verify below. Only thing remaining is to check for and catch user input errors in the quantity text input (it's already working for the stock symbol input). Oh, and if you make multiple purchases of the same stock, it doesn't combine them into a single line in the table. That would be good to add.

Tuesday, April 28, 2015

Monday, April 27, 2015


Just playing around with the Javascript that we learned today--

Enter this code:

into your browser's Javascript console (and edit the source CSS if desired/necessary), and you can play whack-a-link with the page (links disappear when clicked, but will reappear after a few seconds).

Sunday, April 26, 2015

Crockford's Concoction

Having worked through HTML and CSS (and many related frameworks/preprocessors), my cohort and I have arrived at what will presumably take up most of our class time going forward (since our backend framework is Node.JS): Javascript.

I just finished reading and doing all the exercises for A Smarter Way to Learn Javascript, so "document.getElementById()" and "function thisArbitraryFunction() {" are pretty well committed to muscle memory. I know that eyeballs are the only body parts that are supposed to move during REM sleep, but I wouldn't be surprised if my fingers are twitching those commands out during my dreams to come...

Anyway! How about some content?

As part of our "homework" we have been watching Douglas Crockford's "Crockford on Javascript" lecture series on Youtube. The first is a fascinating look through computer and programming language history up until Javascript, the second touches on the particulars and history of Javascript itself, while the third outlines strengths/peculiarities of what Crockford considers Javascript's greatest asset: its functions.

I'd like to consider some code presented toward the end of the lecture, which Crockford presents as a common mistake made by Javascript developers:

Crockford points out that in the top code, all event handlers created by the loop will report the same div_id (the last one) no matter which one is clicked, which is not the desired behavior. In the bottom code, however, each div_id is reported (alerted) correctly because the "make_handler" function is pulled outside of the loop. He tells us that this fixes the problem because of function closure.

Hmm.. I had to pause for a while and give this one some thought. Here's how I see it:

In the top loop, we've created some arbitrary number of event handlers. The loop makes them all at once, and after their respective geneses they all do their thing, handling events as event handlers are wont to do. Each handler is supposed to listen for clicks on a specific div, and alert their specific div when it's clicked.

Great, except that the "div_id = divs[i].id;" line occurs outside of the actual "divs[i].onclick = function () {" functions that are created. In other words, div_id exists outside of the generated functions' closures; like Python (and unlike Ruby unless you explicitly make a global or instance variable, afaik), functions are able to pull variables "above" them in scope in to use, but variables that are declared/reassigned within them are scoped to their respective function closures.

So what happens here is that we get event handler functions that each handle click events for their particular divs. They do this job admirably, but when the actual functions are called, they each alert a "div_id" variable that is pulled in into the function's scope from outside of it; "div_id" does not belong to the function's scope; it belongs to the scope that sits one level above each function.

In other words, each function pulls, from outside of its scope, the same "div_id" variable! And this "div_id" will point to the very last div that the iterator "i" iterates through in the "for" loop, since that's the last value that div_id is set to before the loop ends and we stop reassigning it. The loop runs its course, all the event handlers are created, and div_id winds up set to the very last value of divs[i]. Each individual event handler function now reaches outside of its scope to pull in and alert this same div_id variable, no matter which div the handler is actually handling. Div clicks are handled, but when they are handled, each handler says that it's the last div.

Which is no good!

The bottom code alleviates this by bringing the div_id variable inside of make_handler's closure before passing it to the event handler function that is created and returned. This new event handler function reports a div_id variable that is scoped to its progenitor make_handler function. So each event handler function no longer pulls in the same div_id from outside; it instead pulls in the div_id that exists within its parent make_handler function's closure. Since make_handler was called with a different div_id each time in order to create each event handler function, each event handler function now pulls in its own unique div_id, which it will dutifully report when clicked.

So, thanks to judicious use of function closure, each event handler function now reports its own div_id, all of which are different despite having exactly the same variable name.

I hope that does a decent job of explaining it! It was a lot of fun to work through mentally.