- Were vetted and had a reputation to uphold.

- Did not interrupt me or throw my day into disarray.

- Has no flashing ads, pop-up ads, un-intentional sounds.

- Provided a daily digest of local, national, and world events.

- Did not lead oneself to seek tools to manage the information inflow.

- Can be browsed by the kids without fear of what other material they’ll come across.

- Can be recycled.

If only there were a news, information, and entertainment source like that.  I would buy it.  In a hundred years, someone will probably say “I’ve got an idea…”

1. When the API takes front-and center.

Take a look at https://stripe.com.  You’ll find no screenshots on the front page.  One of the first things you will find is working API code snippets and a link to their API docs.

2. When they boldly declare it.

What’s so bold about declaring it, you may ask? To be clear, I am not saying that declaring oneself as “for developers” makes it so. But, declaring oneself as “for developers” does pretty much make it so that you’ve excluded a lot of potential customers.  The non-developer is likely to come to stripe.com, see that declaration front and center, and then leave.  And I’m glad.

Stripe stands forward and says they are “Payments for Developers”.  As a developer, this focus on developers is important to me. It grabs me.  The logical part of me performs simple reasoning: Stripe’s focus is on developers.  I am a developer.  Ergo Stripe is for me. I think it’s sound reasoning. It’s like they say, if you try to please everyone, you’ll please no one.

As a developer, why would I want one of my vendor’s resources focussed on a non-developer audience?  All companies need to prioritize resources. Wether it be support resources or feature development, I would prefer that my vendors of choice prioritize support and feature development toward my technical capabilities.  Who wouldn’t?  Just the same way that a non-technical person would prefer that a vendor’s support efforts and feature development tended toward a non-technical audience.

3. When their team has vastly more developers than managers and marketers.

Look at Stripe’s team.  Do you see many marketing and sales staff?  Not many if there are any. I am sure Stripe will benefit from a sales and marketing team, but for now they seem to be happily building a product which they hope that developers will love.

I, for one, think this developer focus is an excellent strategy.

Extend Ember.TextField Control
Ember provides hooks into common html controls, including buttons, check boxes, text fields,  select lists, and text areas.  The Todos app has one text field.  This control binds to the insertNewLine function.  insertNewLine is called when [Enter] is pressed within a text field.  When the user presses Enter, this function takes the value in the TextField, creates a Todo with it, and blanks out the TextField.

Todos.CreateTodoView = Ember.TextField.extend({
  insertNewline: function() {
    var value = this.get('value');

    if (value) {
      Todos.todosController.createTodo(value);
      this.set('value', '');
    }
  }
});

Render a Handlebars template and insert it into the DOM
Ember uses the Handlebars templating library.  A View’s templateName property tells Ember which template to use.  The following code tells Ember to use the DOM element with data-template-name=”main_view” as its template.

Todos.MainView = Ember.View.extend({
  templateName: 'main_view'
});

app.js

That’s a wrap for app.js.  We told Ember there is a TextField and extended Ember.TextField in order to capture the insertNewLine event.  Finally, we told Ember to use the ‘main_view’ template.  In the next post we will look at the main_view.handlebars template itself to see how this all ties together.

In the next few posts I’d like to walk through the code.  We’ll start with app/lib/app.js. The Ember app comes to life via instantiating Ember.Application, extending Ember.object(s) (each with methods and properties), creating Ember.Controller(s), and extending Ember.View(s).  In the Todos application, this is all done in app.js.

What follows is a line-by-line walkthrough of the first parts of app.js.

app.js

Leverage jquery and ember.

require('todos/vendor/jquery-1.7.1');
require('todos/vendor/ember-0.9.5');

Require the view template (which we will cover in the next post).

require('todos/templates/main_view');

Create an Ember Application named Todos.

Todos = Ember.Application.create();

Create an Ember Object named Todo.
Todos have two attributes: title and isDone. Each attribute has a default value.

Todos.Todo = Ember.Object.extend({
  title: null,
  isDone: false
});

Create an Ember ArrayController to hold our Todos.  
ArrayControllers handle collection of objects.  Ember knows how to push to, filter, traverse, and perform other enumerable operations on the items in the ArrayController’s content collection.  Yet even more useful and powerful is its binding ability.  You do not need to bind each element of the array to an element in the DOM.  Instead, simply populate the ArrayController’s content property and then wrap the view bindings in #each /each.  We will see this in a future post where we look at the views bindings in detail.  For now, we are just looking at app.js and are about to create our ArrayController with empty content.

Todos.todosController = Ember.ArrayController.create({
  content: [],

Create Todos
When called, createToDo takes a title, creates a Todo setting the title attribute, and then adds our new todo to the content collection via pushObject.

  createTodo: function(title) {
    var todo = Todos.Todo.create({ title: title });
    this.pushObject(todo);
  },

Remove Todos
clearCompletedTodos introduces a couple interesting methods which are available on Ember enumerables such as our todosController.

filterProperty returns only those items in a collection which for which the given attribute (‘isDone’) matches the given value (true).

forEach executes the block for each item.

In this case, each todo for which isDone is true is removed from the content collection (via this.removeObject).

  
  clearCompletedTodos: function() {
    this.filterProperty('isDone', true).forEach(this.removeObject, this);
  },

Define properties and dependencies
Recall that Ember allows you use functions like a property.  Ember functions can be attribute getters, can be setters, and can be “computed properties”.  The “remaining” function is an example of a computed property.

  remaining: function() {
    return this.filterProperty('isDone', false).get('length');
  }.property('@each.isDone'),

This function filters todos where isDone is false, and then returns the length of that filtered collection.

Note the .property call at the end of the function.  This tells Ember to: 1.) treat the function as a property and 2.) optionally create a dependency between this function and other properties.  In the case of todo’s “remaining” function, we can see that the function is to be treated as a property and has a dependency on “@each.isDone”.

@each is a special key which tells Ember.js that the value of “remaining” could change when the array changes or when the isDone property of any of the objects in the contents array changes.  With this dependency marked, Ember automatically observes the collection and its members for changes and automatically recalculates “remaining” upon a change (which then could automatically update views bound to the “remaining” property).

The isEmpty function is in similar form.  It returns the number of items in the content collection. .property(‘length’) tells Ember that isEmpty is dependent upon the collection’s ‘length’.  (i.e. when items are added to or removed from the collection, Ember knows the value of isEmpty changes).

  isEmpty: function() {
    return this.get('length') === 0;
  }.property('length'),

Write getters and setters
allAreDone demonstrates a common pattern in Ember.  This is a getter/setter pattern.  If two values are sent in, it works as a setter; otherwise it acts as a getter (returning the value of the requested attribute).  Note the use of setEach to set the ‘isDone’ property of every item in the collection to value.  Also note the dependency.  allAreDone is dependent on the isDone property of each item in the collection.

  allAreDone: function(key, value) {
    if (arguments.length === 2) {
      this.setEach('isDone', value);

      return value;
    } else {
      return !this.get('isEmpty') && this.everyProperty('isDone', true);
    }
  }.property('@each.isDone')

Close out the Todos.todosController

});

In these 41 lines of code, the Todos application created an Ember Application and defined an Ember Object.  It then created an ArrayController to hold and manage our Todos. It knows how to createToDos, add them and remove them from its content collection, count how many toDos are remaining, answer if it isEmpty, and set all Todos to done or not done. It also knows of dependencies between properties. For example, if any one Todo’s ‘isDone’ property is changes, the application knows that the allAreDone property changed as well.

All of this is great, but even greater when the user can interact with these Todos via views. In the next post, we’ll take a look at the remaining parts of app.js which create a view and tie it to the app.

A top-to-bottom walkthrough of Ember is provided at http://emberjs.com/.  I’ve read through that page a couple times, yet I learn best by examining working code.  In this series of posts, I perform an examination and walkthrough of an Ember demo app.

Install the demo app

The authors of Ember provide several demo apps.  The simplest is the Todos application (source code).

Using ruby 1.9, the steps below will create the Todos app locally.

# get the source
git clone git://github.com/emberjs/todos.git
cd todos

# install dependencies
bundle

# assemble the app
bundle exec rakep build

# run preview server
bundle exec rakep server

Fire up your browser, steer it to http://localhost:9292/, and you should see this:

Go ahead and play around with it.  Learn how it works.  I’ll wait here.  When you’ve had your fill of creating and completing Todos, come back and in the next post, we’ll take dive into the code behind it as a way to introduce ourselves to Ember.

* “Wilderness” (as opposed to urban) is defined in relation to “Time”.  How much time will it take for professional medical help to arrive?  In an urban environment, minutes.  In a wilderness environment, hours.

* With a lot of time on our hands, take a cautious approach to the patient.  NOLS teaches “Don’t just do something, stand there.”  The first step of any scenario at this level is “#1. Assess environment safety”, i.e. is it safe for us to approach the patient?

* The next steps of the initial patient protocol:

#2: “What happened to you?” – Identify possible mechanisms of injury (MOI).

#3: “Not on me.” – Protect yourself from bodily fluids (BSI).

#4: “Are there any more?” – Look for or ask if there are more people hurt.  The person most audible is likely not the person most in need of care.

#5: “Dead or alive?” – Assess the patient’s condition.

We then learned, and practiced: head-to-toe assessment, taking and recording vitals, moving a patient, deciding whether to evac; all while maintaining head control and spinal alignment.  In the second half of the day we covered first aid for head injury, shock, cuts, and abrasions.

This is the first class I’ve taken which uses realistic mock-injury scenarios.  There were 30 students in this class.  For each injury scenario, ten of us acted as patients while the remaining twenty worked in pairs as rescuers for a victim.  The victims had realistic-looking blood, bruises, abrasions, and cuts and we were given a script to follow which said what our injury was, how it occurred, our level of responsiveness (LOR) and other “facts”.  As rescuers these drills presented slightly realistic scenarios of incidents which could occur in the wilderness and great opportunities for hands-on practice.

—-

Wilderness first aid combines logic, compassion, and outdoors into one activity, and I like it. I think I’ve found a new interest.  I plan to take Wilderness First Responder training next summer.  Being a Wilderness First Responder such as a search and rescue (SAR) volunteer would be interesting and fulfilling as well as make me more prepared for family outings to the mountains.

My one-year chain is to write daily in this blog.  So, that’s it.  Here’s to day 1.

p.s. Check out Jerry Seinfeld’s Productivity Secret and chains.cc/.

Whether choosing which car to buy, which job to take, who to date, or which sandwich to order; there is no shortage of endless information and data that you could consume, tabulate, study and otherwise obsess over. Fear of making the wrong choice prevents us from acting on a decision. So one reason we gather and consider all the data we can accumulate is to have re-assurance that our decision was “sound” and “smart”, even if the results turns out less satisfactory than we expected.

Using the deep-data and indecision combo to buttress the fear bad decisions is bogus. Here’s why you are better off making decisions quickly.

1. Reduce stress.

Pending decisions get thrown into your mental bucket with to-do lists, goals, chores, and worries. A great way to battle feelings of being overwhelmed and disorganized is to reduce and simplify the amount of stuff you are juggling. One easy way to reduce: eliminate pending decisions. Make them and move on.

Not only will you be less stressed, but so will people that are awaiting your decision.

2. Reduce uncertainty. Increase value.

Certainty is a major component of value. Don’t know if that car is going to start every morning? It’s less valuable than a reliable car with certainty. Don’t know if hurricanes will hit during an October cruise? It’s less valuable than a February cruise when the weather is more certain.

It’s the same with people. Every pending decision on your plate has introduced uncertainty thereby reducing your value. Your “I don’t know yet” is less valuable than a “No” or a “Yes”, than an “A” or “B”. Whether the answer is yes or no, A or B, you can instantly increase your value by making those decisions now.

3. Learn quickly.

You only learn what really works by doing it. Learn faster then the other guys in business and you have a competitive advantage. Learn faster in life and you’re able to fit more into life.

Got any decisions on your plate?

(photo credit: tj scenes)

The Plan

0. Divide the day into three parts: “sleep”, “work”, and “play”.

The System

1. When it is time to sleep, sleep soundly.

2. When it is time to work, work with focus.

3. When it is time to play, play with passion.

Notes

• Do plenty of all three, every day.
• Respect the present. Be present.  Be “in the moment”. When sleeping, only sleep (no laptop in bed). When playing, only play (no iPhone on the mountain hike).  When working, only work (no checking twitter every 2 minutes).
• Respect the proportions. Trying to shrink one slice in order get more of another always backfires.  Less sleep means less productive work.  Less work means less resources to use for play.  Less play means less restful sleep and less creative, unique work.
• Respect the parts. Don’t try to create more than three slices.  Patterns such as “sleep”, “work”, “sleep”, “play”, “work”, “play”, “work”, “sleep” do not work because there is too much lost time and energy in the transition zones when moving between slices.

Why does this work?
The alternative is what I suspect all these people that are “always working” are really doing. Spending a lot of the work day on unfocussed web surfing, Twitter, and blog reading and then staying up all night because of too much work – resulting in getting no sleep and then not being able to focus on work the next day. This time management plan breaks that vicious cycle.