Closing Thoughts on Big Nerd Ranch’s Front End Web Class

I posted a few thoughts while I was attending the Front End Web class last week and I figured I’d put a cap on it with some final thoughts.

Disclaimer: If you happen to find this post and don’t know, I do in fact work for Big Nerd Ranch, so yes I’m partial but these are still my honest opinions.

Who is this class for?

Like other BNR books and classes, there is an expectation of some experience. You don’t need to be an expert by any means for this class but you should be comfortable with the basics of web design, hosting and how the web works. If you are looking for these beginner skills I’d recommend Code School and/or Code Academy.

With the basics taken care of, this class provides an accelerated but thorough tour of modern web development and the toolchains that you need to know. The class is great for people like myself, who have a history of web development but have been out of the game for a few years or mostly focused on the backend systems. Others who would find value include those who are looking to jumpstart a new web skill set for a new job or project.

Having a full week to escape the distractions of work and personal obligations really enables you to focus on the class at hand. Combine this with guided lectures and an experienced instructor to answer questions and discuss patterns, really elevates the value to “priceless”.

The Syllabus

The table of contents titles don’t really do justice to the details of each chapter. In total we build four separate projects:

  • The first had us work with HTML5, CSS and JavaScript to do a moderately complex layout of a slideshow like page that included animations, responsive layout and modern markup techniques.
  • The second project was a Coffee Order system the helped us use HTML5 forms, Bootstrap styles, and JavaScript to communicate with a backend via AJAX.
  • The third project was a chat app, that utilized web sockets. For this app we not only built the front end but the backend too, in Node.js.
  • The fourth and final project was an EmberJS app that would have us catalog monster sightings. Ember is a big framework but I think the book does a fair introduction. We got to work with a relationship of models, and executed all the big features.

I thought the chapter and project progression went really well. There are some who might prefer to end with Angular or React instead of Ember but the good thing to know is the early class concepts give you a great JavaScript foundation to build on so you’ll be empowered to experiment with all of those projects and more over time.

That is a core value of Big Nerd Ranch classes that I really agree with. They teach you from the bottom up so you can understand how things work and not just how to assemble/configure things.

The Extras

There is lots of open lab time at night. You are encouraged to bring a side project to work on. While I did make some progress on my own project, an Ember Wiki project (I have some basic models and forms working, all backed up my a Firebase persistence layer), I did have to dedicate some lab time to the book itself to make sure I kept up.

In the afternoons we’d have time for a walk around the resort and on some of the days we even arranged for a shuttle van to take us to some of the exhibits, like the Birds of Prey and the Butterfly Center. Considering how focused we are during the class, these excursions are very welcome and a great way to clear your head and get a second wind.

Final Thoughts

If you want to learn a new technology, in this case Front End Web Development, and in particular if there is a time-sensitive nature to your needs it’s hard to imagine a better environment than a Big Nerd Ranch class. The ticket price does include lodging and food for the week so keep that in mind when shopping around or putting together a formal company request. If you have any questions, feel free to contact training support. They’ll be happy to help you out.

Mid-week Checkin

It’s Wednesday night and as expected it’s been both an exhausting and rewarding week so far here at the Front End Web class. Here is the table of contents we’ve been working through:

  • Introduction
  • Chapter 1: Setting Up Your Development Environment
  • Chapter 2: Setting Up Your First Project
  • Chapter 3: Styles
  • Chapter 4: Responsive Layouts with Flexbox
  • Chapter 5: Adaptive Layouts with Media Queries
  • Chapter 6: Handling Events with JavaScript
  • Chapter 7: Visual Effects with CSS
  • Chapter 8: Modules, Objects and Methods
  • Chapter 9: Introduction to Bootstrap
  • Chapter 10: Processing Forms with JavaScript
  • Chapter 11: From Data to DOM
  • Chapter 12: Validating Forms
  • Chapter 13: Ajax
  • Chapter 14: Deferred and Promises
  • Chapter 15: Introduction to Node.js
  • Chapter 16: Real-Time Communication with WebSockets

And what’s up next:

  • Chapter 17: Using ES6 with Babel
  • Chapter 18: ES6, the Adventure Continues
  • Chapter 19: Introduction to MVC and Ember
  • Chapter 20: Routing, Routes and Models
  • Chapter 21: Models and Data Binding
  • Chapter 22: Data: Adapters, Serializers and Transforms
  • Chapter 23: Views and Templates
  • Chapter 24: Controllers
  • Chapter 25: Components
  • Chapter 26: Afterword

Entering the class I was a little worried that my past web development experience would have made the early chapters moot, but to my enjoyment there is a lot of new web features and tools available since I did Rails full time back in 2012. Flexbox is particularly interesting and has me excited to do some testing to see if it will help me solve some layout concerns I have in my side project.

I also enjoyed the time we’ve spent working in pure JavaScript. We built out a very modularized system that would react to a simple coffee order page. I appreciate how we’ve taken the time to learn JavaScript from the bottom up. It makes you better understand and appreciate what more advanced tools like Babel and Ember are doing.

Tonight we closed with web sockets which is something I’m really hoping to embrace on future projects. Live content, no reload and real-time collaboration is where it’s at.

And then of course comes the “ranch” venue itself. Being able to get away and focus on the learning is priceless. Afternoon walks help clear your head. Here are some photos. Wish you were here. 🙂

Greetings, from the Ranch

One of the great perks of working at Big Nerd Ranch is that you are allowed to take one Big Nerd Ranch class a year. This week I’m taking the Front End Web class, and am really looking forward to it.

At nights we are encouraged to work on a side project to help practice what we are learning in the day. I think I’m going to work on a wiki app — with a few touches that I myself have an itch for, drag and drop image uploads, code syntax coloring, and more.

I’ll check in later through the week. Wish me luck.

Philly Craftsmanship

Software as Craft Philadelphia

A community of professionals dedicated to well-crafted software

Was very happy to attend the inaugural meeting of this group last week. Was a great mix of discussion and hands-on coding/pairing. Thanks to Promptworks for hosting.

During the discussions, the Software Craftsmanship North America conference (as well as its manifesto) were mentioned. You can find a bunch of the conference videos on the eighthlight vimeo channel. Seems like pretty interesting stuff.

In related news (since I think all hosts were in attendance at said meeting), I want to give a plug to the podcast Turing-Incomplete podcast. Finally starting to catch up on this Philly showcase of talent and really enjoying the discussions. Keep up the good work!

Side Projects

Sorry for the dead air over the last few months. Things got a bit hectic at my job and I couldn’t seem to find the free time to post. On the plus side, things are starting to calm down. We’ve shipped some more software and I’m finally catching up with some side projects.

One project which I started at the March CocoaHead Hackday is GoldCards. It’s an iOS reference tool for Hearthstone.

  • GoldCards Screenshot 1
  • GoldCards Screenshot 2
  • GoldCards Screenshot 3
  • GoldCards Screenshot 4
  • GoldCards Screenshot 5
  • GoldCards Screenshot 6

While I want this to be a Universal (iPhone and iPad) app in time I think I’m going to finish up a few more loose ends and release it as an iPhone-only app for now.

Another big side project is CocoaLove, an iOS-focused conference coming to Philly. I’m on the planning committee (sponsorship and AV to be specific). I’d also like to help build a simple conference app with the schedule and what not. Shouldn’t be too hard considering my history with such things.

In addition to all that I’m also trying to catch up with some web tech, Ember and Node to be precise. There are a few things on my idea board that could utilize such skills so I’m taking some time reading books and going through Code School examples to catch up.

Updating Homebrew’s “httpListenAddress” Default for Jenkins

I’ve setup some Jenkins servers in the past for Ruby on Rails apps but these days we are trying to get things running for iOS deployment and testing at work.

To experiment with some plugins and such I have my own Mac mini and installed Jenkins via Homebrew. Overall it’s working great though I was a bit stumped as to why I couldn’t load the Jenkins webpages outside of using localhost:8080 on the Mac mini itself. Worked fine last I did a clean install.

Turns out the Launch Agent settings Homebrew gives you (located at ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist for me) will launch with the following command line parameter --httpListenAddress= Edit this to (the default) to allow all addresses.

I know this isn’t the most enjoyable blog post but wanted to post it as Google Food for others who might run into the issue.

Other related posts:

Early Ember.js Thoughts

Over the last three weeks, I’ve been slowly picking up Ember.js while helping some colleagues with a project. It’s pretty interesting tech and I’d like to share some early thoughts.

What is Ember?

To be frank, I don’t think the Ember homepage does a very good job of explaining Ember. It features terms like “less code” and “developer ergonomics,” which are too much like “marketing speak” for me.

How I view Ember. Normally with a web app, you (as a user) will go page to page, sometimes viewing data and then sometimes editing data with forms. That’s what I’ll call a form-based web app. Sometimes you might want a bit of AJAX in these form-based web apps and, to get that, you’ll typically grab a DOM element and manually shove in a bunch of jQuery when needed, including direct commands and event callbacks. This process can work, but the more AJAX and client side stuff you add, the messier you can make things.

Then there is a class of web apps which work as one-page apps, where all interaction and DOM changes happen on the fly, without moving from page to page. Data is sent to and requested from the server in the background. Think of how Gmail and Trello work.

For me, Ember.js is all about giving you the toolchain to provide those types of dynamic, one-page web app experiences. Ember.js is a full stack, client-side, JavaScript-based MVC framework. The main objects you’ll work with client-side in the browser include:

  • Routers, which match the requested URL to controllers. They also ensure that the client URL is updated to allow the user to bookmark the different states of your app.
  • Models, to define your business nouns and store/retrieve user data.
  • Controllers, which handle actions and pass model data to the views.
  • Views to connect user events like clicks and taps to controller actions.
  • Templates to describe the HTML on screen.

Some Notable Features


If you’ve done AJAX work before, you might recognize that knowing what to update in the DOM can be a nightmare as the app state changes on a given page. Ember is particularly good at dealing with this, and as you build your HTML templates, the substitution hashes like {{ name }} for a person’s name not only are substituted for the real value on the first render, but everything is always kept up-to-date with an internal bindings system. This, combined with calculated attributes, really takes a lot of stress off the developer, in terms of keeping the app state in sync with the UI state.


For actually persisting the data, there is the ember-data project which will let you connect and map your client-side Ember models to REST endpoints. If you are using Rails, there are a bunch of gems that can really help to simplify this while providing all the serialization and API endpoints you’ll need. For more info, see this article.

Sharp Edges

As of this writing, Ember itself is version 1.0.0-pre-4 and ember-data is officially considered alpha quality. There is an upcoming Ember Camp, which hopes to see continued progress towards an official 1.0 release. Keep an eye on the Ember blog for more info. I do believe things have settled down to a point where there is value for people who want to get started with Ember and get their hands dirty. As to “production ready” — well, that will greatly depend on the needs of your application and your comfort with working around some sharp edges.

Getting Started

If you’d like to get started with Ember, in addition to the main website, which has some nice and ever-improving documentation, I’d also recommend:

If you are in Philly, also consider stopping by the local Ember Meetup.

Researching New Web Tools

I’ve been spec’ing out this app idea off and on for a few months. At first I was going to do it on the Mac, but, as time passed, I decided to make it a web app in the newer style instead. Not a “present form, hit submit, view results” kind of thing, but something that is always saving and receiving messages from the server — very dynamic.

I’m actually blessed that there are a number of great web tools, libraries, and frameworks to choose from these days. One great overview I read last night was Rich JavaScript Applications – the Seven Frameworks by Steven Sanderson. It does a great job listing and categorizing some of the more popular choices out there. New to me on the list was Meteor, and I consider its video a must-see.

I’m still getting my head around many of these things. My general battle plan is to continue reading and playing with the example code of my CoffeeScript book (which also has some basic jQuery and NodeJS stuff), and then work through some of the various implementations of TodoMVC to see what tech speaks to me.


TodoMVC is a project that offers the same Todo application implemented using MV* concepts in most of the popular JavaScript MV* frameworks of today. These frameworks include Backbone, Ember, AngularJS, and Spine, to name a few. TodoMVC offers a great way to see how different stacks approach the same problem.

Other tools that are relevant to my cause and look promising include:


Ace is a standalone code editor written in JavaScript. Our goal is to create a web-based code editor that matches and extends the features, usability, and performance of existing native editors such as TextMate, Vim, or Eclipse. It can be easily embedded in any web page and JavaScript application. Ace is developed as the primary editor for Cloud9 IDE and the successor of the Mozilla Skywriter (Bespin) Project.


ShareJS is an Operational Transform library for NodeJS & browsers. It lets you easily do live concurrent editing in your app.

While I personally have a lot of Rails experience, I’m not going to shy away from NodeJS and other solutions. I almost welcome the opportunity to try something new these days. I’m also very excited to see that the NodePhilly group has gotten off the ground — I hope to make the next meeting in September.