Building an Automatic Fish Feeder

Hey there! I hope you have some fun Thanksgiving plans that include lots of gorging yourself and relaxing. Today’s song is an old favorite of mine.

I’ve been looking for a project for my Tessel2 microcontroller for a few months now. It’s cool because it allows you to program hardware using Javascript, which is my favorite.


With the coming holidays, I’ll be traveling for a few days. Since I’m the proud father of a Betta fish named Rhaegar, I wanted to make sure he stayed alive and happy, so I decided to make him an automatic fish feeder.


First, I printed out the model from Thingiverse.

Top-down view of the final print with the servo attached


It’s a pretty simple idea: a tank that gravity-feeds food to an auger. The auger spins with the help of the attached continuous-rotation servo, which is controlled by the Tessel.


3/4 view of the finished piece

Then, I wrote the code. I wanted to make sure the fish was fed every twelve hours, and that I was alerted when he was fed. I used Twilio as my text messaging service, which was super easy.



var tessel = require('tessel');
var servolib = require('servo-pca9685');
var servo = servolib.use(tessel.port['A']);
var twilio = require('twilio');

var servo1 = 1; // We have a servo plugged in at position 1
var TWELVE_HOURS = 60 * 60 * 1000 * 12; /* ms */

servo.on('ready', function () {
	var client = new twilio.RestClient('AC60444a3748dee195b9250b351b25f0f6', 'API_SECRET_GOES_HERE');

	var timeSinceLastFeed = 0;
  	var dispenseFood = function(){

  		if(((new Date) - timeSinceLastFeed) > TWELVE_HOURS) {
		//if(((new Date) - timeSinceLastFeed) > 1500) { //for testing at a faster pace
		            body: 'Fish is about to be fed!',
		            to: 'MY_PHONE_NUMBER',  // Text this number
		            from: '+18455354398' // From a valid Twilio number
		            }, function(err, message) {
	  		servo.move(servo1, .7); //moves clockwise at full speed
	  		setTimeout(function(){servo.move(servo1, 0.4)}, 75); //moves clockwise at slow speed
	  		timeSinceLastFeed = new Date();
	  		return true;
	  	else {
	  		console.log('It has been less than twelve hours since the last feeding; can\'t feed yet!');
	  		return false;
  	dispenseFood(); //run once on start
  	setInterval(dispenseFood, 60 * 60 * 1000); //check every hour, just in case
  	//setInterval(dispenseFood, 2000); for testing

Then, I did lots of testing. I needed to make sure the amount of food was consistent in each feeding, which was exceedingly difficult. I decreased the time between feedings and tried both worms and pellets to see which was the easiest to produce consistent results, and ended up with a mixture of both.

View post on

Testing the amount of time to spin the auger for optimum food release


Next, I pushed the code out to the Tessel to connect to our WiFi and run the program automatically on boot, which was as simple as

t2 push index.js


Then, I secured it to the top of the fishtank with some tape (hey, it’s a prototype. Don’t judge me.)

Affixed temporarily to the top of the tank
Affixed temporarily to the top of the tank

We’re still in the testing phase, so hopefully I don’t over/underfeed him. Bettas are pretty hearty fish, though, so I’m not too worried.


Thanks for reading! I hope you’re having a fantastic day. See you next time!

UI End-to-End Testing with Nightwatch.js

Good morning and Happy Friday! I’m back after a little prompting from an old friend.

Song of the day:

Quick life update: I’m living near New York City now, and I’m working as a Senior Software Engineer for a team that writes the software that supports such excellent blogs as Engadget, Huffington Post Australia (more international editions to follow!), and Autoblog, among many others.

I’ve also gotten way into 3D printing, Internet of Things development, and am still doing minor development on my open-source fitness project,

Today we’re going to talk about testing our front-end code. I know, I know, I’ve used the excuses myself: “I don’t have time! My deadlines are too tight.” “I need to test how something LOOKS, not unit test a function in my code.” “Writing tests is weird and unnatural.” “Deuteronomy says UI testing is an abomination.” Yeah.

Enter stage right: Nightwatch.js. Super simple to set up. I get to use Node.js to simulate clicks, typing, and key presses, and check to see if elements are visible. I also get to check properties of the elements. Plus, it runs against the industry-standard Selenium server.

Though the initial setup took about a day to get my code decently covered by tests, I can now rest a little easier knowing that when I release new feature updates to my software, everything will work.

Setting Up

Install guide
Also download:

I set up my folder structure like this:

project folder
…source files…
– bin
— chromedriver
— selenium-server-standalone-2.53.0.jar
– tests
— pages
—- pageCreateNew.js
— login.js
— createNew.js

I’m going to put my files up, with my comments inline for explanation.


  "src_folders" : ["tests"],   
  "output_folder" : "reports",
  "custom_commands_path" : "",
  "custom_assertions_path" : "",
  "page_objects_path" : "tests/pages",
  "globals_path" : "",

  "selenium" : {
    "start_process" : true,
    "server_path" : "bin/selenium-server-standalone-2.53.0.jar",
    "log_path" : "",
    "host" : "",
    "port" : 4444,
    "cli_args" : {
      "" : "bin/chromedriver", //THIS IS A BIG DEAL SO WE CAN TEST IN CHROME
      "" : ""

  "test_settings" : {
    "default" : { //runs when we don't pass in any options
      "launch_url" : "http://localhost:3000/management/splash/", //point this to whatever URL you want to test
      "selenium_port"  : 4444,
      "selenium_host"  : "localhost",
      "silent": true,
      "screenshots" : {
        "enabled" : false,
        "path" : ""
      "desiredCapabilities": {
        "browserName": "firefox",
        "javascriptEnabled": true,
        "acceptSslCerts": true

    "chrome" : { //runs when user runs `nightwatch --env chrome`
      "desiredCapabilities": {
        "browserName": "chrome",
        "javascriptEnabled": true,
        "acceptSslCerts": true

    "production" : { //runs when user runs `nightwatch --env production`
      "launch_url" : "",//point this to whatever URL you want to test
      "selenium_port"  : 4444,
      "selenium_host"  : "localhost",
      "silent": true,
      "screenshots" : {
        "enabled" : false,
        "path" : ""
      "desiredCapabilities": {
        "browserName": "firefox",
        "javascriptEnabled": true,
        "acceptSslCerts": true

Next, I wrote a tiny login function that I can call to get past authentication screens:


module.exports = function(client){
    return client
        .waitForElementVisible('body', 5000)
        .waitForElementVisible('#signinemail', 3000) //change the selector to whatever the username input is on the site you're testing
        .setValue('#signinemail', email_goes_here) //change the selector accordingly
        .waitForElementVisible('#signinpassword', 3000) //change the selector to whatever the password input is on the site you're testing
        .setValue('#signinpassword', password_goes_here) //change the selector accordingly
        .click('#signin_button')  //again, change this to the ID of the login button

One thing that’s really cool about Nightwatch is the ability to define pages. You get to define elements here and re-use them later in your testing code:


module.exports = {
  elements: {
    splashesListContainer: { 
      selector: '.splashes-list-container' 
    startFreshButton: { 
      selector: '.new-button'


Quick break.

Alright, and now we get to the meat of our testing code!

var login = require('./login.js'); //this is our login function from before

module.exports = {
  '@tags': ['create', 'splash'], //tags are used to run certain groups of tests; I'll talk more about this in a minute

  'can edit the first headline': function (client) { //name your functions like this so that the person running the test knows what's broken or working
  	var createNew =; 

  	login(client); //this is how easy it is to call our login.js script!

      .waitForElementVisible('@startFreshButton', 15000) //this is how we use the element selectors we defined in pageCreateNew.js
      .waitForElementVisible('#template-container .headline-1 .splash__header', 1000) 
      .click('#template-container .headline-1 .splash__header')
      .setValue('#template-container textarea', 'Automated Testing Is the Best!') 
      //custom color tests
      .waitForElementVisible('.showCustomColors', 2000)
      .click('.showCustomColors') //hide it
      //font size
      .setValue('#font-size-number-input', '80')
      .setValue('.anchorLink', '')
      .waitForElementVisible('#template-container .headline-1 .splash__header', 1000)
   //this is where we make our actual comparisons to see if everything is working!
    client.expect.element('#template-container .headline-1 .splash__header')'Automated Testing Is the Best!');
    client.expect.element('#template-container .headline-1 .splash__header').to.have.css('font-size', '80px');
    client.expect.element('#template-container .headline-1 .splash__header').to.have.css('color', '#2D7061');

As you can see, the syntax is really simple!

expect(elementSelector).to.have.css(style, value)



I am even able to test the type of my remote data store’s JSON schema with it by running AngularJS commands using client.api.execute(command)!

'is the schema set up correctly?':function (client) {
 var pageData=;
 var code;

 .waitForElementVisible('body', 10000)
 .api.execute("return angular.element($('.data-editor-form')).scope()['ctrl']['data']['schema']['properties'];", [], function(response) {
 code = response.value;
 var dataType = typeof code;

client.assert.equal(dataType, 'object');
 client.assert.equal(code['Data']['type'], 'array');




I’ve just barely scratched the surface of this fantastic automation framework. I envision being able to automate a ton of online stuff with this tool – it doesn’t just have to be used to test my code.


Discussion of the day: what would you automate to make your life easier? I’m currently working on an automatic window blinds project (I’ll write that up soon!)




Happy Saturday!

Good morning everybody! I strongly recommend you let this song melt into your ears while you read. 

It’s been a busy couple of weeks for me! I’ve been working on a big feature release at work, and in my free time, I’ve also been working on arkWatcher and ojo, two open-source Javascript projects. I ran into an issue with some of arkWatcher’s functionality that I posted to StackOverflow, and ended up getting some excellent guidance from my brilliant coworker Michael Timbrook. He suggested using Reactive Extensions to solve my problem, so I’ve been reading up on it the past day or two. It’s really cool, and builds quite simple functions into complex functions to solve big problems. So far, I’ve found this awesome YouTube video and this guide to help me learn more about it.


In other, non-programming, news, I’ve been swimming a ton lately. I love it, and it’s fun, but it’s made me noticeably more tired and hungry lately, so I probably have to eat more.

Speaking of eating more, check out this breakfast sandwich I custom-ordered at Lucky Donuts and Deli. Two glazed donuts, scrambled eggs, excellent bacon, and bubbly cheese. This was, without a doubt, the most craving-satisfying, stomach-filling, rich, delicious thing I’ve eaten in a long time.

View post on

I’m of the firm belief that you have to have a cheat meal once in a while, at least. This near-obscene, perfect sweet-and-salty combination is the cheatiest of all meals.

This month is just flying by, and I still haven’t come up with a Halloween costume. It’s weird – being on the West Coast for the first time, it doesn’t feel like Fall yet, so some part of me is in denial about what time of year it is. But the days are getting shorter. My friends back at home sent me tons of pictures of hail and snow and 20 degree temperatures last weekend, which seems a little early, even for the Northeast, although this week was apparently a gorgeous one. Here in San Diego, it’s been pretty nice with some occasional rain and cool temperatures. Here was the view on my porch this morning:

View post on

Yeah, I live next to a freeway. And a construction site. It’s pretty loud sometimes.

Pool’s nice, though.

This month, I really started pushing myself more physically, mentally, and with my work. I’m starting to enjoy and see great benefit from pushing past the limits of my comfort zone and moving as far into the learning zone as I can. I’m working on finding small optimizations that give me more time, and then using that time to get stronger.



The other day, my buddy asked my advice about which things he should prioritize in his life and which he should drop. The problem was – all the items he wanted me to choose from were equally important. The only answer I could give him in good conscience was that he had to do them all. If they’re all critically important items, what other choice does he have?

Sometimes, it feels like we have the barest illusion of choice;  really, we have no true choice at all. Sometimes we just have to stay awake later than we want; sometimes we have to concentrate longer and harder, and do more, than we ever thought possible. Sometimes, everything seems to go wrong all at once.

Important in my examination of these ideas is remembering how lucky we are to be given these challenges in the first place. How lucky we are that we have people all around us who’ve gone through similar things! I’m starting to treat each challenge as a gift, a lesson, and a test. A way to glean as much as possible from the brilliant and amazing people around me.

Anyway, that’s about it! Enjoy your weekend. Do something new.

Until next time!

NodeJS – Wrapping the Request() Module to Point Fingers at Services

Lately, I’ve been looking into tracing the route of service calls through chained services. Since many companies are moving toward a Service-Oriented-Architecture model, tracing when services are called is a crucial step in debugging. This way, when there’s an issue with a service, we know which one is breaking and causing everyone downstream to fail.

As a quick example of what I’m talking about, I’ve made a simple model:

Service A: returns “Hello”

Service B: returns “world”

Service C: calls A and B, then returns “Hello world”


Now, imagine service B is taking a long time to respond. Service C will be stuck, and we couldn’t be sure whether it was A or B who is causing the problem!

My goal is to get in the middle of those calls to services A and B and attach headers that track when those calls are made. First, I tried digging into my services’ Bunyan() logging modules and adding my interceptors there. Didn’t work.

Instead, after asking around work and on StackOverflow, I’ve decided to make my own NodeJS module that wraps around Request() and handles all of this for developers with them doing a minimal amount of work. Here’s what I came up with:

'use strict';
var request = require('request');

function spRequest( options, callback ) {


// check for our specific headers
if (options.incoming_req.headers['id'] == undefined) {
   console.log('No id passed to this service');
   console.log('I was given id ' + options.incoming_req.headers['id']);

// pass those headers boldly forward where no service call has gone before
var forwardHeaders = {
   id: options.incoming_req.headers['id']
   //add other headers here as needed

var forwardOptions = { //these are the options we'll use to call request()
   url: options.url,
   headers: forwardHeaders

// get start time for the call
var hrTime = process.hrtime()

// we use hrTime because it's more accurate than
var start = hrTime[0] * 1000000 + hrTime[1] / 1000;

// called when request() comes back with our data
function _onResponse( start, cb ) {
   var hrTime = process.hrtime()
   var end = hrTime[0] * 1000000 + hrTime[1] / 1000; //since hrTime is an array{milliseconds, nanoseconds} we have to do a bit of conversion
   var responseTime = end - start;
   console.log('request took ' + responseTime + ' milliseconds');

   return cb;

// and...GO!
   return request(forwardOptions, _onResponse(start, callback));

module.exports = spRequest

What’s really cool about this is that developers really only have to change one thing in their code. When making a HTTP request, they just have to include the request object in the call, like so:

Old way:

request('http://localhost:3000/hello', function (error, response, body) {...});

New way:

request({incoming_req: req, url: 'http://localhost:3000/hello'}, function (error, response, body) {...});

I learned a lot about functional programming today.

Do you like this? Is this something you’d like to read more about? Do you hate this and want me to write more about cooking or building physical things?

Let me know in the comments!

Happy Thursday, everybody!