scottmessinger

class ApplicationController < ActionController::Base
  protect_from_forgery
  before_filter :ensure_domain
  APP_DOMAIN = 'www.commoncurriculum.com'
  STAGING_DOMAIN = 'hlavka-staging.herokuapp.com'
  def ensure_domain
    if request.env['HTTP_HOST'] != APP_DOMAIN && request.env['HTTP_HOST'] != STAGING_DOMAIN && Rails.env != 'development'  
      # HTTP 301 is a "permanent" redirect
      redirect_to "http://#{APP_DOMAIN}", :status => 301
    end

scottmessinger

 [
  {
    "id": "5033fc7061dec5507a000001",
    "title": "Math",
    "startDate": 1345593600,
    "background-color": "#64D1AA",
    "border-color": "#34B47C",
    "daysOff": [
      1346112000,
      1346716800,

scottmessinger

I've been working with the relationship-improvements branch of ember-data and I like the changes. However, I notice it's quite a bit slower than creating native ember objects.

• With Chrome, loading/finding 400 records is 3x slower with ember-data than if I create native ember objects (700ms vs 200ms).
• With IE8, it's almost 4x slower (2300ms to 600ms).

I'm wondering if the architecture of ember-data prevents it from being suitable to large data sets. Or if it's slow simply because it's young and we can expect that, over time, its performance will approach native ember-objects.

Given I have very large data sets in my app (1000+ records loaded (though not all visible at once)), I'm wondering if, it's better to just role my own much simpler data library or hang in there with ember-data.

We're launch our app in the next 1.5 months, and my guess is ember-data won't become dramatically faster by then.

scottmessinger

$(document).ready(function(){
    window.App = Ember.Application.create();

    WEEKDAYS = []
    WEEKDAYS.push(DATES['2012'].weekdays)
    WEEKDAYS.push(DATES['2013'].weekdays)

    App.store = DS.Store.create({
      revision: 4
      // , adapter: DS.RESTAdapter.create({ bulkCommit: false })

scottmessinger

class Ability
  include CanCan::Ability

  def employee_abilities(user)
    # [ code ]
    # I imagine the invite abilities being set just like the group
    # viewer abilities and supervisor abilities are set now. 
    supervisor_abilities(user) if user.employee.supervisor?
    group_viewer_abilities(user)
    invite_abilities(user)

scottmessinger

global vs. local property When nesting a view class like this, make sure to use a lowercase letter, as Ember will interpret a property with a capital letter as a global property.

scottmessinger

evaluatePossiblyAsyncknockout-deferred-updates.js:234
ko.subscribable.fn.notifySubscribersknockout-2.0.0rc3.debug.js:809
ko.utils.arrayForEachknockout-2.0.0rc3.debug.js:60
ko.subscribable.fn.notifySubscribersknockout-2.0.0rc3.debug.js:805
ko.observable.observable.valueHasMutatedknockout-2.0.0rc3.debug.js:882
observableknockout-2.0.0rc3.debug.js:871
ko.bindingHandlers.value.initknockout-2.0.0rc3.debug.js:2061
ko.bindingHandlers.value.init.ko.utils.arrayForEach.runEventHandlerknockout-2.0.0rc3.debug.js:2054
ko.bindingHandlers.value.initknockout-2.0.0rc3.debug.js:2057
jQuery.event.handlejquery-1.6.1.js:2927

scottmessinger

http://tutorials.jumpstartlab.com/topics/models/modules.html

Typically the classes would be stored in a subfolder of models with the name of the namespace, so here app/models/packager/*.rb

Isn't it required? As in, won't Rails throw an error if it doesn't find the modules in the right folder structure?

We want to extract the common code into a module, but it has to add a class method, not an instance method like the module we wrote before. There are two approaches.

You write there are two approaches then address one and then jump to a larger heading. For clarity, I'd note the two approaches. e.g. There are two approaches: using a dedicated module that holds class methods and using a module that holds both class and instance methods.

scottmessinger

%table
  %tr
    %td{ ADD OPTIONAL CLASS HERE }
      Text
      Text 
      Text

scottmessinger

ko.bindingHandlers.sortableList = {
    init: function(element, valueAccessor, allBindingsAccessor, context) {
        var parent = allBindingsAccessor().parent
        var list = valueAccessor();
        $(element).sortable({
            handle : '.move'
            ,start: function(){ mpq.track("sort")}
            ,sort: function(){
                var $lis = $(this).children('li');
                $lis.each(function(){