Matt Beedle

Morning Routine

2015-09-27T00:00:00+00:00

I’ve been struggling a bit with productivity at recently, working for a startup, from home, with a 1 year old child. 9am I wake up, 2 hours later than I would like, then after a shower and 30 minutes work it’s time for family breakfast. Then my girlfriend is in the shower and I need to keep an eye on my son. Another hour of work, then it’s lunch time. Another couple of hours after that it’s dinner, getting my kid to bed, etc. Now it’s late, I spend several tired, less productive hours trying to cram a day of work in. I go to bed late and tired. Rinse and repeat. This routine has been really affecting my productivity, health, fitness, etc.

I’ve read a lot about how important good habits and a morning routine are for success. A good morning routine sets you up to win at your day and at life in general. Since this week I’ve implemented a new routine and it’s amazing. I’m now up every morning at 5:30am and started intermittent fasting again.

My Routine

1. Wake up at 5:30am and drink a large glass of water

When you wake up, whether you feel it or not, your body is dehydrated. Drinking a large glass of water not only rehydrates you, but apparently also has numerous thereputic effects. I leave a glass full next to my bed before I sleep so I can have it at room temperature instead of having to drinking freezing water straight from the cooler.

2. Have a freezing cold shower (5 minutes)

Benefits of a cold shower include better immune system, fat loss, improved circulation, temperature regulation, relief from symtoms of depression, health skin/hair, testosterone increase, fertility increase, energy increase, lymphatic movement, inflammation decrease, better breathing, better sleep, tolerance to stress. Wow, they are healthy. Also hard to start doing. I’m pretty sure the neighbours could hear me screaming on the first day. I’ve already got much more used to them now though after only a few days.

3. Brush teeth / get dressed (2 minutes)

Even working at home, it’s important to have the feeling of “going to work”. I wear pretty much the same clothes every day, so there’s no decision making there in the morning.

4. Meditate (15 minutes)

I use headspace for this, although I’m thinking of investing in a Muse headband.

5. Brew a bullet-proof coffee (10 minutes)

This stuff is really great. It gives me a huge morning energy/concentration boost. That being said I do seem to get less of a boost now than I used to. Maybe it’s one of those slippery slope things and I’ll end up doing morning lines of speed by next year. I brew my coffee using a stove top espresso maker. While that’s going on I do the washing up if there is any.

6. Read something (20 minutes)

I like to read something technical in the morning when my mind is most receptive. At present I’m reading JavaScript Allongé.

7. Write something (20 minutes)

I always used to be annoyed at myself for not writing any blog posts. Now, with 20 minutes per morning I should be able to pump out at least 1 per week. Hopefully I’ll get a bit faster at this with practice. Maybe now I’ll also find time again to continue writing the EmberJS/Rails book I started over a year ago.

8. Daily goals (5 minutes)

I review all of my tasks in OmniFocus. This used to take a long time but now I do it daily it’s really fast. I pick 3 things that need to get done for that day and flag them. I also do have a bunch of recurring flagged tasks in here.

Start working

In under an 1.5 hours I’ve already got a load of things done that I never normally have time for and I have a blissful 5 hours to work with no interuptions until workout/lunch time. During this working stretch I switch on “Do Not Disturb” in Notification Center, turn off AirMail/TweetBot/etc, and I work in Pomodoros using Vitamin-R At the moment I’m working for a startup (Groove where the development tasks are nicely planned out already in PivotalTracker and Github. If I were doing some other job I would probably need to add a day planning phase where I actually prioritise and plan out the tasks that I need to run through that day.

In conclusion I’m so far very happy with this experiment and can definitely see myself sticking to it. You should definitely give it a go too.

Git Cleanup

2014-08-16T00:00:00+00:00

My normal development workflow:

Create a new feature branch on my local machine for whatever project I am working on
Build the feature (testing first!)
Push the working feature to GitHub
Create a pull request
Pull request is reviewed/signed off
Click the “Merge” button on GitHub and then “Delete branch”
Checkout master on my local machine and pull the latest master from GitHub
Repeat

I should probably remember to always delete the feature branch on my local machine after it’s merged on GitHub. I never manage this. Sometimes I don’t do this for a very long time and end up with 30+ branches. Then I don’t remember which ones are merged so I don’t know which ones I can delete. Things get messy. So I wrote a quick Git Alias to help me out. To create the alias run the following command from your terminal:

git config --global alias.cleanup '!git checkout master && git branch --merged | grep -v "*" | xargs -n 1 git branch -d'

This alias will automatically delete all branches which have already been merged with master. Just run it from the root of your Git project.

git cleanup

I hope this helps simplify your life as it did mine.

Ember Data ISO Date Transform

2014-07-25T00:00:00+00:00

Most of my EmberJS projects use a datetime field somewhere on the backend. Reading them from the API is easy using a ‘date’ attribute type, but this doesn’t serialize to a very API friendly format. For example:

new Date().toString()
"Wed Aug 06 2014 12:39:29 GMT+0200 (CEST)"

My API expects to receive date times in ISO 8601 format. We can easily achieve this using MomentJS and an an Ember Data Transform.

bower install --save moment

app/transforms/isodate.coffee

`import DS from 'ember-data'`

IsodateTransform = DS.Transform.extend
  # The deserialize function just transforms the string it receives from the
  # server JSON response into a date.
  deserialize: (serialized) ->
    if serialized
      moment(serialized).toDate()

  # The serialize function takes the value of the attribute on the model and
  # transforms it into a nice ISO date to send to our server.
  serialize: (deserialized) ->
    if deserialized
      if deserialized instanceof Date
        moment(deserialized).toISOString()
      else
        # I'm using the European date format here. This is how date strings are
        # set on my models by my datetimepicker inputs. US readers may be able
        # to leave this second argument out
        moment(deserialized, 'DD/MM/YY h:mm a').toISOString()

`export default IsodateTransform`

Now in any models where it is needed, you can use your isodate transform.

app/models/user.coffee

`import DS from 'ember-data'`

User = DS.Model.extend
  createdAt: DS.attr('isodate')

`export default User`

Ember CLI Bootstrap Modals

2014-07-18T00:00:00+00:00

It’s really easy to create reusable modal code to integrate Twitter Bootstrap modals into EmberJS projects. Here’s how to do it:

TL;DR

Demo at http://ember-cli-bootstrap-modal.herokuapp.com

Code at https://github.com/mattbeedle/ember-cli-bootstrap-modal-example

The Modal code

The modal code is all the code that our modals will be built on top of. It consists of a ModalController, ModalView, openModal and closeModal actions, and a modal outlet. Links to demo app and working code are at the bottom of the article.

First, let’s create a basic application template with a modal outlet into which our modals will be rendered:

app/templates/application.hbs

<h2 id='title'>Bootstrap Modal with Ember CLI examples</h2>

{{outlet}}

{{outlet "modal"}}

Now we will define a ModalView. All modal views will inherit from this view. It ensures that modal settings are consistent across all modals.

app/views/modal.coffee

`import Ember from 'ember'`

ModalView = Ember.View.extend
  tagName: 'div'
  classNames: 'modal'.w()

  # didInsertElement is run once the element of the view has been inserted into
  # the DOM
  # http://emberjs.com/api/classes/Ember.View.html#event_didInsertElement
  didInsertElement: ->
    # First set the div id to "modal". "@$()" is the shortcut to get the view's
    # jQuery element
    @$().attr('id', 'modal')

    # Now set up the modal
    @$().modal
      keyboard: false
      backdrop: 'static'

    # Now show the modal
    @$().modal('show')

  # This is run when the element of the view is going to be destroyed. We
  # override it here to hide the modal first.
  # http://emberjs.com/api/classes/Ember.View.html#event_willDestroyElement
  willDestroyElement: ->
    @$().modal 'hide'

`export default ModalView`

Now we define a ModalController. This will handle the cancel action. All other modal controllers will inherit from this.

app/controllers/modal.coffee

`import Ember from 'ember'`

ModalController = Ember.ObjectController.extend
  actions:
    cancel: ->
      # If the controller @content is set, then we need to roll it back to avoid
      # inconsistent state between client and server.
      @content.rollback() if @content

      # Now we send "closeModal" event to bubble up to the application route
      @send 'closeModal'

`export default ModalController`

Now we need to define the global openModal and closeModal actions. We will do this in ApplicationRoute as everything bubbles up to here in the end.

app/routes/application.coffee

`import Ember from 'ember'`

ApplicationRoute = Ember.Route.extend
  actions:
    # This takes one argument; The template to render. It then renders it into
    # The modal outlet which we defined in the application template.
    openModal: (modal) ->
      @render modal,
        into: 'application'
        outlet: 'modal'

    # This handles removing the modal. It simply disconnects the modal outlet to
    # remove the modal. When this happens the "willDestroyElement" function will
    # be called on the ModalView, telling it to close the modal.
    closeModal: ->
      @disconnectOutlet
        outlet: 'modal'
        parentView: 'application'

`export default ApplicationRoute`

Building our first modal

At this point all of the code to handle modals is complete. Now we can actually create our first modal. Let’s do this with an action fired from our index template.

app/templates/index.hbs

<p><a href="" {{action openConfirmationModal on="click"}}>Confirmation Modal</a></p>

We will create an IndexRoute to handle the openConfirmationModal action.

app/routes/index.coffee

`import Ember from 'ember'`

IndexRoute = Ember.Route.extend
  actions:
    openConfirmationModal: ->
      # The "openModal" event will bubble up to the ApplicationRoute and be
      # handled there.
      @send 'openModal', 'confirmation/new'

`export default IndexRoute`

We will need a confirmation/new template now to be rendered.

app/templates/confirmation/new.hbs

<div class="modal-dialog">
  <div class="modal-content">
    <div class="modal-header">
      <button class="close" type="button" {{action cancel on="click"}}>x</button>
      <h4 class="modal-title">Confirm</h4>
    </div>
    <div class="modal-body">
      Are you sure about this?!?!
    </div>
    <div class="modal-footer">
      <button class="btn btn-default" {{action cancel on="click"}}>Nope</a>
      <button class="btn btn-danger" {{action confirm on="click"}}>Yes, do it!</a>
    </div>
  </div>
</div>

Now we will need to create a ConfirmationNewController to handle the events from the confirmation/new template.

app/controllers/confirmation/new.coffee

`import ModalController from 'ember-cli-bootstrap-modal-example/controllers/modal'`

# We inherit from ModalController to get the "cancel" action.
ConfirmationNewController = ModalController.extend
  actions:
    confirm: ->
      alert 'OK, it will be done!'
      @send 'closeModal'

`export default ConfirmationNewController`

Finall we must create a ConfirmationNewView that extends ModalView to get all of the modal view functionality.

app/views/confirmation/new.coffee

`import ModalView from 'ember-cli-bootstrap-modal-example/views/modal'`

ConfirmationNewView = ModalView.extend()

`export default ConfirmationNewView`

Notes & links

So that’s it. Simple Bootstrap modals in EmberJS. I’ve created a demo app and published it to GitHub. It includes a confirm modal, information modal and a form modal (using ember-easyForm, ember-validations and ember-data LocalStorage).

Demo at http://ember-cli-bootstrap-modal.herokuapp.com

Code at https://github.com/mattbeedle/ember-cli-bootstrap-modal-example

File Uploads in Ember Data

2014-06-25T00:00:00+00:00

Recently I’ve been working on an EmberJS application (SalesFlip - go register there now) which needs to allow file uploads. There are a couple of different approaches to this which I’ll discuss here, along with a new one which I would like to propose. If you are wondering what all the import and export statements are in the examples below, it’s because I’m using Ember App Kit. You should use it too!

HTML5 FileReader API

https://developer.mozilla.org/en-US/docs/Web/API/FileReader

The HTML5 FileReader API is fine for really small file uploads outside of models. It seems to be the currently recommended solution on StackOverflow. Just create an UploadFile view and then bind the file attribute to the relevant attribute in the model. However, the ember-data adapter will then upload the file as a data URI via JSON. This proved pretty much useless for me. Anything over around 60k would fail.

app/models/user.coffee

User = DS.Model.extend
    avatar: DS.attr('string')

`export default User`

app/routes/users/new.coffee

UsersNewRoute = Ember.Route.extend
    model: ->
        @store.createRecord('user')

    actions:
        save: ->
            @currentModel.save()

`export default UsersNewRoute`

app/templates/users/new.hbs

view "upload-file" name="avatar" fileBinding="avatar"

app/views/upload_file.coffee

UploadFile = Ember.TextField.extend
    tagName: 'input'
    attributeBindings: ['name']
    type: 'file'
    file: null
    change: (e) =>
        reader = new FileReader()
        reader.onload = (e) =>
            fileToUpload = e.target.result
            Ember.run =>
                @set 'file', fileToUpload
        reader.readAsDataURL(e.target.files[0])

`export default UploadFile`

Custom FormData Upload View

With this approach (adapted from here) we define an upload button view which will upload the file on change. This would require some backend magic to work for new users (ones without an ID). Perhaps the file could be saved and then associated with the user when the user is saved.

app/templates/users/new.hbs

view "upload-button" userBinding="user"

app/views/upload_button.coffee

UploadButton = Ember.View.extend
    tagName: 'input'
    attributeBindings: ['type']
    type: 'file'
    originalText: 'Upload Finished Product'
    uploadingText: 'Busy Uploading...'

    newItemHandler: (data) ->
        @get('controller.store').push('item', data)

    preUpload: ->
        parent = @.$().closest('.fileupload-addbutton')
        upload = @get('uploadingText')

        parent.addClass('disabled')
        @.$().css('cursor', 'default')
        @.$().attr('disabled', 'disabled')

    postUpload: ->
        parent = @.$().closest('.fileupload-addbutton')
        form = parent.closest('#fake_form_for_reset')[0]
        orig = @get('originalText')

        parent.removeClass('disabled')
        @.$().css('cursor', 'pointer')
        @.$().removeAttr('disabled')
        form.reset()

    change: (e) ->
        formData = new FormData()
        @preUpload()
        formData.append('user_id', @get('user.id'))
        formData.append('file', @.$().get(0).files[0])
        $.ajax
            url: '/file_upload_handler/'
            type: 'POST'
            # Ajax events
            success: (data) =>
                @postUpload()
                @newItemHandler(data)
            error: =>
                @postUpload()
                alert('Failure')
            # Form data
            data: formData
            # Options to tell jQuery not to process data or worry about content-type.
            cache: false
            contentType: false
            processData: false

`export default UploadButton`

Ember Data FormData Adapter

This is the approach that I have settled on. I created a FormData Adapter which is used by any models which require file upload. Using this approach, adding file uploads to another file is just a matter of creating a new adapter for it which extends the FileUpload adapter. Although I haven’t tried it, it should be easy to combine this approach with the HTML5 File Reader approach to generate image previews and validate file information before uploading.

First define a transform so that files are left untouched

app/transforms/file.coffee

FileTransform = DS.Transform.extend
  serialize: (jsonData) ->
    jsonData

  deserialize: (externalData) ->
    externalData

`export default FileTransform`

Use the newly defined “file” attribute type

app/models/user.coffee

User = DS.Model.extend
    avatar: DS.attr('file')

`export default User`

Create a FileUpload input. This is what assigns the file to the model

app/views/file_upload.coffee

FileUploadView = Ember.View.extend
    content: null
    type: 'file'

    change: (event) ->
        if event.target.files.length > 0
            @set('content', event.target.files[0])
        else
            @set('content', null)

`export default FileUploadView`

app/templates/users/new.hbs

view "file-upload" contentBinding="avatar"

Create a FormDataAdapter. This is what handles uploading the data via FormData instead of the default JSON.

app/adapters/form_data.coffee

`import ApplicationAdapter from 'appkit/adapters/application'`

get = Ember.get

FormDataAdapter = ApplicationAdapter.extend
  ajaxOptions: (url, type, hash) ->
    hash = hash || {}
    hash.url = url
    hash.type = type
    hash.dataType = 'json'
    hash.context = @

    if hash.data and type != 'GET' and type != 'DELETE'
      hash.processData = false
      hash.contentType = false
      fd = new FormData()
      root = Object.keys(hash.data)[0]
      for key in Object.keys(hash.data[root])
        if hash.data[root][key]
          fd.append("#{root}[#{key}]", hash.data[root][key])

      hash.data = fd

    headers = get(@, 'headers')
    if headers != undefined
      hash.beforeSend = (xhr) ->
        for key in Ember.keys(headers)
          xhr.setRequestHeader(key, headers[key])

    hash

`export default FormDataAdapter`

Create a UserAdapter for the User model to use

app/adapters/user.coffee

`import FormDataAdapter from 'appkit/adapters/form_data'`

UserAdapter = FormDataAdapter.extend()

`export default UserAdapter`

USDA Nutrient Database Web Service

2014-05-30T00:00:00+00:00

The US Department of Agriculture provides a fairly comprehensive database of foods and their nutritional information. However, I think they don’t really want anyone to use it, as it’s only available as separate US-ASCII text files or, even worse, an MS-Access database.

Some time ago I found myself needing this data in a web app, so I built the USDA Nutrient Database gem. It’s very simple, and basically just downloads and imports the text files into your application database.

The Web Service

Recently Corey Martin wrote a blog post about using my gem along with some others to build smarter nutrition labels for CookSmarts. In it he mentions them building their own server just for serving nutrient information, which eventually inspired me to build this service. It provides all of the same data, but additionally adds full text search, pagination, caching, and soon weight conversions. I’ll be keeping the data up to date and will be providing product support. Feature requests may be sent through UserVoice. Maybe I’ll throw an object mapper gem together in the coming months, to allow people to deal with ruby instead of JSON. Anyway, you can find the USDA Nutrient Service here… Enjoy

TL;DR

I built a web service that you can use to query the USDA National Nutrient Database. You can find the docs at http://docs.usdanutrientservice.apiary.io/. It provides querying, full text searching, pagination, caching, and is also kept up to date with the latest data.

Ember App Kit: EMFILE, too many open files

2014-01-26T00:00:00+00:00

Recently I ran into an issue with an Ember App Kit app that I’m working on. With livereload enabled the development server is reloaded every time a file is changed, including the bower dependencies installed in vendor. As the bower dependencies grow there is soon a point where the number of files being watched exceeds the allowed limit for the operating system.

Mac OS X limits the number of open files to 256 by default. There are two types of limit. The soft limit and the hard limit. The soft limit is the currently enforced limit. The hard limit is the maximum value which the soft limit may not exceed. The simple solution is to add the following to your .bashrc:

ulimit -n 2048

If this doesn’t work you may need to increase the hard limit. To do this set the following in /etc/sysctl.conf:

kern.maxfilesperproc=166384
kern.maxfiles=8192

Deploy Feature Branches to Heroku with Heroku Feature Deployments Gem

2014-01-10T00:00:00+00:00

The Short Version

Deploy the branch you are currently on to Heroku, create a Pull Request, configure DNS and report in PivotalTracker with my Heroku Feature Deployments gem using the following command.

rake hfd:deploy

And tear everything down again with:

rake hfd:undeploy

The Long Version

The problem

I often find that one major bottleneck in the process of building and shipping software is testing features. Perhaps 1 feature is pushed to the staging server for testing, and the feature owner is working with the developer to iron out any kinks. While this is happening no other developers can push to staging. Perhaps the other developers don’t realise this, and keep pushing and wiping out each others work before it can be tested. The more things that are being worked on at once, the worse the problem can get.

The (temporary) solution

When we developers use git we create a feature branch where all of our changes go, then create a pull request in GitHub, and then it is merged in after a code review. Why not also use feature deployments? Heroku is perfect for quickly deploying temporary sites as long as your infrastructure is immutable.

My idea for a process is this:

Developer takes the next story/task/feature from the project managment tool
Developer does required work
Developer creates a pull request in GitHub
Developer creates a new Heroku app and deploys the site there
Developer sets up the DNS so that the site runs on a subdomain. (http://FEATURE_NAME.mattbeedle.name for example)
Developer adds this link to the project managment tool and marks the story/task/feature as ready for testing
Feature Owner tests the functionality on the subdomain and accepts the work (hopefully)
Developer deletes the Heroku app, DNS settings, etc
Developer marks the pull request as ready for review in GitHub
Team reviews the pull request and merges into master
CI server runs tests and if all passes then deploys to the live site

The only issue with this really is that no-one wants to spend so much time creating Heroku apps, configuring DNS, etc.

In order to automate this we’ve been using a very simple gem which I hacked together in a couple of hours and have been gradually adding stuff to for the past year. This gem will handle the following functionality:

Deploying

creating a Heroku app for the current branch
adding any required Heroku addons (memcached, redis, etc)
adding collaborators to Heroku app (the rest of the development team in case they also need to work)
configuring DNS to setup a subdomain
creating a pull request in GitHub
adding a link to the story in the PivotalTracker

All handled by 1 rake task:

rake hfd:deploy

Tearing Down

Deleting the Heroku app
Removing DNS settings

rake hfd:undeploy

This process has worked very well for us so far. The reason it’s a temporary solution is that the gem right now sucks. It’s does not have automated tests and it’s tied to Heroku/DNSimple/PivotalTracker. I’m going to start working soon on a hosted configurable deployment tool which integrates with many other services and has an API so that deployments may be started by a CampFire/HipChat/IRC bot.

Replicate Heroku Production Data in Development

2013-11-22T00:00:00+00:00

The Short Version

Quickly replicate a Heroku production applications database to your rails development database with the following command:

./script/replicate

The Long Version

Sometimes when I have a project in production a bug occurs which I am unable to replicate on my development machine without a copy of the production data. Grabbing production data is a task that should be automated. Here’s a simple bash script that I use in all of my heroku apps. Put the file in your rails script folder:

#!/usr/bin/env bash

echo "Running: heroku pgbackups:capture --remote production"
heroku pgbackups:capture --remote production

echo "curl'ing the latest.dump"
curl -o latest.dump `heroku pgbackups:url --remote production`

echo "restoring the dump"
pg_restore --verbose --clean --no-acl --no-owner -h localhost -U postgres -d
project_name_development latest.dump

echo "removing latest.dump"
rm latest.dump

The git remote for my heroku production app is always named “production”. If yours is different make sure that you rename it in the script. Also change the database name to the name of your development database. Finally, make the script executable:

chmod+x script/replicate

Initialize

2013-11-10T00:00:00+00:00

Blog.new name: 'Blog attempt number 5!'

Yet another attempt at a blog. Since 2006 I’ve blogged on matt-beedle.com and then mattbeedle.com. Once with over 1000 UVs per day. Unfortunately I never seem to manage to keep it up. Both domains were eventually forgotten about and expired, all the posts only remaining now in the web archive. At least this time everything is stored in Git on GitHub! Let’s see how long it lasts for.

I’m planning to blog about code and startup experience. Stay tuned.