I gave a talk entitled “Time-Based Estimates Are For Suckers! Size-based is The Way to Go” at this year’s GLSEC on April 29. It’s meant as a call to action for those who haven’t made the leap to size-based estimation, or who have been beaten back by some of the challenges you’ll encounter when trying, such as:

• Breaking things down by value, not by task
• Thinking in terms of “size” (not time)
• Making estimates

I did this because, even though we’re all a bunch of Agile know-it-alls by now, and estimation is a remedial topic from 10 years ago, there are still plenty of people who haven’t been introducted to size-based estimation. Besides, making the switch from time-based estimation to size-based isn’t as easy as some of the books and blogs out there make it sound.

(Nevertheless, I didn’t design the talk to actually teach the skills needed to fully implement size-based estimation and planning. For a better-articulated discussion on how complexity-based estimates actually work and on why and how to start using them, see Carl’s talk on Making Better Estimates.)

As a tail on the conversation, I prepared some common high-level concerns and roadblocks to discuss, but the audience in the room provided plenty of same-level questions. A good example was, “How does all this data-driven re-estimation help me when I’ve got a fixed timeline that cannot change?” Answer: “This is one of the best tools to know if you’re going to get done on time; your manager will thank you for sharing that information early.”

I also had a brief tangent where I had to admit that Atomic does, in fact, use time-based “Aggressive-but-possible/Highly-probable” estimates during the sales process, when sketching high-level time-and-money estimates, since it assists with bidding and budget setting. But these estimates are then decomposed further using size-based tools for tracking and management.

Some common questions I didn’t get to in the talk:

• When is a story “done”? (When the customer says so, or when you’re able to demonstrate the value has been added.)
• Should estimate and track points for bugs? (Depends on what your customer is planning around; bugs aren’t scope, but they take time. Best to tackle them regularly and let them affect overall velocity.)
• Will customers accept estimates given in points? (Maybe eventually, but don’t force anyone to understand or accept your point scale. Instead, derive an estimated duration and be ready to explain how size and velocity create that information.)

I actually hope to continue the discussion. Size-based estimation — far from being old-hat or a close topic — is still the kernel of any great software project management process, and it still takes care and effort to keep the furnace stoked with good input.

Here are the slides from the presentation:

 

The post Time-Based Estimates Are for Suckers! (Size-based Is the Way to Go) appeared first on Atomic Spin.

The Build is an essential cog of any software project, but it is most often maintained by identified “experts.” This needs to stop. Agile depends on shared code ownership and understanding of the system — all parts of the system.

Consequences of Ignoring the Build

Most sufficiently-sized projects use a continuous integration system and some amount of configuration and/or code to make them work. If only a subset of individuals understands and maintains this system, it will likely not be kept up to snuff to meet the growing demands of the project.

I have experienced the effects of an insufficiently-maintained build system on numerous projects in the past. The risk of the build system getting in the way is especially high in the case of static languages (like C/C++). These compiled language project frequently require a lot of non-standard setup and complex build and/or packaging requirements (including compilers, linkers, tests, simulation, and static analysis tools).

Continuous integration systems, which use The Build, are invaluable for regression testing. Although, if the understanding of how the system works is compartmentalized, the overall health of the project will most likely suffer.

Where Things Go Wrong

The most disheartening aspect of this problem is that The Build is indeed code, just like the real code that developers write every day. While the code that makes it into the product being developed usually has mandates on its quality, structure, maintainability, and testing, code in the build system is too often not held to this high standard.

As a result, the build system suffers, tech-debt grows and eventually comes back around to bite you. And thanks to Murphy’s Law, it usually rears its ugly head at the worst possible time.

Not maintaining the code and/or services that comprise the build environment is a recipe for disaster. Instabilities in the build and the need to continuously tend to specific areas of the build environment are red flags that technical debt exists and is not being dealt with properly.

Spreading the understanding and ownership of The Build will have very beneficial effects on any project — most notably, sanity of the developers and all involved in delivering the product. Treat it with the same respect and the rest of your code base. You will not regret it!

Does your team tend to the build environment over the course of a project? Or does your team and/or management wait for the system to fall apart before addressing the resultant issues?
 

The post Not Tending to “The Build” – A Common Anti-Pattern appeared first on Atomic Spin.

In a previous post, I explored the question: Is your chair your enemy?, based in part on the many recent articles, research reports, and infographics claiming that the simple act of sitting is killing you.

But I recently read David Zax’s FastCompany article, In Defense of Sitting, a humorous counter argument (“Sitting may kill you. But at least you’ll die doing something you love.”) to the widely-published judgement that standing while at task is surely the key to eternal life.

What the summer of 1975 did for sharks, what the fall of 2001 did for anthrax, the last few years have been doing for that seemingly innocuous object: the chair.

Seeking inspiration of the “Great Standing Writers” like Ernest Hemingway and Philip Roth, Zax decided to try working while standing, but things didn’t go well:

The first thing I noticed about my standing desk was that it wasn’t particularly comfortable. It was also the second thing I noticed, and the third thing I noticed.

Zax also talked to some furniture designers and learned that it is not necessarily sitting that’s bad for us, but sitting still. Herman Miller has researched the health benefits of dynamic sitting. One of their seating research papers, Sitting Can Be Good for the Circulatory System, identifies the need for chairs that help users move:

One approach to promoting movement in a work chair would be to design one with a dynamic seat and backrest. Doing so would require a surface that automatically conforms to a sitter’s micro-movements and distributes weight evenly. This would allow the seat to take on the greater burden of supporting more weight while providing stability. It would also reduce seated pressure and increase blood circulation to improve oxygen flow and decrease heart rate.

While the jury is still out on whether or not sitting will actually kill us, we’ll continue to benefit from a variety of postures and overall movement as we work. And David Zax reminded me that a good sense of humor helps too.

The post Is There a Case to Be Made for Sitting? appeared first on Atomic Spin.

My team recently needed a date picker in our web app. We wrote tests and implemented a simple text field first as scaffolding. Call it YAGNI if you want — we really just weren’t excited about choosing from the long list of time-forgotten, unlovable JavaScript date picker widgets out there.

Surprises from Chrome

The next day while we were pairing, we opened up Chrome, hit our app, and noticed that our new “date” field had magically turned into a fully-functional date picker!

We were puzzled. We started looking at commit logs, wondering if another teammate had snuck in a little treat without us noticing. Then I tried the app in Firefox… and the date picker disappeared.

As it turns out, Chrome automatically adds a date picker to input elements with a type attribute of “date.” It’s been in there for a while, but we’d never noticed. It’s one of a longer list of new input types in HTML5 that Chrome has implemented, while Firefox has not.

Why Ember?

My team chose Ember.js to help us build a web app on top of a REST-based JSON+HAL API. Our next task then was to figure out how to integrate this gift horse into our app.

I like Ember.js for two reasons: I trust their team, and I like the decoupled, testable style of their architecture. It’s still a small enough framework that our team can solve most problems by looking through the source code or by running simple examples (or, sometimes, by asking fellow Atoms who’ve been using Ember longer than we have).

As it happens, our app expects a typical (for us weirdos in the US anyway) MM/DD/YYYY date format. We are using moment.js to convert a user’s entry into a preferred ISO8601 format for storage in CouchDB, so we started with a simple Ember view and a template helper to make our date picker and date display easy. The View was kickstarted with the results of this thread on the Ember Discourse page. We used Modernizr to help detect browser support and adjust the expected input format accordingly, so if you’re in Firefox, you’re just going to get a text field. If you’re in Chrome, you can haz a date picker.

The resulting model property is a bonafide Moment object, which in our case converts cleanly when JSON.stringify is called on the way to our API.

Here’s the resulting view class (in CoffeeScript of course.) Good luck with your Ember app!

# Usage:
# {{App.DateField dateBinding="date"}} # Where "date" points to a Moment.js object
App.DateField = Ember.TextField.extend
  type: 'date'
  hasFocus: false
  placeholderBinding: 'dateFormat'
  dateFormat:(->
    if Modernizr.inputtypes.date then 'YYYY-MM-DD' else 'MM/DD/YYYY'
  ).property()
  init: ->
    @_super()
    @updateValue()
  updateDate: (->
    ms = moment.utc(@get('value'), @get('dateFormat'))
    @set('date', ms) if ms and ms.isValid()
  ).observes('value')
  updateValue: (->
    return if @get('hasFocus')
    date = @get('date')
    if date
      @set('value', if moment.isMoment(date) then date.utc().format(@get('dateFormat')) else moment.utc(date))
  ).observes('date')
  focusIn: ->
    @set('hasFocus', true)
  focusOut: ->
    @set('hasFocus', false)
    @updateValue()

The post HTML5 Date Inputs and Ember.js appeared first on Atomic Spin.

I’ve been an email addict for a long time, but I’ve been working to replace my old, bad habits with new ones. I’ve discovered that managing email well can dramatically improve my productivity.

Old Habits (Letting my email manage me)

I get about 2,000 work-related emails every month (I’ve nearly given up on my personal email account), and my historical approach to keeping an empty inbox was to be always checking and responding to my email.

I’d frequently check email:

• first thing upon waking up
• right before commuting to work
• first thing upon getting to work
• in between meetings or scheduled sessions
• during any free moments or waiting periods
• right before I left work
• while eating lunch or dinner with others
• as a car passenger during family errands
• right before I went to sleep
• in the middle of the night if I woke up

My empty Mailbox inbox. I wish life could always be this good.

It’s a little embarrassing to admit, but there were times I’d check email on my phone and feel a sense of loneliness or anxiety if no new messages had come in. I was so addicted to email that I didn’t realize its corrosive effect on my productivity and energy levels.

A Forced Experiment

About a month ago, I took a trip to Mammoth Cave National Park and found that I had no cell reception. The Mammoth Cave Hotel had limited WiFi access only available in the lobby.

The limited internet connection forced me to batch my email interaction to 1-2 concentrated sessions per day. I was struck by the mental impact of batching email up instead checking it throughout the day. I was more present with others and focused during the day because I was not preoccupied with potential distractions in my inbox. When I did check email, I felt I had more energy to power through the entire batch more effectively and efficiently.

During the same trip, I read Harvard Business Review’s Guide to Getting the Right Work Done and discovered two great sections on email:

1. Simplify Your E-mail by Gina Trapini
2. Eight E-mail Overload Experiments by Alexandra Samuel

New Habits (Managing email on my terms)

Back at work, I’m now trying to establish the following email habits:

• Ruthlessly set filters for any newsletters or lists I don’t actively read (I have 67 new delete filters after ~1 month).
• Process email in batches (I usually check before lunch, before going home, and in the evening).
• When processing batches, quickly follow up or put the response task on my todo list in priority with my other tasks.
• Steer clear of lengthy conversations with “reply all” chains. If something is important enough for a group discussion, we should schedule an in-person group discussion.
• Stop replying to every email I get.
• Be more conscious of the email I send and reduce the amount of email I generate.
• Communicate more by phone. It’s amazing how much more you can convey quickly on the phone, even if it’s through a voicemail.
• Do the most important tasks of my day in the morning and don’t check email before my allocated priority time block is done. I’ve realized that if someone needs me urgently, they can call or text me.
• I don’t keep my email open in a browser tab, and I’ve turned off my email notifier.

My new email habits have me feeling happier and more productive. I seem to be getting more work done at work — and in less time. I’m spending less time at night or on the weekends getting my priority work done.

Are you addicted to email? Do you believe email has a negative impact on your productivity? Please share your stories or solutions.
 

The post Kick Your Bad Email Habits appeared first on Atomic Spin.

I recently started doing a lot more standalone JavaScript front end development, often using CoffeeScript, less, jade, or other modern web stack components. Compiling assets like these is pretty much a solved problem when they are being delivered from a server side web stack like Rails, but I found myself in need of a JavaScript-based solution for statically compiling, serving, and testing my code.

I first looked into simple solutions involving node Cakefiles and static site generators like wintersmith, but I found these solutions lacked the power and flexibility I needed. At this point, through an obscure comment in a Google Talk thread about wintersmith, I heard my first reference to Grunt.

Grunt

The front page of Grunt immediately looked promising, offering support for CoffeeScript, handlebars, jade, JSHint, and less — a significant portion of the tech our team was using. The plugins page revealed a list several hundred items long. Since every technology needed for my project at the time had at least one plugin on the list, I decided to dive into Grunt.

Fortunately for me, Grunt tasks are very consistent and easy to configure, and Grunt itself has excellent documentation. Configuring Grunt in fact only requires two files: a package.json file specifying which Grunt plugins you are using, and a Gruntfile.js or Gruntfile.coffee file to configure each task.

A Simple Example

Let’s look at a simple grunt configuration to compile CoffeeScript files into JavaScript. We can use the grunt-contrib-coffee plugin to do this (the contrib in the name indicates that that particular plugin is maintained by the Grunt team.). First off, we need to put the appropriate dependencies into our package.json file.

package.json

 
{
  "name": "my-project-name",
  "version": "0.1.0",
  "dependencies": {
    "grunt": "latest",
    "grunt-contrib-coffee": "latest"
  }
}

Here we declare the only two dependencies we need: the latest versions of Grunt, and the contrib-coffee plugin.

Gruntfile.coffee

Now we can configure the coffee task in our Gruntfile.coffee. I prefer to use CoffeeScript for my Gruntfile because it is supported by Grunt out of the box and it makes the configuration much more concise:

 
module.exports = (grunt) ->
  grunt.initConfig
    coffee:
      all:
        options:
          bare: true
        files: [
          src: ["./app/src/**/*.coffee"]
          dest: "./public/js/app.js"
        ]
 
    grunt.loadNpmTasks "grunt-contrib-coffee"

There’s a lot of information in the above configuration, so lets take an in-depth look at it. The first line simply defines an entry point for the Grunt object to be inserted into our configuration via nodejs’s module system. The second line calls Grunt’s initconfig method, which takes a Grunt configuration object as an argument.

The next section is our CoffeeScript task configuration. We start by defining a subtask all. While we don’t strictly have to do this because we only have a single subtask right now, it will make it easier to add other subtasks later. Within this configuration, we have two sections, options and files. As you would probably expect, options is where you set predefined configuration options for the task, and files is where you define the files that the task will operate on.

In our config, we are setting the bare option to true, which tells the CoffeeScript compiler to not wrap its output in a function.

The files section specifies an array with one item, an object with a src and dest parameter. As you can see in our src parameter, Grunt supports file glob syntax out of the box, allowing you to dynamically define which files you want to target. Since our dest is only one file, the coffee task also implicitly knows that it needs to concatenate all of the source files it finds into a single output file.

The last line simple loads the contrib coffee task from our our installed node_modules.

That’s all that is needed to configure a simple, automated build process for your CoffeeScript Source. Running grunt coffee:all from the command line will execute our defined task.

A More Comprehensive Example

Unfortunately, doing simple CoffeeScript compilation is rarely the only thing you need to do to build a complex client side project. So let’s look at a more complete configuration for an AngularJS project I’m working on in my spare time. First, the Gruntfile.

Gruntfile.coffee

 
module.exports = (grunt) ->
  grunt.initConfig
    appDir: "./app"
    srcDir: "<%= appDir %>/src"
    contentDir: "<%= appDir %>/content"
    templateDir: "<%= appDir %>/templates"
    vendorDir: "<%= appDir %>/vendor"
    cssDir: "<%= appDir %>/stylesheets"
    testDir: "./test"
 
    buildDir: "./tmp/build"
    outputDir: "./public"

Here we start our Grunt config the same way we did before. Immediately after that, we create some aliases for various directories we will be using. These aliases, as you can see, can be referenced in the Grunt configuration using underscore style template placeholders: <%= %>.

 
    # Javascript compilation tasks
    # Essentially we want everything in the vendor,
    # templates, and src directories to end up in
    # one big JS file in that order.
 
    coffee:
      options:
        bare: true
 
      all:
        files: [
          expand: true,
          src: ["<%= srcDir %>/**/*.coffee"]
          dest: "<%= buildDir %>"
          ext: ".js"
        ]
 
      changed:
        files: [
          expand: true
          src: "<%= grunt.regarde.changed %>"
          dest: "<%= buildDir %>"
          ext: ".js"
        ]
 
    jade:
      options:
        client: true
        compileDebug: false
        namespace: "APPLICATION_TEMPLATES"
        processName: (path) ->
          path
            .replace(/^.*\btemplates\//, "")
            .replace(/\..*$/, "")
 
      all:
        files: [
          expand: true
          src: ["<%= templateDir %>/**/*.jade"]
          dest: "<%= buildDir %>"
          ext: ".js"
          ]
 
      changed:
        files: [
          expand: true
          src: "<%= grunt.regarde.changed %>"
          dest: "<%= buildDir %>"
          ext: ".js"
        ]
 
    concat:
      js:
        src: [ # Order matters, at some point we should use requireJS or something to fix that
          "<%= vendorDir %>/**/*.js",
          "<%= buildDir %>/<%= templateDir %>/**/*.js",
          "<%= buildDir %>/<%= srcDir %>/*.js",
          "<%= buildDir %>/<%= srcDir %>/modules/**/*.js",
          "<%= buildDir %>/<%= srcDir %>/directives/**/*.js",
          "<%= buildDir %>/<%= srcDir %>/services/**/*.js",
          "<%= buildDir %>/<%= srcDir %>/filters/**/*.js",
          "<%= buildDir %>/<%= srcDir %>/controllers/**/*.js",
        ]
        dest: "<%= outputDir %>/js/app.js"

Now we’ve defined our javascript build tasks. These compile our CoffeeScript and jade sources into javascript files in a temporary build directory. Then our concat task concatenates our 3rd party vendor javascript, as well as our newly created javascript sources, into one large javascript file. Take particular note of the changed configuration blocks in the CoffeeScript and jade tasks; they will be explained shortly.

 
    # LESS compilation
    less:
      options:
        paths: "<%= cssDir %>"
 
      all:
        files: [
          src: "<%= cssDir %>/app.less"
          dest: "<%= outputDir %>/css/app.css"
        ]
 
 
    # Copy static files
    copy:
      html:
        files: [
          expand: true
          cwd: "<%= contentDir %>/html"
          src: ["**/*.html"]
          dest: "<%= outputDir %>"
        ]
 
      images:
        files: [
          expand: true
          cwd: "<%= contentDir %>/images"
          src: ["**/*"]
          dest: "<%= outputDir %>/images"
        ]

Here we define some tasks to compile our less stylesheets and copy our static assets like images into our output directory.

 
    # Set up file monitors to rebuild project on changes
    regarde:
      coffee:
        files: "<%= srcDir %>/**/*.coffee"
        tasks: ["coffee:changed", "concat:js"]
 
      templates:
        files: "<%= srcDir %>/**/*.jade"
        tasks: ["jade:changed", "concat:js"]
 
      vendor:
        files: "<%= vendorDir %>/**/*.js"
        tasks: ["concat:js"]
 
      less:
        files: "<%= cssDir %>/**/*.less"
        tasks: ["spawn_less"]
 
      html:
        files: "<%= contentDir %>/html/**/*.html"
        tasks: ["copy:html"]
 
      images:
        files: "<%= contentDir %>/images/**/*"
        tasks: ["copy:images"]

The regarde task defined here watches for changes to our source files and executes the specified task(s) whenever a watched file is changed. This saves us from manually rebuilding every time we make a change. Notice that for CoffeeScript and jade files, it calls the changed subtask, which only recompiles the files that were actually changed. This drastically cuts down our compilation times when there are a lot of source files, and only one was changed.

 
    # Set up a static file server
    connect:
      server:
        options:
          hostname: "0.0.0.0"
          port: 9292
          base: "<%= outputDir %>"
          keepalive: true
 
 
 
    # Clean up artifacts
    clean:
      build: "<%= buildDir %>"
      output: "<%= outputDir %>"
 
 
 
    # Execute server script
    exec:
      server:
        cmd: "./server.js"

The above are miscellaneous tasks:

• connect serves our output directory on our local machine so that we can open our newly generated site in a browser
• clean simply erases the build and output directories when invoked
• exec task lets us execute arbitrary shell programs (in this case, a custom server script that I’ll show in a moment)

 
    # Karma conf
    karma:
      unit:
        configFile: "<%= testDir %>/unit_conf.js"
      e2e:
        configFile: "<%= testDir %>/e2e_conf.js"
 
 
    # The contrib-less task has an outstanding bug that will kill a running grunt
    # process (like a watch process) when it fails.
    grunt.registerTask 'spawn_less', 'Run Less in a subprocess', () ->
      done = this.async()
      grunt.util.spawn grunt: true, args: ['less'], (err) ->
        if err
          grunt.log.writeln(">> Error compiling LESS file!")
        done()
 
    grunt.registerTask "js", ["coffee:all", "jade:all", "concat:js"]
    grunt.registerTask "build", ["clean", "js", "less", "copy"]
    grunt.registerTask "server", ["exec:server"]
    grunt.registerTask "unit", ["build", "karma:unit"]
    grunt.registerTask "e2e", ["build", "karma:e2e"]
    grunt.registerTask "ci", ["build", "karma"]
 
 
    grunt.loadNpmTasks "grunt-contrib-coffee"
    grunt.loadNpmTasks "grunt-contrib-jade"
    grunt.loadNpmTasks "grunt-contrib-concat"
    grunt.loadNpmTasks "grunt-contrib-less"
    grunt.loadNpmTasks "grunt-contrib-copy"
    grunt.loadNpmTasks "grunt-regarde"
    grunt.loadNpmTasks "grunt-contrib-connect"
    grunt.loadNpmTasks "grunt-contrib-clean"
    grunt.loadNpmTasks "grunt-exec"
    grunt.loadNpmTasks "grunt-karma"

The last part of the Gruntfile defines a task to load and run our tests via the karma test runner, registers some aliases for groups of tasks, and loads our tasks from our node modules.

The associated package.json file looks about like you would expect:

package.json

 
// package.json
{
  "name": "rcr-frontend",
  "version": "0.1.0",
  "dependencies": {
    "grunt": "latest",
    "grunt-contrib-coffee": "latest",
    "grunt-contrib-jade": "latest",
    "grunt-contrib-less": "latest",
    "grunt-contrib-copy": "latest",
    "grunt-contrib-connect": "latest",
    "grunt-contrib-concat": "latest",
    "grunt-regarde": "latest",
    "grunt-notify": "latest",
    "grunt-contrib-clean": "latest",
    "grunt-karma": "latest",
    "grunt-exec": "latest"
  }
}

And as promised, the server.js file referenced in our exec task. This script allows us to run both our webserver and file watcher service in the same terminal by just running the command grunt server.

server.js

 
#!/usr/bin/env node
 
var spawn = require("child_process").spawn,
    watcher = spawn("grunt", ["regarde", "--force"]),
    server = spawn("grunt", ["build", "connect:server"]);
 
watcher.stdout.on("data", function(data) {
  var importantOutput = data.toString().split("\r?\n").filter(function(str) {
    return />>|Done|Warning|Running/.test(str);
  });
 
  process.stdout.write(importantOutput.join("\n"));
  // process.stdout.write(data);
});
 
server.stdout.on("data", function(data) {
  process.stdout.write(data);
});
 
watcher.on("exit", function(code, signal) {
  server.kill();
  process.exit();
});
 
server.on("exit", function(code, signal) {
  watcher.kill();
  process.exit();
});
 
process.on("exit", function() {
  watcher.kill();
  server.kill();
});

There you have it, a relatively straightforward build configuration for a complicated static JavaScript site, made easy with Grunt.
 

The post Build a Rich JavaScript Front End with Grunt appeared first on Atomic Spin.

I’m currently working on an Ember.js web application that is a basic CRUD app with a twist — we don’t know all of the form fields or model attributes ahead of time, but rely on a JSON document to specify the names and types of attributes for which we need to render form controls. This presents some interesting challenges, the most significant being that our input elements don’t know what to bind their value to until they are instantiated.

After trying a few different approaches, we settled on using a pair of observers to accomplish what a more direct binding could not in this scenario. One observer watches the input’s value property and updates the remote property value, and the other observer watches the remote property and updates the input’s value.

Our Solution

Cut to the chase and check out the jsbin example, or read on for a few more details.

(This example uses Ember.js 1.0.0-RC.1, and we are using the same general solution in 1.0.0-RC.3.)

Say we have the following definition for a set of fields:

{"fields":  [
  { "name": "First Name", "key": "first_name" },
  { "name": "Last Name", "key": "last_name" },
  { "name": "Email", "key": "email" }
]}

We want to display a text field for each element in the array and bind its value to a property on our model defined by the key. This example uses a CollectionView to render a subclass of Ember.TextField for each element. The DynamicBoundTextField here has the pair of observers.

App.DynamicBoundTextField = Ember.TextField.extend
  placeholderBinding: 'content.name'
  # Update the remote property's value when the value of
  # our text field changes
  _setRemoteValue:(->
    val = @get('value')
    @set("controller.data.#{@get('content.key')}", val) if val?
  ).observes('value')
  # Since we don't know the name of the property to
  # observe ahead of time, create the observer when
  # inserted into the DOM (we'll have the key then).
  didInsertElement: ->
    updateCurrentValue = =>
      currentValue = @get("controller.data.#{@get('content.key')}")
      console.log currentValue
      @set('value', currentValue) if currentValue?
    updateCurrentValue()
    @addObserver "controller.data.#{@get('content.key')}", updateCurrentValue

Our implementation uses an intermediate object to perform the observation because it requires specialized knowledge about the context that the binding is being performed in, and we felt it was odd having that information on the input itself. But it works the same way.

Try it out in this JS Bin: Runtime binding using observers JS Bin.

Things that Didn’t Work

TextField with a valueBinding

The primary constraint we’re dealing with is not knowing what the TextField should bind to until it’s created. This means we can’t simply place a valueBinding on our text input in our class definition like most Ember examples show. It needs another level of indirection to work.

TextField and an Intermediate Object with Bindings

So we tried creating a valueBinding to a known property, inputValue, of an intermediate view. The intermediate view then bound its inputValue to the target property in init. This caused interesting but unwanted behavior, like the target property getting set to undefined instead of the input’s value getting set to the existing value of the target property. It just didn’t work out very well.

Our current, working implementation does have an intermediate object, but it uses the observer pair pattern instead of a binding to the target property to avoid the bad behavior described above.
 

The post Dynamic Binding in Ember.js Using Observers appeared first on Atomic Spin.

Recently, a group of people at AO collectively bought a MakerBot Replicator 2. The printer has been going pretty steadily, but not without the teething problems expected in an early-adopter technology.

Poor Extruder Block Design

Makerbot’s stock extruder for the Replicator 2 uses a round delrin plunger mounted on the end of a screw to pinch the filment against the stepper motor’s hobbed wheel to push filament. Delrin has a low enough coefficient of friction that this works great so long as your filament is a constant diameter. In our printing, we’ve found that our extruder occasionaly still skips steps, leaving gaps in the extruded filament.

This delrin plunger is adjustable, but only after removing the print-cooling fan, which is attached with self-tapping screws. It takes quite some time to remove the fan, and the self-tapping screws give you a limited number of removal and replacement cycles.

Thankfully, Makerbot has recently put released a commmunity-derived pinch roller design which is theoretically much more tolerant to filament thickness deviations. They even sent us the upgrade kit at no cost when we contacted them. It was installed earlier this week and is working pretty well so far.

Belt Tension Issues

An issue kept appearing in various prints where infill would sometimes not reach the edges of the print in the positive y direction. After running prints through several independent software chains (Makerware with MiracleGrue and Skeinforge, ReplicatorG with Skeinforge and Slic3r) and seeing the same issue, I determined it *must* be either a firmware or a hardware issue.

To try and narrow down the issue, I printed out a 20mm diameter, 20mm height cylinder. The thought was that any axis slope would be very apparent with a pair of digital calipers. When the printed part was measured, I found a minimum diameter of 19.7mm and a maximum of 20.4mm. 0.7mm is way more variance than I was expecting.

Some previous experience with an Ultimaker suggested that this could be a belt tension issue. I went through the belts in the machine and found that the belt connecting the y-axis stepper motor to the gantry system was quite loose. Once I found a 5.5mm socket and extension with which to loosen the two mounting nuts and repositioned the stepper motor, the print improved much more to a .3mm difference.

Still an Early Technology

Makerbot has come a very, very long way in their efforts to bring 3d printing to the masses. When comparing the amount of effort needed to get good prints out of a Cupcake CNC or even a Thing-o-Matic to that required on the Replicator 2, the ease of use is astonishing. The question I ask myself when wondering whether something is ready for the mass market is “Would I be willing to shoulder the technical support load if I gave this to my grandmother?” For the Replicator 2, the answer is a definitive no.

The Makerbot Operators Group is a great place to go for help with issues like these. Have you encountered any odd issues or assembly inconsistencies with your Replicators?
 

The post Replicator 2 Teething Issues appeared first on Atomic Spin.

In one of my previous posts, I described an implementation of miniKanren in Haskell. I have since been improving the implementation.

I am currently working on the third iteration of my logic library. The first one was described by my previous post. The second is in a GitHub repository. I have yet to settle on a design that I really like, but I thought I’d post something about what I’ve been working on.

Improvements

The key improvements in the second iteration were the ability to easily add custom data types and the addition of a match function. The custom data type addition was pretty straightforward.

The match function was an attempt to replicated the functionality of the match function in William Byrd’s thesis. I think what I have does the same thing; if not, it still gave me the idea.

The type of my match function is as follows:

match :: (MonadKanren m, Matchable a, Unifiable b)
      => (a -> m (LVar b)) -> m (LVar a) -> m (LVar b)

Think of the type m (LVar a) as a relational monadic computation that returns a logic variable.

match turns code that looks like this:

logic_append a b ab = do
   conde [ do
      (h, t, res) <- fresh
      Cons h t === a
      Cons h res === ab
      ab === logic_append t b res
   , do
      Nil === a
      b === ab
   ]

into this:

logic_append a b = match (logic_append_match b) a
      where
        -- Note that the order of the arguments was swapped
        logic_append_match b Nil = b
        logic_append_match b (Cons x xs) = conso x (logic_append xs b)

It lets me take some advatage of Haskell’s built-in pattern matching and cleans things up quite a bit.

Hey look! I found a Monad!

One of the really interesting things about match that I didn’t notice at first is that
it, has a very similar type signature to the monad bind operator: =<<

match :: (a -> m (LVar b)) -> m (LVar a) -> m (LVar b)
=<<   :: (a -> m       b)  -> m       a  -> m       b

Is it possible to build a monad around match? It turns out: yes! This is the core idea behind my third iteration, which is starting to look a lot less like miniKanren.

In this implementation, match is implicit in monadic bind >>=. The main interesting consequence of this is that logic variable are abstracted away. A given piece of code in the resulting monad cannot tell the difference between a logic variable and a plain old
regular value. And in fact, if it could, that would mess up everything.

I’m still working on fleshing out the implications of this. I honestly don’t know if this is a really cool idea or a really dumb idea. Perhaps both?

The most obvious implication is that it saves a lot of wrapping and unwrapping to convert between logic variables and computations that produce logic variable. Though at first glance it doesn’t look like it grants much more than just some extra syntactic sugar for the ‘match’ function. But…

Laziness

One thing that appears to be a more significant implication is laziness.

In my previous iterations, when I defined customs datatypes to be used by the logic library, I put the logic variables right in the datatype like so:

data List a = Cons (LVar a) (LVar (List a))
    | Nil

Which worked fine, but it meant that I had to run all the computations that would produce those logic variables before I constructed an instance of my datatype.

In the new system, the list type looks like this:

data List f m = Cons (m (f m)) (m (List f m))
    | Nil

Which, first of all looks terrible (and I’ll talk more about that later), but secondly it lets me construct my list with just the computation that will produce the logic variable (or maybe just a value) rather than the logic variable itself. The computation is only run when the value is needed.

Going Forward

I’m still not sure if all this is a really cool idea or just a really dumb idea, but I’m learning a ton about relational/logic programming in the process.

My goal for my next iteration is to clean up the super ugly datastructures. Currently a custom datatype in the new system must be a higher-kinded type with higher-kinded parameters, which is not just ugly, but also a real pain. Defining your own datastructures and converting back a forth between the logic and regular variants of a datastructure is currently the biggest pain point in the new system. Fortunately, I think I can fix it.
 

The post Towards a Haskell Logic Library appeared first on Atomic Spin.

I recently came off a project where it is clear, in retrospect, that we operated in a rush throughout much of the last half of the project. The budget got extended more than once so that we could “just get it out the door.” It was a small project: a month or two initially, then another month part time working on “that last detail” and helping to transition it to the customer’s internal team.

This has led me to the conclusion that, when coming to the end of a budget, deciding under pressure to extend the work for “just another week” is a very bad idea. The technical decisions driven by a project size of six months are probably not the same decisions that you’d make on a one year project. When you find that your schedule is slipping, it’s important to make an honest review as soon as possible.

The overall size of a project is the best constraint you have for driving decisions and tradeoffs: “We have six months to work on this and will have time to build features X and Y for return on investment of $Z.” That information can inform decisions throughout the project. The problem is that when you make decisions based on the wrong constraint, you end up making the wrong decisions. For example, you might choose a technology you’re not familiar with if you have time for training. I’ve written about this before from the other side, describing why having too large a budget makes it difficult to know how much to refine features.

Where Things Went Wrong

Because so much of my recent project was based on a short timeline, we made a few decisions that I think I’d do differently in retrospect:

“Silo-ing” Information

I worked on one feature and allowed my colleague to work on another. We finished quickly, each of us not having to stop to teach the other about what we’d built. Then later, when it was just me, I was not equipped to debug it as effectively as I could.

This problem showed up on my customer’s side too — like me, they had too much to do, so we didn’t talk to each other nearly enough. Now — having a complex system with multiple interacting components — debugging is a more difficult proposition than it ought to be.

Not Taking the Customer’s Capabilities into Account

When I started, the customer did not have any full-time developers on staff, so I wasn’t driven towards choosing a tech stack their developers were expert in. Instead, I chose technology that I know well so there were no ramp-up costs. Because we had such a short target, we built a heterogenous system.

Now, they’ve hired a developer that is only expert in some parts of the technology stack. I think if I’d planned for the timeline we ended up with (after more than one “just one more feature”), I’d have chosen something more homogenous that fits their team better. On a short project, the time for me to ramp in to their tech might be a substantial proportion of the project, but on our final timeline, it would not have been nearly as significant.

Lessons Learned

A project’s schedule and budget are always necessarily estimates, and they are not always going to be correct. When you realize that your plan is not accurate, it’s important to adjust the plan. The problem with only extending the budget (instead of extending the budget and reviewing the plan) is that you’re still making decisions based on a plan you just proved was wrong.

Every decision I made was sensible at the time, but in aggregate I think things could have gone better. You should make sure to stick your head up regularly and take stock of the big picture. Frederick Brooks’ famous quote about from The Mythical Man-Month was appropriate in 1975, and it hasn’t stopped being true:

Question: How does a large software project get to be one year late?
Answer: One day at a time!

Problems accumulate a bit at a time. When you see a second or third 10% budget extension for “just one more thing,” you should ask “what has really changed?”
 

The post Budget Extensions Are a “Smell” appeared first on Atomic Spin.