Attempt 101C

I didn’t grow up in Stockton, but soon after I graduated high school, my mom moved there, so I’ve been visiting there regularly for nigh on 20 years now. Stockton has always been a bit of a mystery to me. It has all the ingredients, like proximity to the Bay Area and Sacramento (not to mention glorious recreational areas like Yosemite), very affordable rents, and the oldest university in California in UOP, to be a cultural and tech hub, but it consistently has rated as well, a miserable city. It has high crime rates, low literacy, and only recently exited bankruptcy.

But my yearly snapshots have begun to show more promise. The Miracle Mile has more and more hip restaurants, cafes, and bars. The city just elected a 26-year-old African-American mayor in Michael Tubbs. And on my last visit, I finally discovered a tech company, Tuleburg. It’s great to see some UOP grads, instead of joining the post-college exodus to the Bay Area, stick around Stockton and make a contribution to the community. They took over a space in the beautiful old Federal Building downtown with just six people, and proceeded to explode in size and reputation in the last five years. Tuleburg does business development in the broadest sense of the term, from marketing, branding, design, and social media, to building web presences (which is where the coding comes in and I get tingly). 

Most impressively for a company still in its toddlerhood (and something I really don’t see enough of in NYC tech companies), Tuleburg dedicates a lot of time and space to the Stockton community. There’s a room Tuleburg uses for community tech education that any local grassroots organization or nonprofit is also allowed to use. The CEO Jason showed me some impressive art on his wall that he commissioned from a local homeless man. He also organized an anti-crime march. The list goes on--suffice to say Tuleburg isn’t some stealth firm taking advantage of plentiful Stockton office space while pretending it’s not part of the city.

How do I know all this about Tuleburg, you ask? Well, here’s the kicker for people used to the uber-secretive and/or “we’re too busy” tech cultures of NYC or the Bay Area. I emailed them saying I’d love to visit. And they emailed back right away saying sure, come by. I went there a few days later and was shown around by Becky, the CMO, as well as Emily, a marketing assistant. I talked to developers, creatives, and Jason, the CEO, all of whom were friendly and either happy to talk to me or damn good at pretending.

I finally can post here links to the videos of the presentation I did for my hackathon project Poetaster, the presentation my team did for Borderless, and the full video of my tech talk about Angular dependency injection. Without further ado:

http://www.fullstackacademy.com/final-projects/borderless

http://www.fullstackacademy.com/hackathon-presentations/poetaster

Well, I did it! After thirteen very hard weeks, I’m a proud Fullstack graduate. I’ve dived instantly into the job search at our Hiring Day and afterwards, and am excited about a number of possibilities. I’ll keep you updated. In the meantime, I thought I would link to both my final project and my poetry analysis project, both of which are officially deployed!

https://guarded-plains-82965.herokuapp.com/

It’s been a fun ride, interrupted a bit by sickness. But our project is going well. I can’t believe we’re two weeks from the end of Fullstack. I thought that this week I would share the slides from a tech talk I presented about Angular dependency injection. Here they are: 

http://slides.com/jrauschenberg/angulardependencyinjection

I’m currently swamped with my first solo hackathon-style project, Poetaster, which has taken the last few days of my life rather completely, but is pretty amazing. In the meantime, here are a few other tidbits. First, Code and Stuff As Will Break Her, Installment The Seventh, with things learned largely by trial and error as I built a working Amazon-like shop with a team, and Poetaster solo:

--Population in Mongoose is a finicky thing. If you’d like to populate a single field, you can do it like so:

Orders.find({}) .then(function(orders) { populate('user')

(and so on). Pretty straightforward. But if you’re populating multiple fields, do not use commas or needlessly use ‘populate’ twice. The result looks like a syntax error in waiting, but is actually the correct way:

Orders.find({}) .then(function(orders) { populate('user product’)

--You may think you’re writing good paths, but to be sure, require the path module in node.js and use path.join, like so:

var path = require('path'); path.join('/foo', 'bar', 'baz/asdf', 'quux', '..')

Secondly, I’m thrilled to have completed my first major group project witih Jeremy, Liana, and Hailey, a person/pet clothing store that is as lovely as it is fake:

https://glacial-tundra-86660.herokuapp.com/

In the absence of a pressing coding issue that came up this week, I thought I would begin to talk about similarities between two of my biggest interests, poetry and coding. I feel like I’m relatively uncommon in loving both, though I’m mystified why more poets don’t like coding, and vice versa. For now, in lieu of making sweeping generalizations, let’s just take one poetic example, Galway Kinnell’s insanely good poem, “Prayer”:

Whatever happens. Whatever what is is is what I want. Only that. But that.

Yes, that’s the whole poem. Read it. Then read it again. Have you been, like “ohhh,” yet? Read it again.

It’s a dense piece of poetic code, playing on repeating “what,” “that,” and “is” over and over, in ways that mean something different every time. Who else but a coder could understand how context changes a single variable, even if it has the same name? Kinnell pulls off using “is” three straight times, while still making perfect sense. Here’s my paraphrase of all that he’s packing into these three lines (though of course any written-out version vitiates the whole point of the thing):

“Whatever goes on in life--whatever existence turns out to include--will satisfy me. I can live given just that. But please give me at least that.”

What makes this poem succeed is not merely attention to detail, but semantics, and how an entire program, i.e., poem, can turn on a phrase. It’s also understanding of the emotional context that any poem lives in, kind of like the process that any piece of code lives in. The poem would be meaningless if you didn’t know it was part of a module, as it were, called “Prayer,” and if you didn’t know what modules like that have been used for in the past.

Any poet who has obsessed over a missing--or extraneous--element that keeps a poem from working, or who has appreciated the few turns that have made the best poems work, should be able to acknowledge the same kinds of a-ha coding moments, given the appropriate tools. Take this example, all credit due to Tom of Fullstack, who gave it to us this week as one of “mutual recursion”:

a(1);

function a(foo){  if (foo > 20) return foo;  return b(foo + 2); }

function b(foo){  return c(foo) + 1; }

function c(foo){  return a(foo * 2); }

I’m not going to go into the full JavaScript explanation of this piece of code, but in certain ways it’s working just like the Kinnell poem, playing off the meaning of repeated function invocations which change every time, and an increasingly burdened context.

Maybe it’s the traditional technology/humanities divide that has kept a mutual admiration society from happening, but I don’t see why in principle poets and coders can’t at least be acquaintances, or drinking buddies, even.

On a personal level, I’ve now gone through a relatively calm review week, as well as a harrowing first week of our senior phase, where we began building an application from the ground up. I definitely, as my buddy Andrew mentioned, felt that it was the toughest week so far, in terms of feeling out of my depth. But I have to trust the process, as they say here, and know that the harder it seems, the more we’re learning. I look forward to the final five weeks, because code, that enigmatic Russian lover, keeps enticing me far more than she frustrates me. 

It’s been an amazing week, but I’m actually going to save the personal/Fullstack stuff for the end of the post and first provide a focused discussion on something thorny that can waste hours of your time if you don’t know it backwards and forwards. Without further ado, Code and Stuff As Will Break Her, Installment The Sixth:

--Javascript calls by sharing. Remember when I talked about objects being passed by reference and primitive values being passed by copying? Those statements are true, but don’t actually tell the whole story. Let’s try passing a few things into a few functions to illustrate the difference.

function addSixTo(num) {  num = num + 6; }

myNum = 2; addSixTo(myNum); console.log(myNum); --> “2″

As you might expect from knowing that values are passed by copying, “num” inside the function just copies our “myNum” variable. There are actually two separate numbers once the function is called, and everything we do to the function’s “num” after then has no effect on the original "myNum.” But check this:

function modify(obj) {  obj.name = "Ollie"; }

var myTurtle = {type: "yellow-bellied slider"}; modify(myTurtle); console.log(myTurtle); --> “{ type: 'yellow-bellied slider', name: 'Ollie' }”

Insert your best Jeffersons-style reaction take here. You might think the function would create a new object the instant it messes with the original object passed in. Not the case. The function here actually has power to mutate the object passed into it. Remember, the object is passed in by reference, so “obj” inside the function points to the same thing that “myTurtle” outside the function points to. This is where “sharing” comes in! The function has the same right to modify myTurtle as any other place pointing to it.

You might still not be surprised. “I get it, objects are passed by reference and values by copying. So you can always change an object, but when you change a value, you’re just changing a copy of it.” Not so fast. Here’s the biggest mind-bender:

function modify(obj) {  obj = {type: "red-eared slider"}; }

var myTurtle = {type: "yellow-bellied slider"}; modify(myTurtle); console.log(myTurtle); --> “{ type: 'yellow-bellied slider' }”

Here, an object (gasp) is acting just like a value! The modification done in the function hasn’t stuck at all and instead seems to have disappeared, or gone into a copy of the object. The explanation is that yes, you can mutate objects, but you can’t change them wholesale. Once “obj” is given a whole new object to point to (instead of just an additional attribute), the link between it and what it’s pointing to is broken. The object it was pointing to (”myTurtle”) survives in its unchanged form, while a new red-eared slider object is created and “obj” is pointed at it. 

So, in sum: values, since they are always passed by copying, can’t be mutated. When you pass them to a function, you simply create a new copy that then changes. Objects can be mutated and still be successfully referred to by all variables pointing at them in their mutated form. But when you assign a new object to a variable, it breaks all links to the old object and things behave more like value copying: the original object (as well as any variable pointing to it) remains unchanged, and a new object is created for your variable to point to.

I gotta name-check Barbara Liskov here, because she apparently was the first to name this evaluation strategy. And, in turn, Ayana, an instructor at Fullstack who turned us on to this wackiness.

This week, we finally got into Angular, and we got in deep, with all five days devoted to building a Spotify-like music app using that pointiest of front-end frameworks. I have to say that I am kind of in love with Angular at first blush. It’s very intuitive and powerful. I love being able to use tiny bits of code to control an entire user experience. I also got to attend my first CS Saturday, which was a fascinating dive into the details of real-world black hat hacking (my partner Patrick and I ended up getting second place in the black hat hackathon, meaning you shouldn’t get on our bad sides). I learned quite a bit this week, and so managed to break things in new, interesting, and plentiful ways. Here are a few, in Code and Stuff As Will Break Her, Installment The Fifth:

--Hashbang mode, in addition to just sounding wrong, complicates the URLs you give your users with Angular. Just go with $locationProvider.html5Mode(true) and everything will make much more sense.

--Perhaps not something that will break your code, but a very useful tool that also makes things prettier: using the <pre> tag in HTML, which will display contents in a fixed-width font and preserve both spaces and line breaks. Another thing Angular supports is piping with “|”, so you can pipe anything you want to JSON, or even filter it. Awesome.

--I’ve noticed that in otherwise modular apps, people still go hog-wild sharing controllers between different states. I think it’s really dangerous in that it can cause variable conflicts and other confusion. I don’t see why one shouldn’t create new controllers, even if it means copying some code over from previous ones. Better that than having to go through all the different places that are using the same controller to figure out what’s going wrong.

--It’s key to remember to use dash-separated names (snake case) inside your HTML and camel case for the corresponding name in your Angular directive. But if you’re like me and want to avoid all possible sources of mystifying errors, just use neither. I know I’m going against prevailing style, but would the world really end if you made an all lower-case, no-dash name for a directive or HTML element?

Week 4 saw us creating our first full-stack application, a trip planner. which involved everything from creating and maintaining a database (via Mongo) to a server (via Node and Express) to the front end (via Javascript, jQuery, and Swig), with Ajax helping communications run smoothly. It was really impressive seeing how quickly we could build a fully functioning web application, even if the complexities had our heads spinning at times. I also keep feeling a little dirty every time I incorporate these powerful libraries, where by copying and pasting a few lines of code I am granted magical abilities I feel I haven’t earned. I have to get used to standing on the shoulders of giants, I guess (an R.E.M. song comes to mind). On to a jam-packed episode of Code and Stuff As Will Break Her, Installment The Fourth:

--It’s “val”, not “value” in jQuery, and make sure you understand the difference between “val” and “text.” “Val” is used to fetch the “value” (not “val”)  property of a given HTML element, which can either be assigned manually like any other property or can be the user’s input to an input field, like a form or selection box. “Text” gets you the text of an HTML element, not the user’s input but the actual text on the page. For example, if there’s a form element that asks for your name, the “Name” text preceding the input box would be the “text” and whatever the user types in (or what you set as the default value) would be the “val.”

--forEach takes a super-secret second argument after the callback function, which sets the “this” for the callback function. Very, very useful in some cases where forEach can tend to lose its “this” context and break your code. Enough said.

--Always remember to res.send, res.json, res.sendStatus, or res.end (among others) even if you don't need to. A lot of times, you’ll just need to take in a request as a server and do something internally with it. You don’t have to respond to the request. Oh no, but you do. If you don’t send something, anything, to the client, he or she will hang indefinitely, desperately waiting to hear back from you. Clients, in short, are like those annoying people who constantly bug you about whether you saw their texts, Facebook posts, interminable computer-science-related Tumblr blogs, and so on. To avoid them hiring private detectives or subpoenaing you, at least send them a status code. Though I think your parents deserve more than a quick “200,” don’t you?

--The importance of ordering in middleware cannot be understated. There’s no hard and fast rule set for this. Just carefully go through all your middleware apps, making sure that each will have the necessary tools to do its job by the time it runs, and that it helps prepare the apps that follow to do theirs.

We’d definitely been cramming in massive amounts of data and concepts before week 3, but it felt truly insane for most of the week. We ended up with a Mongoose and Express assessment that I did pretty well on, but not as well as I l would have liked. But I was soon to redeem myself. We traveled to the American Museum of Natural History for a scavenger hunt. Our team was hard-core, sending out scouts to find clues while coding like maniacs back at our home base in the dinosaur area. We emerged victorious, thanks to excellent clue-finding and speedy coding! So that was a needed ego boost and fun diversion. Now for Code and Stuff As Will Break Her, Installment The Third:

--Don’t forget to use body-parser in your Express app. You may be like me, thinking “everything is working fine--do I really need another library?” That’s well and good until nothing works and a simple install of this helper fixes everything. Suck it up and embrace it. And while you’re at it, make sure to specify whether the “extended” property is true or false when you bring in body-parser. We accidentally left that out, which also causes problems.

--Similarly, don’t forget to include chai’s “should” when you include chai. None of our tests were working properly until we realized we had left that one essential line out when incorporating chai.

--Finally, as I’ve mentioned before, “catch” and “then(null, done”) are your friends! Don’t forget to use them whenever you are chaining promises together. Even after my admonitions last week, I slowed myself down by forgetting them a few times in the Friday assessment.

Fullstack Week 1 was a hard-core introduction to the basics of computing, data structures, and JavaScript. Week 2 was hard-core in a different, data-dumpy way. We were introduced to several huge topics--databases, Express, Node, promises--each of which will probably take months to master. But we’re diving in and using them right away. While that involves a lot of blind coding and trial and error, I think it’s a better way than over-reading first without getting any practical experience. We get to be teenage drivers and hit some coding trees (NOT of the binary search type--I’m still scarred), which is still a better way to learn how to drive than reading all the car manuals first. I was psyched about our first CS Saturday, but decided it was inadvisable to leave Brooklyn, as NYC is in the process of getting painted like an Elizabethan woman with a thick alabaster exterior. On the plus, side, Jonas was polite and had excellent timing, and I will be slightly less annoyed by all those people wearing Canada Goose coats when I go out later. Slightly. I’ve gone on too long: here are some coding tips, or Code and Stuff As Will Break Her, Installment The Second:

--Put error handlers below success handlers. This applies especially in the case of promises. You might think that if you’re passing a function two other functions, one to call if the function succeeds, and one to call in the case of an error, you’re covered. Not so. What about the case where the function succeeds, but throws an error after it does so? You’re already past your error handler, and so you have a deadly uncaught (”silent”) error. You can avoid this dreadful outcome by putting an error handler below the entire original function. I’d recommend ”catch,” which is an excellent way to handle any errors up to the point that you call it and keep things moving. You only need one “catch” to clear multiple possible errors. It’s like a good busser at an understaffed restaurant.

--”This” can get lost really easy. If I hadn’t learned my lesson last week with buttons resetting “this” to themselves, I definitely learned it this week, when calling functions like forEach or even simple anonymous ones caused my sweet little “this” to go out, get wasted, and completely forget what it was holding before. There are a few ways to kind of pin a nametag on “this” so it remembers where it lives later, but my favorite so far for its simplicity is setting a variable like “self” to “this” at a point where “this” is the object that you want. Whatever happens to “this” after that, you’ll still have “self” to refer to the original object (if you’re still in scope).

--In a somewhat related topic, be careful with iterator variables. Several times now, my code has gotten messed up because of an “i” value in a for loop. It’s best to illustrate this with JavaScript code:

var funcs = []; for (var i = 0; i < 3; i++) {   funcs[i] = function() {     console.log("My value: " + i);   }); }

What do you think will happen if we call funcs[0], [1], and [2]? We get “0,” “1,” and “2”? Nope. Each one will log “3.″ Because the loop ends when i becomes 3. And those functions are still tracking that very same i later when you call them. They don’t remember what i was when they were created unless you do something special. 

So what can you do? You can create an IIFE to immediately invoke the function and thus freeze the value of i, or play with inner variables that hold an old i value, but the best way might be “bind.” With “bind” you can hard-set the variable inside the function to always be the value of i at the time you create it. Like so:

var funcs = []; for (var i = 0; i < 3; i++) {   funcs[i] = function(x) {     console.log("My value: " + x);   }.bind(this, i); }

Don’t worry about the “this” here; mostly what the bind is doing is setting the “x” inside the function to always, always be the value of i right at the moment bind happens: 0, 1, or 2, depending on where in the loop we are. Neat!

I had an excellent first week learning JavaScript and Friends at Fullstack. That humble little place just off Wall Street holds a wealth of coding knowledge. I was challenged but not totally destroyed (I only had one coding-related dream all week, thankfully), and mostly just happy that it’s a comfortable, non-competitive, friendly environment with a lot of smart and interesting folks who I’m looking forward to getting to know. Favorite moment? Maybe getting that bastard known as a binary search tree, or BST, to work via code. Suffice it to say that if I call you a BST in the future, it’s not a compliment. Right on cue, as I finally reached a long-awaited weekend, a cold that, I guess, had been waiting in the call stack (Javascript humor! Get it? I’ve been opened up to a whole world of bad jokes in the last week), finally got executed and I’m laid up on a perfectly nice Saturday.

In the spirit of keeping this blog actually useful to coding newcomers, here are a few pieces of Javascriptiana that are really important to know, as in they can waste you lots of time if you don’t know them. I’ll tentatively call this series Code and Stuff As Will Break Her:

--Objects are passed by reference, values are passed by copying. Don’t let anyone generalize to you about JavaScript variables, calling them, misleadingly, ‘tags’ that can get passed around to different things, or ‘containers’ that hold things. Both and neither are true. When a variable is assigned to a value (i.e., a string, a number, a Boolean), the variable stores a copy of the value itself. It don’t care where it got it from. If the original value changes, the variable won’t change with it. Objects, on the other hand, get passed in to variables by reference. The variable points to the object but doesn’t ‘know’ what's in the object. It’s like knowing of someone without really knowing them. So if the object changes, the variable will point to that changed object. It’ll keep track of it until it’s reassigned or the object becomes a value.

--When you make something a ‘form’ in your HTML, it will automatically reload the whole page when submitted. Using a form instead of a button delayed getting a lot of functionality in a game I built, because everything I had changed in the state of the page was erased every time the form was submitted. Buttons are buttons, just like the form button, but don’t reset your page.

--Maybe the biggest thing: buttons don’t care what your current ‘this’ context is. They automatically reset it to themselves when clicked. I was scratching my head wondering why the buttons simply wouldn’t link to the functions I had associated with their click events. It’s because the functions were being called from the context of the button itself. How to hard-set context? My acquaintances ‘call,’ ‘apply,’ and ‘bind,’ who are growing on me after a rough start.