I’m still a beginner to Ember, but when I was just starting out, aside from learning from my instructor and the tutorials he created, I searched for a book that I could use to help get started. There are two books that I found and have been using to aide me in my learning of Ember, which I wanted to tell you all about today.

While some of the materials I found were a little outdated, one I settled on was called “ember-cli 101”. The book, now called “ember 101” is written by Adolfo Builes and helps you get started developing in Ember. It helps you build your first app, an app to help you keep track of items you lend to your friends, a bit different than the standard todo-list app and teaches you the main features of Ember CLI and how to use Ember Data.

The cool thing about this book is that it was recently updated for Ember 2.0 and continues to be updated regularly, plus it’s now FREE!. Although you can still pay for it to contribute, Adolfo said he wanted to make a stronger commitment with the Ember community and make it accessible to everyone. The book is also now released under a creative commons license so anyone can edit and contribute to the book, which is in the spirit of Ember itself, built by an open source community. The source code for the book can be found here. With almost 3000 readers already, you know it’s a good book to help get your started.

You can check out ‘ember 101’ here.

I wanted to mention one other Ember book that’s now available as well called “Rock and Roll with Ember.js” by Balint Erdi. I’m actually working through this currently. Although I only recently found out about it, the first edition of the book followed Ember’s journey to its 2.0 release. As with “ember 101”, this book also guides you through building a ‘real’ application to teach you all of Ember’s concepts.

Balint made the book extremely beginner friendly, starting with the very basics such as installing ember-cli and writing your first template and works his way up in complexity. It’s also pretty fun to be working in a book to build an app that’s Rock and Roll themed.

“Rock and Roll with Ember.js” is also being updated constantly so it stays void of deprecation warnings and promoting practices that are no longer considered idiomatic.

The book is a little more expensive. There are multiple packages that start at $39, there was a discount though when the new version of the book first came out, and the price goes up from there, packaged with other materials such as access to the source code in the book and screencasts.

Check out “Rock and Roll with Ember.js” here.

Whichever material you choose to help you on your Ember journey, know that these are both great resources and won’t let you down!

My initial apps only used the find method, which provides records of a single type, but there are others that can be used as well including findAll and findQuery. These initial apps weren’t backed by a database either so everything was loaded from fixtures and new records were destroyed upon a page refresh.

export default Ember.Route.extend({
  model: function (params) {
    return this.store.find('recipe', params.recipe_id);
  }
});

In a recent app, it was connected to a Rails API and was using the findQuery method to retrieve records from the Ember Data store. I didn’t write the initial code, I was only adding features to the app, so I wasn’t familiar with findQuery. In adding features to the app, I created a form to add new records and a function in my controller that would grab the data from the form and save the new record. I ran into one problem though. Although my Ember app was making a POST request to the Rails backend to save the record to the database, the DOM was not automatically updating with the new record.

// In my model:
model: function(params) {
  return this.store.findQuery('memory', params);
}

// In my controller:
addNewMoment: function () {
      let moment = this.getProperties('caption', 'content', 'location', 'happenedAt');
      this.store.createRecord('moment', moment).save();
    }

I felt like I had tried everything and couldn’t figure out why the record was saving to the database, but wasn’t updating on the front-end in my Ember app. It turns out the reason why my record wasn’t saving was because of the findQuery method in my model.

If you use the findQuery method, it puts the job of filtering on the server’s back. Ember Data assumes that the results that were returned initially are the only results that are associated with that collection, so it will only make the call to the database once. In this case, you can manually push a new record into a collection of records using pushObject.”

  // If using findQuery, something like this
  // will push the new record into the collection:
  var model = this.get('model');
  model.pushObject(moment);

This is when I realized that I needed to pay closer attention to the methods that I was calling in my models and started to learn what all the different ones will do for you.

Basically, findAll will return all the records of a specific type and will trigger a request to the server, all is essentially the same, but uses the cache, so if you have records in your store, no request will be made, findById returns a single object and as we discussed earlier, findQuery will return a subset from your server.

Here’s a bit more information in the Ember source code.

I hope this was helpful for other Ember beginners learning the framework.

There are many tutorials on the web to help teach you Ember like the one on Code School, but those that are sightly outdated, like the Code School one, won’t teach you to develop Ember apps with the Ember CLI, a command line interface for “ambitious web applications” and the generally accepted way to create Ember apps today.

Although Ember is written in JavaScript, I found it easy to understand much about how the framework worked because of similarities it shared with Rails, especially with the CLI.

Before we dive into the Ember CLI, I think it’s good to take a step back and ask what is Ember, just so we’re all on the same page. For those that aren’t familiar, Ember.js is a client-side JavaScript MVC Framework that provides bindings, observers, adapters, such as the RESTAdapter or ActiveModelAdapter, etc. Ember CLI on the other hand is a Rails-like helper for building Ember.js apps that provides a development server and build tools, generators, testing by default and add-ons.

There’s a lot that we can talk about with Ember CLI, but besides telling you how to get started with it, I’m going to focus on three main things: generators, testing and addons.

Getting Started + generators

To install Ember CLI, as long as you have npm (Node Package Manager) and NodeJS installed on your machine, all you need to do is run the command ‘npm install -g ember-cli. This may take a little while to install Ember CLI and Ember, which is just a NodeJS package, but once installed, we can immediately begin a new project by running ‘ember new my-great-app’, ‘ember new’ plus the name of our app/project.

For help installing, the Ember website has a tutorial, plus has another tutorial to help you build your first Ember app.

By running the ‘ember new’ command, we create a new project directory with different folders and files and install any packages or dependencies needed via npm. The great thing about this is that if you’ve seen a NodeJS app before and/or a Rails app, you have an idea of the layout and where things should be located. For example, in the app folder, you have additional folders and files for your components, controllers, models, routes and templates, etc.

Believe it or not, just by running this simple ‘ember new’ command, we already have a working Ember app even though it’s extremely simple and doesn’t do much. If we run ‘ember s’ or ‘ember server’, our app will be built and served to localhost:4200.

Now that we have our new app, we can start building it out and make use of Ember CLI’s generators. The generators in Ember CLI are very much Rails-like and can generate nearly anything including models, routes, controllers, components, adapters, tests… you name it.

To generate these, you just run ‘ember g’ followed by the type of thing and then the name of it. Here are some examples: ‘ember g model user’, ‘ember g resource album’ and ‘ember generate component email-component’.

One last thing that’s really awesome about generators, which will take us into the next topic, is that when you do generate something it will also create a test for you to test that new thing you generated.

Testing

Another thing that Ember takes from the Ruby/Rails world, is the ability to let you easily write well-tested code by including QUnit as the default testing library. If you aren’t a fan of QUnit, that’s okay since others are supported through third-party addons.

To run your tests, just run ‘ember test’ from your command line and the tests will be run and you can see the results right there. You can also re-run your tests on every file-change by running ‘ember test –server’ from the command line. These commands run your tests using Testem to make testing multiple browsers very easy. You can configure Testem using the testem.json file in your application root.

If you have your app built and served to a local server, you can just visit ‘http://localhost:4200/tests’ and view your tests in the browser.

One last thing to mention is that while using generators to generate code such as models or controllers will create tests for you, you can also generate your own tests such as an acceptance-test by running ‘ember generate acceptance-test’ then the name of the test. For example, here’s how I would create an acceptance-test testing login, ‘ember g acceptance-test login’, plus the test it generates.

Addons

The last thing I’d like to touch on with the Ember CLI are addons. This is a system that provides a way to create reusable units of code. You can think of them as similar to RubyGems.

Basically, if someone has already created code for something that is done by many, why should you have to reinvent the wheel?

Addons are installed by running ‘ember install ' and some addons that you could potentially add to your project could be 'ember-cli-materialize' to add a CSS framework for styling based off of Google's Material Design or 'ember-g-map', a simple way to integrate with Google Maps in your Ember app. One that I've used in the past was called 'ember-cli-showdown' that transforms Markdown into HTML, since our text wasn't styling correctly for one project.

Conclusion

Although you can create Ember apps without the CLI, that’s how you have to do it if you were creating an Angular.js or Backbone.js app, this is just a tool that really simplifies things and gives you a lot of things for free.

The Ember CLI was created so you can stop wasting time with little things such as file structure or how exactly do I setup this code and lets you get to the more important and challenging things. Also, if everyone is using it and the projects all have the same file structure, any Ember developer can jump into the app and know where things are located.

To reiterate, the reason why you’d want to consider the Ember CLI is that it’s considered a best practice to use it to build an Ember app, it comes with generators to easily create boilerplate code, it has a built-in testing library and has lots of addons for reusable code already created by the community.

“Learning how to learn” is something that I’ve heard many times and didn’t fully understand until recently. Over the course of the seven months at Turing it’s almost like high school all over again, but super condensed. When you’re in Module 1, you’re almost like a freshman, not knowing that much and basically being given lessons and assignments where you’re hand is being held a bit. As you make your way up through the program, you gain more and more experience and confidence, but also more responsibility. Starting in Module 3 and continuing into Module 4 and now real life, our learning became our own responsibility. We were taught that if we wanted to succeed in the engineering world, we needed to be able to take control of our own learning and possess the ability to constantly teach ourselves new skills. The program at Turing primarily teaches Ruby, Rails and JavaScript among many other things, but if you aren’t open to learning new skills or trying different languages, you won’t succeed because the industry never slows down or settles on one technology. Plus, you won’t always have someone to stand in front you to in a classroom setting telling you exactly what you have to do.

The place where I saw these skills coming into play the most were this past weekend when I participated in the Pebble Rocks Boulder hackathon with several other Turing students and alumni as well as another engineer who works locally in Boulder. PRB was a 48-hour hackathon held at Galvanize Boulder where teams had to come up with an idea and implement it. They were encouraged to hack hardware using Pebble Time smartwatches, newly-released smartstraps, arduinos and more, as well as create software to accompany it and use 3D printers to create anything else needed. After deliberating for a long time, our team settled on a project that we ended up calling TurnaKit. Although we worked iteratively, we ended up with smart turn signals for your bicycle. We developed two smartwatch apps, one that could allow you to turn on the signals manually from the Pebble Time once it was connected to the dock on the bicycle and another that once a destination was set, it would provide turn-by-turn directions for the rider as well as automatically turn on the turn signals within 50 feet of a turn.

We came into the hackathon thinking we knew some JavaScript and would be fine since the Pebble development team allows you to write apps in either C or JavaScript, but it ended up that to be able to write apps that interact with the new smartstrap hardware, you had to use C. My education at Turing allowed me to be able to follow the documentation and provided tutorials to write the code required by our project. This was the first time I ever wrote C code, but we ended up with completely working hardware and software. It was a challenge, but one I was fully prepared to tackle. We didn’t end up winning, but we were finalists in the top 8 out of 22. There were more teams originally since there were 75+ developers that started, but only 22 had a finished project.

I think this just proves that as a developer, you never know what you’ll be doing from day to day, but if you can think logically and know how to learn and constantly teach yourself new skills, you will always be successful.

Since we’re always so busy with classwork and don’t usually have time for much else, I’ve been using my Lightning Talks as an opportunity to explore topics that I find interesting, but usually don’t have the time to.

My talk was originally shared over at the Turing’s blog. Here’s my description from the school’s blog:

At Turing, students are taught to become diverse developers who are able to think logically and can use any programming language as a tool to solve a problem. In my Module 3 Lightning Talk, I chose to explore the MEAN Stack. The MEAN Stack is made up of four frameworks: MongoDB, ExpressJS, AngularJS and Node.js. It uses a single language across the entire stack and has been said to increase productivity. I realize that I may not be programming in Ruby and Rails after Turing, so I wanted to explore other frameworks and drive deeper into JavaScript.

My screencast/presentation is also over on Turing’s Vimeo channel, but to make it easier, here it is:

Exploring the MEAN Stack -- Tom Leskin from Turing School on Vimeo.

Slides from my talk can be viewed here.

If you have any questions feel free to drop be a line. Thanks!

Although these weeks are somewhat breaks, the burner is turned down only slightly and you still have pre-work for the next module to complete. During the last intermission week, it was lucky enough to fall on the same week as Boulder Startup Week 2015. For a student who will now be graduating in about 7 weeks (including the intermission week), this couldn’t have fallen on a better time. It was perfect to try to get involved in the local startup community as well as to do some networking.

There were numerous events during BSW, but the one that sticks out in my mind the most was the Humor Hackfest hosted by Quick Left, a software consultancy on Pearl Street in Boulder.

It was the first time I had ever participated in such an event so I was both excited and nervous. If you’re unfamiliar with what a hackfest is, it’s not an event where you’re trying to do something like hack the government, like you hear in the news involving China and the U.S., but an event where you’re given a limited amount of time to try to “hack” together some kind of working app. In the case of the Humor Hackfest at QL, you were given about three hours to build an app around the theme “humor” or as the event description said, “create products — tech or otherwise — that help people learn and practice how to be funnier, thus enriching their lives and the lives of people around them.” The only real strict rules were that you couldn’t have built it before the event and it had to “work”, so you needed to be able to present a working app.

Before the hackfest, I had been excited for the event for weeks and even started recruiting a team before hand, which ended up being my friends and fellow Turing students Eric Dowty and Patrick Medaugh, but we had no idea what we were doing to build. One of the ideas vetoed was an app that lets you receive emails from your favorite celebrities, such as Taylor Swift, who surprisingly some people people at Turing are obsessed with. We settled on an app that we called Trolio that let you spam your friends with random MMS messages.

The thought behind Trolio was that just about everyone gets random texts from time to time from someone they don’t know. Eric came up with the idea, which a lot of people really enjoyed and thought was pretty funny, where you could go to our app, enter a message, which we provided the default ‘wish you were here!’, enter a URL to an image, again a random default one is provided, then you enter a phone number and your friend (or person you’re trolling) will receive a text with all of that information from a random rural Colorado phone number.

During the event we did our best to code as quickly and efficiently as possible, mostly working in pairs (yes, we do lots of pair programming at Turing). As soon as Rachel Scott from QL yelled “go!” after everyone got pizza and beer for dinner, it was a mad dash to your work area. I just remember it being a whirlwind to get started and also feeling the pressure of only having three hours to build our app. The advantage to pairing was that we had who brains what could write code twice as fast, that was also much cleaner.

The three of us had just come out of Module 2 at Turing, so our Rails skills were just starting to really develop, but we felt comfortable enough to be able to create a new project and implement what we wanted. One of the most challenging parts was one of the most crucial pieces of our app, integrating the Twilio API, which allows your app to make and receive phone calls and send and receive text messages. We had never used an API before, we actually just got really deep into using third-party APIs in the past six weeks at Turing in Module 3, but it only took us less than an hour to get it all hooked up.

As the time went on, we had our app mostly finished in about an hour and a half. A lot of the time afterwards was spent trying to get some CSS styling and to add additional features, but the most challenging thing was that we wanted to have an app in production so that people could use and visit our app even afterwards. With electronic music blasting in the background and time running thin, we tried everything and eventually got our app pushed to Heroku at the last minute. I can’t remember what the issue was that were having, but thanks to some help from other fellow Turing students, we got it sorted out.

In the end, we got to present our app and although we didn’t win, people did seem to love it. I remember reading on Twitter how someone mentioned our app was their favorite out of all the presentations so far. It also seemed to be the most favorited and retweeted out of all the apps.

Even before attending the Humor Hackfest, I got some advice from a Turing graduate that I should try to participate in as many ‘hack-a-thons’ as possible since it looks good to employers and many look for new employees at these sort of events. While that’s probably true, I think participating in such an event shows that you’re able to come up with an idea and put together some sort of implementation quickly. For anyone studying software development, Turing students or not, I challenge you to participate in at least one as it will give you a great assessment of your skills and show that you can think on your feet under pressure and time constraints. Some advice that I’d give, which could apply to any project, not just for a hackfest, is to use some agile practices and work in iterations. There’s no way you’re going to build the next hot fully fleshed out app in just a few hours, but the chances are you can build something that can be expanded upon later.

Here’s our project, just incase anyone was interested:

Demo app: http://trolio.herokuapp.com

Project repository: https://github.com/tleskin/trolio

Besides that, just have fun and happy hacking!