Goal of this iteration: Implement list of showing watched repositories for a defined username.

Goal of this iteration: Further cleanups of used ember-skeleton template

So I wanted to create an Ember.js application which uses the Router feature as well as Ember-Data.

I also think that the current GitHub Dashboard at github.com/dashboard is not that useful. It’s hard to keep up with what’s going on in a specific project you are following. Which issues have been created, what are the discussions on Pull Requests, when has a new download been created, etc. I’m currently following 372 repositories. Some of them are written in languages I’m not really interested in any more. But there is no way to filter repositories based on a written language. Or sort them by count of watchers. Or by fork count. Or whatever.

Well, those are enough reasons to change that. To implement an own version of GitHub Dashboard. Using Ember.js. And Ember-Data. And Twitter Bootstrap, because I suck at design. I think about a dashboard which will be easily hackable. Fork it and you have your own version of the Dashboard running.

I plan to develop the dashboard and post updates on this blog. This hopefully helps some developers to get to know Ember.js better and help them to understand, how to build awesome applications using this very handsome framework.

Since the previous release 0.9.5 and the current release 0.9.6 many changes have been made. Besides the many bug fixes, added documentation and speed improvements also some new features have been added. This blog post will cover some of them. The complete changelog is listed in ember.js/CHANGELOG.

I recently stumbled over some very handy functions in the Ember.Observable mixin, which is applied to Ember.Object’s. They are basically shortcuts for incrementing/decrementing a property and toggling a boolean.

incrementProperty and decrementProperty

1
2
3
4
5
6
7
8
9
10
11

var obj = Ember.Object.create({
  score: 10
});

obj.incrementProperty('score'); // score === 11
obj.incrementProperty('score', 5); // score === 16

obj.set('score', 10);

obj.decrementProperty('score'); // score === 9
obj.decrementProperty('score', 5); // score === 4

toggleProperty

1
2
3
4
5
6

var obj = Ember.Object.create({
  isVisible: true
});

obj.toggleProperty('isVisible'); // isVisible === false
obj.toggleProperty('isVisible'); // isVisible === true

Bindings are one of the killer features of Ember.js. When you use the framework your are likely to use this good stuff probably via adding a Binding to your property name, like valueBinding: 'App.controller.value'. There are some enhanced ways of using bindings which are covered in this blog post. I’ll show how you can create bindings which transform values, convert a value to a boolean and how chained bindings work.

While developing stuff with Ember.js I stumbled upon some very nice and handy functions which are built in. This post lists some of them and describes in a short what they are used for.

Yesterday user cloke asked whether there is an ‘array’ attribute available for DS.attr() emberjs/data. I looked at the code and haven’t seen this functionality. Browsing through the Issues and Pull Requests also left no hint that somebody already implemented this. So I opened TextMate, did a git checkout -b add_array_attr, looked at the existing tests to see how the other attributes are tested, created new ones for the ‘array’ functionality and implemented it. Afterwards I ran the tests via bundle exec rackup and navigating to http://localhost:9292/tests/index.html?packages=all. All tests passed, so I updated the README to give a hint about the new attribute type. Finally I added my modifications, pushed to my fork on GitHub and opened a Pull Request.

I wasn’t sure wether my explanation about the added attribute type in the README was accurate so I simply started a discussion on the diff which is shown directly inside the Pull Request. A few hours later wycats closed the request and commented that my added implementation does not mark a record as dirty and therefore it is not merged in.

So why am I writing a post about this? Well: Open Source on GitHub or development in general on GitHub is just great!! I love it! There is absolutely no barrier for a developer to contribute to a project. Just hack around, open a Pull Request and start a discussion. If it gets merged, fine. If not, thats fine too! Just do it and see what happens. GitHub put back the fun in contributing to Open Source projects!

I am very excited about Ember.js, an awesome JavaScript library with some neat features like Bindings, Computed Properties, Templates, … you should go check it out on GitHub.

If you need some help you can simple ask your question at the #emberjs IRC channel. There is just one problem: you cannot read through older conversations because this channel is not logged - yet. So I decided to hack something together to end this.

The result - which is hosted here http://emberjs.iriscouch.com/irc/_design/viewer/index.html - is a Hubot hanging around the IRC channel, storing the messages in a CouchDB. Additionally there is a viewer written in - you guessed it - ember.js which let you browse through the transcripts. This blog post covers the basics how I implemented all this.

Today I’ve installed CouchDB on Mac OS X via Homebrew. Running a brew install couchdb started downloading the dependencies and eventually the CouchDB itself. Everything looked as expected. I switched to TextMate to continue coding and somehow forgot about the CouchDB installation process.

After it came back in my mind I looked at the progress and it seemed that it was stuck in make. I did a search on the mighty interwebs and found the solution: It seems that OS X Lion hangs on the final make. As stated on the CouchDB wiki, installing with the verbose option does the trick. Weird. So a brew install -v couchdb helps.

Starting CouchDB via couchdb gives the calming message: Apache CouchDB has started. Time to relax. Thankfully there is a verbose option!