Tech from the previous week: Bower, Backbone, and CoffeeScript

It’s funny how time perception is so easily manipulated. After 3 weeks of immersive education, I forget what day of the week it is. My fellow students also think time is passing by really quickly despite how many hours per day we spend in one (big) room.

Weekends are limited to Sundays due to the 6-days-per-week schedule, so Fridays don’t feel like Fridays (so to speak). However, I should note that Saturdays at Hack Reactor are less intense than other days because the weekly social nights replace the final few hours of the daily classwork with entertainment. Social nights are optional, and plenty of students decide to spend that time working.

More varied thoughts from week 3

• I’ve stopped using pen + paper. I probably didn’t need to buy notebook for this course, and I’m just not a fan of paper. Hopefully my lack of note-taking won’t bite me later. Hack Reactor provides some good online notes, diagrams, etc, but I’m not sure they’ll be enough when it comes time to study for job interviews. That said, I’m not too worried.
• Gym time is limited. Students get 2-hour lunch breaks every other day, but it takes at least 10 minutes to walk to the gym, a few minutes to change clothes, a few minutes to shower, 5-10 minutes to buy lunch afterwards, etc. Actual workout time is roughly 45-60 minutes max. A lot of us have ended up eating during the post-lunch lecture, so I guess it’s all good.
• Hack Reactor hosts various meetups throughout the week (Coursera study group, general JS meetups, etc). I think that’s a pretty cool way for them to help out the greater dev community.
• Burnout watch: I still feel pretty excited to go to Hack Reactor 6 days per week, but I definitely look forward to relaxing on Sundays. In my previous blog post, I lamented about spending free my limited free time to write substantive blog posts, but now I think they really help me exercise my memory to prevent that “it was all a blur” feeling.

Recap of Events

Industry Event: Firebase

Sadly, I didn’t attend the Firebase meetup hosted at Hack Reactor HQ. I heard from fellow students that the Firebase tech is pretty sweet. Firebase devs gave a demo that impressed many with promises of data syncing hotness.

Why didn’t I attend the event? My pair programming partner and I decided we couldn’t spare any time for the event because we were more concerned with Backbone. Firebase just happened to come around at a bad time for me.

Social Night: Movie Theater

Yesterday, many students went to see Gravity (in 3D IMAX format). It was pretty friggin’ fantastic. Afterwards, some of us went our separate ways, some went back to studying/working, and some went out to partake in beverage consumption.

What I Learned

Quick tip: I learned a tactic for dealing with low brain energy. When I’m tired of analyzing software architecture decisions or concocting algorithms, I can give myself a productive break by switching to CSS work. Changing gears from program development to applying styles and designing layouts works wonders to give certain parts of my brain a rest while exercising others.

Most Hack Reactor assignments come with some pre-written code, but they often come devoid of any interesting visuals so that you can practice CSS skills.

Bower

Not much to say here. Students got a very brief lecture about Bower, but it didn’t take much time to convince me to use it. Easily manage libraries/dependencies with a few terminal commands? Nice. bower install = woot!

Inner workings of the web (HTTP/AJAX, full stack overview)

Students have yet to write any server-side code, but we’ve dealt with programming small client-side apps that interact with servers. We were taught some AJAX skills and some general HTTP knowledge. One lecture covered the overall system architecture that describes client-server interaction. There were so. Many. Terms: local storage, sockets, page requests, asset requests, client vs server MVC, content delivery networks (CDNs), object-relational mapping (ORM) –good times.

Backbone

Most of the week 3 assignments involved Backbone, which forced us students to really change the way we think about designing software. Developing with Backbone means organizing code to follow paradigms involving models, views, and collections (not quite MVC –which is “model view controller”).

Before Backbone (a JavaScript framework for providing web apps with structure) our code was a like a stream of consciousness. With Backbone, our code was given order, structure, and rules to follow. It was a tough, but rewarding adjustment. Students were struggling with the process when initially exposed to Backbone. It’s funny because we were all questioning the effectiveness of Hack Reactor’s curriculum at first, but by the end of the week, most of us feel much more comfy with the framework.

Imagine you could only teach via stream-of-consciousness statements. Content would be expressed, but it would be messy as hell. Now imagine you were forced to teach by writing a well-structured, well-organized textbook. The difference is staggering. Suddenly you need to think about organizing concepts into topics, sequencing topics, connecting topics, etc. Making the leap from using no framework to using Backbone isn’t quite as drastic, but it’s still a tough contrast to get comfortable with in just a few days –even if those days involve ~12 hours of learning.

CoffeeScript

Before my time at Hack Reactor began, I was open to the idea of learning CoffeeScript (a more expressive, human-readable programming language that compiles into JavaScript, allowing you to write JavaScript with a very different syntax) because it looked friendly in the same way Ruby looks friendly. After a couple of weeks of writing lots of JavaScript code, I was far less open-minded about spending time learning a drastically different syntax. Imagine being told you were going to take a break from learning intermediate Spanish so you could learn beginner Portugese. You’d say, “No thank you, crazy person.”

After finishing the CoffeeScript sprint, I remain somewhat ambivalent. I don’t love it, but I don’t hate it. The whole experience taught me that learning new syntax isn’t so bad.

Last updated on Oct 13, 2013 to fix a typo and embedded a tweet.

Awesome of the @Airbnb team to visit @HackReactor. Picture of them talking about their tech stack. pic.twitter.com/AYVDYA3JaT

— Ben Martin (@HealthfulHacker) October 2, 2013

I don’t know if my summary of week #1 made it clear or not, but although my first six days at Hack Reactor were tough, I didn’t exactly struggle with any of the material. This is probably because the pre-course work was incredibly difficult, thereby infusing me with helpful knowledge while also shaping my expectations.

Well guess what? Week 1 was an anomaly. It was a week filled with more lectures and less hands-on programming. I knew this ahead of time, but week 2 still caught me off guard. There was quite a bit more learning with minimal guidance. Also, the joys/stresses of pair programming are turned up a few notches as a result of the additional programming time created by reducing the amount of lecture time.

Consequently, I’ve been feeling more tired in general. Forgive me, but spending my free time to write this blog is beginning to look less and less appealing.

I joined a nearby gym (aside: I just remembered that I need to notify Hack Reactor to get my $50 reimbursement from them!) so my energy levels should increase in a week or two. Every other lunch break is two hours long instead of just one hour long. The extra time is meant to encourage students to go exercise.

I want to write more about student life at Hack Reactor, but I think I’ll just spread out the details in my HackR Diary series rather than providing every bit of info in a single, giant blog post. So for now, I cover gym time, toy problems, and tapouts. In the future, I’ll discuss the workstations, help system, student-staff interaction, food, and more.

Week in Review

Toy Problems

This week, my cohort, the junior students, started solving (almost) daily toy problems, which are small coding challenges designed to get us used to the type of timed problems that will be thrown our way at tech interviews. We have to complete these problems individually. We have 30-60 minutes to think of a solution, code the solution, and submit pull requests to have an automated tester give us feedback that we can use to help fix our solutions as necessary.

Tapouts

This week, us juniors also started attending weekly(?) tapouts. Tapouts are like small group therapy sessions where five students voice their opinions of Hack Reactor to an alumnus. She will send anonimized feedback up the chain while also providing us with advice for any struggles we care to talk about.

Special Event: AirBnB Presentation

Lead devs from AirBnB presented a ton of info about their tech stack, their work environment, their open source project, dev career advice, startup advice, etc. There was a post-presentation panel for answering several questions. Then there was a post-panel meet-and-greet session. It was a truly fantastic event.

Saturday Social Night

I skipped last Saturday’s social night to go to a close friend’s birthday celebration(s). Week 2’s theme for social night was board/card games.

What I Learned + What I Thought

Inheritance/Subclassing in JavaScript

The subclassing sprint was a bit frustrating at first. It took me awhile to grasp the keyword this because of JavaScript’s tendency to pass functions around as parameters to other functions.

Upon wrapping one’s brain around this (and the .call()/.apply() methods), there was a lot of fun to be had with the assignment that Hack Reactor gave the students. This was the first assignment involving a visual facet, and the student body reacted accordingly (with creativity galore).

Algorithms

The algorithms sprint was a fantastic challenge, but there was no specific set of knowledge to learn. It felt like the main goal of the sprint was to get students’ minds thinking in more computer-oriented ways. We were taught some basics about time complexity, but we didn’t go into much depth about Big-O notation. We briefly described actions (e.g., deleting data from an array) and algorithms (e.g., solutions to the n-queens puzzle) as constant, linear, quadratic, polynomial, and exponential (as opposed to discussing the nuances of O(c), O(n), O(n^2), O(n^c), O(c^n), etc).

The main takeaway was that we should worry more about macro optimizations (storing data in variables in a way that allows for constant-time lookup) rather than micro optimizations (improving a for loop so then it loops fewer times). Micro optimizations are good, but they aren’t very valuable when you’re just creating prototypes, minimum viable products, etc.

I’m somewhat disappointed that we weren’t taught specific algorithms such as quicksort, binary search, etc. I’m under the assumption that all software developers need to know the “greatest hits” of algorithms. Although, I’m also under the assumption that such knowledge is more useful in tech interviews than in day-to-day coding.

Layout/Positioning (HTML/CSS)

I taught myself a decent amount of HTML/CSS before my cohort’s start date, so I was very comfortable with the layout assignment, but it wasn’t easy. There are still plenty of times when proper CSS positioning eludes me. That said, this topic doesn’t provide an intellectual challenge.

The difficulty lies in getting the syntax just right and understanding hierarchy. Some students didn’t learn much HTML/CSS before joining Hack Reactor, and so they had a lot to learn (box model, DOM hierarchy, CSS selectors, etc.) in a very short amount of time.

If you’re thinking of joining Hack Reactor as a student, I highly recommend you teach yourself HTML/CSS ahead of time. HTML/CSS isn’t tough to learn on your own, but it can be time-consuming even if you’ve got pros helping you. You may as well prepare yourself so then you can spend less time at Hack Reactor worrying about HTML/CSS and more time worrying about other technologies and concepts.

D3 (library)

D3.js is a JavaScript library for creating data-driven visuals inside HTML documents. I thought jQuery was cool, but now I think D3 takes the cake. It’s much harder to learn D3, but there is tremendous power to be had from familiarizing yourself with it.

That said, the D3 assignment left me mentally tired as hell. Like jQuery, you can easily select DOM elements, but the rest of the D3 syntax isn’t so straightforward, and the general concepts for using D3 properly will feel rather foreign at first. I hope to spend more time on my own to master D3 …when I’m not so damn tired. The key is to understand the general update pattern.

Last updated on Oct 1, 2013 (minor edits).

Good way to start week 2 at @HackReactor pic.twitter.com/6pB80gQKCO

— Jeff Lee (@RebootJeff) September 30, 2013

This post is a bit late, but it can be hard to find time to write up a thorough blog post when I’m studying at Hack Reactor for 70-80 hours/week. During my free time, it’s tempting to just play Hawken or catch up on YouTube (yes, I subscribe to some damn good channels).

Quick correction: In my previous HackR Diary entry, I said that the staff gets a 1-week vacation every 7 weeks (6 weeks of work followed by a 1-week break). This isn’t entirely true. The interim week can be used as vacation, but staff also use it to make changes to Hack Reactor. For example, the most recent interim week was used by staff to rearrange the lecture room, which involved installing a new projector screen.

Week in Review

I wake up everyday Mon-Sat at 7:30am. I should really wake up earlier so then I can arrive before 8:50am. I rely on the BART (subway) to get to/from Hack Reactor. I make my subway rides more enjoyable by saving YouTube videos as .mp4 files to my phone. I generally watch documentaries on cosmology and nature featuring British narrators. The accent is key. If you’re interested in such documentaries, check out this link and this link.

Ok enough of that. You came here to read about the intersection of start-up life and student life, not BBC on YouTube. Here’s a quick recap of what I was up to last week:

• Learning: 2 “standard” sprints + 1 longer sprint
• Reflection: Provided feedback on what students did and didn’t like about week 1.
• Week 0 self-assessment: An ungraded quiz to force you to ask yourself how confident you are about what was taught in the pre-course work.
• Code Review by seniors: The “upperclassmen” took a look at our data structures solutions.
• Social Night: Visited House of Air, a sweet trampoline gym.

What I Learned

• Sprint #1: Recursion
• Sprint #2: Mini-clone of Underscore.js
• Extra #1: Advice for Success
  • Hack Reactor’s role in students’ success
  • Students’ role in our own success
• Extra #2: Debugging
  • debugger; statement
  • Sources tab in Google Chrome dev tools
  • Call Stack in Sources tab
• Sprint #3: Instantiating Data Structures with various Class Patterns
  • Class Patterns
    • Functional (with and without shared methods)
    • Prototypal
    • Pseudoclassical
  • Data Structures
    • Stacks
    • Queues
    • Linked Lists
    • Trees
    • Sets
    • Hash Tables

What I Thought

Lectures

Week 1 is very different from most weeks due to the amount of lengthy lectures we have to sit through, but ya know what? I really liked the lectures. The main instructor for week 1 is Marcus, and he’s pretty great at teaching. Students constantly ask questions during lecture so it feels much more interactive and much less like being force-fed information.

I like that lectures involve plenty of analogies, live coding examples, industry best practices, and “every interviewer will ask you about this” moments. You’d think students would get pretty tired of all the lectures, but they’re too good to be off-putting. Also, 5+ hours of lectures per day isn’t a lot when you consider we’re spending 12+ hours per day at the school.

Paired Programming

I generally like the idea of paired programming so long as you have a good dynamic with your partner. That said, it can be really tiring because you’re constantly talking as you and your partner are coding. Not only are you exhausting your brain’s cognitive abilities by working on programming challenges, but you’re also exercising verbal comm skills and listening skills. It can be tough to listen to your partner explain his/her solution when you feel like you’re on the brink of working out your own awesome solution in your head.

The School

Hack Reactor is a fantastic environment, and I know every student of every bootcamp says this, but it’s just so amazing to be in a school where the students and teachers are all so pumped to be there. On top of that, the students are open-minded without being naive. Basically, Hack Reactor is filled with the positive vibes that should make every college wildly jealous.

It’s also worth noting that Hack Reactor is transparent. They’re a small company, and their small size allows them to build a tighter community of teachers, students, and alumni. I love that Hack Reactor staff is very honest and genuine. When cynics look at the relatively expensive tuition, it’s tempting for them to say HackR is “in it for the money,” but check out a lecture or listen to them explain their intentions and you won’t hear a sales pitch. You’ll hear earnest intentions to educate the next generation of developers using next-generation methods.

Last updated on Sep 28, 2013 to edit section on guard operator.

It’s the end of day #3. I don’t have much time to write, so this blog post is a smattering of thoughts from a fresh Hack Reactor student.

Initial Observations

Recap

• Day 1 and 2 are just review days covering topics and challenges covered by the pre-course work. Day 1 covered ettiquette, expectations, and recursion. Day 2 covered passing functions, a lot of JS fundamentals, and awesome advice for being successful (e.g., we talked about impostor syndrome, Hack Reactor’s motivations, some job-hunting advice, etc).
• Day 3 covered paired programming, object-oriented programming (OOP), and classes (e.g., functional instantiation vs. prototypal instantiation vs. psuedoclassical instantiation).

Logistics

• Week 1 is full of lectures. Each day is about 50% lectures, 50% coding.
• The first 6 weeks will have plenty of lectures and structured challenges. Then there is an interim week where you work on a project from home, which gives you the flexibility to travel, but the Hack Reactor staff will be offline (they basically get a 1-week vacation every 7 weeks). After the interim week is more time for your individual project, time for a group project, and time for job prep.

Nuances

• Lunch breaks and dinner breaks are often cut short due to lectures running long.
• Lectures run long due to people asking questions.
• All teachers advocate for students to ask questions. At Hack Reactor, the students ask a TON of questions because the class atmosphere is very comfortable.
• The students are really nice. Everyone’s excited to meet new people (even the quiet ones are clearly motivated to be social).
• I’ve heard stories of students of other bootcamps going out at night to hang out and have fun. I could be wrong, but so far it seems like there’s no time/energy left for going out at night.
• That said, students don’t stay here that late (so far). A lot of us leave by 9pm. I thought it’d be common to leave no earlier than 10pm, but there aren’t even that many students from the senior cohort by the time the clock strikes 9:20pm (which is the latest I’ve stayed). I have a feeling this will change in a few weeks (beause that will be crunch time for the senior cohort).
• Nothing’s perfect. Some equipment is broken, some chairs are shitty, some online resources are buggy, etc. None of these issues have been big issues.

Nuggets of Knowledge

I’ve picked up a lot of cool (and oftentimes valuable) advice/facts in just 3 days.

Life Nuggets

Re: Education

Passive learning is deceptively similar to true understanding. When you just observe a correct solution, it can give you the illusion that you learned more than you really did. For example, you might watch someone code up a good solution. When you walk away, you’ll think you understand everything necessary to solve the problem, but all you learned was some code without its meaning.

Re: Starting a new tech career

Everyone thinks starting a new tech career with a tiny startup is really exciting. That might be true, but people tend to forget an important caveat: less structure could lead to a less efficient roadmap to individual success.

In less formal terms, you might work for a tiny startup on something you truly care about, but the startup could easily be too small or too young to provide an environment with superiors/peers that can help you develop your programming skills (or any job-related skills).

JavaScript Nuggets

Guard operator

Marcus, the primary instructor, warned us that some devs dislike the guard operator, but it’s really concise (which is cool to him). The guard operator is a logical-AND or logical-OR that “guards” a small bit of code the same way an if statement would guard it. For example:

if(goodStudent === true){
    candy++;
}

// The above code could be refactored into the following:
goodStudent && candy++;

The following is a more practical example:

// Let's say you want to only call a function with an array if the array is NOT undefined (i.e., you want to guard against a scenario where you pass an undefined argument to a function).
arg && myFunction(arg);

You can also use a logical-OR in a guard-like fashion. This is sometimes called the default operator rather than a guard operator.

// if no name was passed into the function, just give the name variable a default value of 'friend'

var sayHello = function(name){
  if(name === undefined){
    name = 'friend';
  }
  console.log('Hello, ' + name + '!');
}

// the function above could be refactored to use the OR-guard as follows:
var sayHello = function(name){
  name = name || 'friend';
  console.log('Hello, ' + name + '!');
}

Thumbnail of my Twitter clone assignment

Tomorrow is a huge day for me. Tomorrow is when I start attending Hack Reactor. I’m about to go from funemployment (going to bed at 4am; waking up at 12pm) to immersive student life (spending 80 hours/week on “campus”). I will write about my journey from amateur to trained pro in a series of blog posts called HackR Diary.

Mandatory Pre-Course Work

I enrolled in tomorrow’s Hack Reactor cohort back in late August. So I had a month to get through some pre-course “homework.” Some bits of the homework were harder than I expected (e.g., functional JavaScript challenges); some bits were easier than I expected (e.g., creation of simple Twitter-like front-end). The Twitter clone challenge was actually really fun for me because I like a challenge that actually includes a front-end.

There were times I was frustrated because I felt like I would be doing a lot better with just a little bit of help (e.g., recursion challenges), but I didn’t ask for much help, so I did a lot of solo struggling. However, one of the biggest bummers was going through the Backbone.js assignment. The assignment was to simply complete the Code School Backbone.js tutorials (two of them). Hack Reactor provided me with a Code School membership, and I was excited to take advantage of it, but that particular set of Code School tutorials isn’t very good at teaching. I felt like I didn’t get a good grip of the concepts (models/collections, views/rendering, routers).

I’m also a bit jaded when it comes to online tutorials. They generally do a lot of hand-holding to the point where you don’t retain much info, and if you get stuck on something, you’re a bit screwed. My low patience for tutorials is part of why I decided to enroll in a bootcamp, but there I was: doing tutorials as part of bootcamp homework! Don’t get me wrong, online tutorials are great resources in general, but I can only take so much. Eventually, I’d rather do some Coderbyte challenges instead of Code School challenges.

Pre-Course Check-In Meeting

Hack Reactor makes incoming students meet with a Hacker-in-Residence (basically a Teaching Assitant?) to check up on the pre-course homework. I heard that some students have been weeded out of the bootcamp by the homework.

I met with an H-in-R named Bianca. My meeting was done in person, but these check-in meetings are sometimes conducted via webcam for those who haven’t arrived in San Francisco yet.

Before the meeting, I was pretty worried about how I stacked up compared to my peers. We’re not experts (hence the desire to enroll in a bootcamp), but we’re supposed to be much better than a typical beginner because the admissions process was not easy. During the meeting, Bianca asked me how I felt about the three biggest parts of the pre-course homework: the functional JavaScript challenge involving test-driven development (TDD), the rudimentary Twitter front-end clone, and the JSON recursion challenges.

I anxiously watched as Bianca scrolled through my code. After discussing some questions I had, issues I struggled with, and solutions to my few bugs, I felt a lot better. Maybe I put too much pressure on myself, but I tend to worry a lot. I walked out of the conference room feeling very positive.

Other Pre-Course Work

Hack Reactor suggests completing more tutorials and reading some resources if students have some spare time before classes start. Suggested topics include Git, Node.js, CSS, Ruby, Ruby on Rails, and CoffeeScript.

I studied Backbone.js a bit more, I read about JavaScript best practices, and I spent a lot of time doing more Code School tutorials. Some are better than others. I mostly looked at HTML/CSS stuff, which sounds easy, but I just wanted to make sure there weren’t too many gaps in my fundamental knowledge (position and display properties still slap me around sometimes).

The Code School tutorial on the Fundamentals of Design was pretty awesome actually. It’s the only tutorial that doesn’t require coding, but it imparted quite a few cool nuggets of knowledge about how to choose fonts, colors, and layouts. The layouts part wasn’t as insightful (I wish they had you actually implement a grid with some coding), but learning about typeface categories (e.g., humanist vs. transitional vs. modern) and what defines a good color scheme (e.g., 60 degrees of hue separation) was sweeeet. Hopefully I’ll get around to blogging about the basics of fonts and colors one day. It’s just some very simple stuff that can help a lot.

Overall, I didn’t do as much studying on my own as I should have. I suck at independent study. Bahumbug.

I’m so friggin’ nervous!

Although the pre-course check-in meeting left me feeling optimistic about my future success at Hack Reactor, I no longer feel quite so confident.

This past weekend, I got access to my cohort’s Google Group. I bet that Hack Reactor nearly forgot to add me to the group. I browsed the group forum, and I saw posts dating back from July. There were some posts in August about meeting up to get to know one another before our Hack Reactor course starts. Doh! I missed those opportunities!

There was also a thread of self-introductions. Only a handful of people introduced themselves, but damn! They sound impressive. They make me worry about how I’ll compare. What’s funny is that a lot of them are non-Asians who have lived in China. They can speak Mandarin way better than I can (i.e., I only know a few basic words). Hopefully I don’t get a lot of flak. I already get enough grief from my mom.

My plans for blogging

Considering that I will be busier than I have ever been in my entire life(?), I probably won’t have much time for blogging, but I am determined to do a fair amount of blogging anyway!

I still have plenty of coding bootcamp research to blog about, but I will give my HackR Diary a higher priority. I’ve set a goal to blog about my experience at Hack Reactor at least once per week. Each diary entry will include a quick recap of topics taught by HackR staff, observational knowledge nuggets I picked up myself, and my personal evaluation of myself and the bootcamp.

I wanted a way to count visitors for my blog. Easy enough, right? Just sign up for a free Google Analytics account, obtain a tracking ID from the account, and add the tracking ID to Octopress config file…right?

Wrong. Maybe I was doing something else incorrectly, but I didn’t get things working until I did what a guy named Stefan Alfbo wrote about. I found his blog post via Google, which reminds me that my own blog’s Google-powered search doesn’t seem to work :(.

Problem solved

Here’s the trick for getting Google Analytics working on an Octopress blog hosted on Github: open up the source/_includes/google_analytics.html file and add…

// add this line to the series of _gaq pushes already in the code
_gaq.push(['_setDomainName','github.io']);

Questions remain

Alfbo recommends putting this new line of code in between the 2 existing _gaq.push statements. I’m not sure if the order of the _gaq array really matters, but I didn’t want to chance it, so I followed his recommendation. However, this left me wondering, “What is the _gaq array anyway? How is it used? And why does it need special attention to get it working with Github hosting?”