Writings

Webstorm is pretty good for Angular Development (I only have a few qualms); but one behavior that’s annoying is that it searches all folders in a directory when looking for usages.

For instance, in the Jewelbots App repo if I search for files named controllers.js, I get both app\ references and www\ references:

But in this setup, www is really just an output directory. When I run grunt build; that’s where all the files go for deployment.  So it doesn’t actually help me to search there.

It turns out, there is a way to ignore or exclude certain folders from search:

• Right click directory you want to exclude
• Go to “Mark Directory as”.
• Choose “Excluded”

Now when you search, files in that directory won’t show up in the results:

A little over four months ago now, I joined Jewelbots. I also wrote a retrospective on the first four months.

When I first joined Jewelbots, Sara mentioned that they’d either cover me working from home (pay for internet) or they’d cover me working from a co-working space. Since I’d had mixed results with Working From Home previously, I elected to take a serious look at co-working spaces.

Here’s why I didn’t join one.

1. Coworking Spaces aren’t built for productivity. If you’ve ever heard me rant about open office floor plans (twitter, blog post), then you know I dislike them immensely. The chief reason is that they foster collaboration at the expense of productivity. If you spend 8+ hours a day doing something, don’t you want to feel like you accomplished something meaningful at the end of those 8 hours? What about if ‘meaning’ in your line of work meant releasing code?

Collaboration is a great goal if that’s what drives your business (It’s even a good idea otherwise; except that you have nothing to collaborate on if you go out of business). If software drives your business, then perhaps you should optimize for creating software?

See? There I go again. Even in a blog post about coworking spaces, open office floor plans rear their ugly head. I probably won’t edit that out.

My point is, coworking spaces are generally open offices (most money per sq. ft. that way), and open offices do not enhance productivity.

Why would I pay to be in a space that makes me less productive?

2. Coworking spaces don’t let you control your environment. As I write this, I’m on a standing desk with three monitors, a laptop, a freshly painted room, and standing pads. Oh, and I have a smattering of dev boards, an iPhone for testing, and a Ladycorn I was supposed to ship out last night. How easy would this set up be to replicate at a coworking space? The three monitors would be out; the standing desk would be a huge if (if no one else grabbed it that day), and I certainly wouldn’t have the comfortable chair. That brings me to the next point, money.

3. The economics don’t work for productivity. In order to get that same setup (I paid for all this, btw) in a coworking space; I’d have to pay for a private office (about $600 a month), sign a year lease, and have all of this shipped there.

That’s just not economically feasible for a single remote employee to do in a startup. In order to pay for itself, I’d have to be $7200 a year more productive than I would be otherwise, and that’s just for office space. That doesn’t count the desk, the chair, the monitors, the arms, or any of the other accessories (around $3000 all told).

4. The choices just aren’t that great. I live in Springfield, VA. For those of you that don’t know the dynamics of the Washington DC area; I live at the end of the Blue Line. If I want to travel to Arlington (the ‘major’ metropolitan center that isn’t DC), I’d have to spend 20-30 minutes (each way) on the Metro each day; in addition to the 10 minutes to commute there and back. If I want to go into DC; that’s another 20-30 minutes (depending on the day). At best that’s an hour to get to and from work, at worst it’s 2 hours. And that’s if nothing goes wrong (which it does, all the time). In Arlington, there are currently two choices for Co-working spaces; one’s part of an unused coffee shop, and the other is a small office space above a bank.

5. You can’t control internet speed or connectivity.

Testing out Coworking Spaces. this place has a great vibe, but terrible wifi. If I can’t deploy EB, I can’t work.

— George Stocker (@gortok) March 23, 2015

Internet’s really important to programming. In this instance, I couldn’t do something as simple as deploy our site to Elastic Beanstalk because the internet was terrible. That’s a bad thing. What would have happened if our site went down and the internet went down at the same time?

Coworking spaces are probably great. But they don’t work for everyone, and after trying it for a few days, I realized they didn’t work for me either. They embody all the bad parts of an open office floor plan and working at Starbucks, all while paying for the privilege.

It was four months ago that I joined Jewelbots.

Four months. Seems like a lifetime ago.

This has been the second time in my career that I’ve been doing remote work full time; the first time was when I was very much a junior programmer.

Here’s what I’ve learned in these four months:

1. It’s hard to separate work and home. Really, really hard.  When commuting to another place, it takes physical effort to go back and do work; and that is (shamefully?) usually all that’s enough to make sure work stays at work. At home, I can just drift downstairs and get some work done.

2. It’s hard to separate piddling around with actual work.  Yea, I put in more hours; but do I really get more done?  Probably not.  There’s laundry to switch out, animals that want attention, etc.  So while I may put in 10-12 hours a day, I’m probably closer to the south side of ‘8’ for hardcore work.

3. Having a quiet space is even more important at home.  My current office setup includes no door; and until I move my office into a space with a door, it’s super important that I’m either with headphones or that the house is quiet. Since my wife and kids are home for the summer, that means great headphones.  I also recommend “Music to Code by” (originally recommended to me by Jonathan Sampson).  It was composed by Carl Franklin, programmer and host of the .NET Rocks! podcast.

4. All conversations must be in a digital medium. Working with people who are in an office together means either all conversations have to go through Slack, or missing out on critical information.  Brooke and Sara both work in our NYC office, and since they’re in a small office together, they can easily share information. Because I’m not in said office, I have to be extra sure to stay up to date.  David Fullerton talks about this issue in the blog post “Why We (Still) Believe in Working Remotely“:

You have to commit to it as a team (and a company). There’s no halfsies in a distributed team. If even one person on the team is remote, every single person has to start communicating online. The locus of control and decision making must be outside of the office: no more dropping in to someone’s office to chat, no more rounding people up to make a decision. All of that has to be done online even if the remote person isn’t around. Otherwise you’ll slowly choke off the remote person from any real input on decisions. (non-bold/italic emphasis mine)

This is something we’ve worked through as a team, and it’s gotten easier; but it is tough to do at first. Would you rather say something to the person standing in front of you or would you rather get on a Slack Channel and type it to that same person?

5. Virtual Coffee is a must. Working remotely means having less opportunity to interact, which makes those daily interactions all that more important.  Everyone needs feedback on what they’re doing, what they should continue doing, and what they need to be redirected on.  Working Remotely means scheduling explicit time for that so that it happens.  We’ve had good success having a bi-weekly feedback session; and even if there’s no feedback to share, it still gives us time to connect with people we work with.  Think of it like getting coffee together — virtually.

6. All Progress must be visible or reportable. I spent time porting a bluetoothle library over for use in Ionic (long story short, the other library didn’t support the latest version of Cordova).  Normally that’d be a blurb in a standup, but remotely, that counts as part of my output.  Since we use Slack, it’s really easy to set Slack up to report Git pushes.  Unfortunately, there’s no easy way to have a Slack Integration for reporting conference calls, emails sent, or any other work that doesn’t really seem like work until you’re remote. To combat that, we share our Google Calendars, and everything we do goes on our calendar.  With a bug with Shared Calendars in Sunrise, that sometimes means me popping in on a meeting I shouldn’t, but for the most part it works.

7. Being open about strengths and weaknesses. It seems antithetical to workplace advancement; but it’s absolutely crucial in a remote work situation.  I talk about my weaknesses because even thought it’s uncomfortable for me, it’s crucial to ensuring frank communication, and when you’re working remotely, you don’t have those normal cues to know how you are being perceived. Candor is a strength.  This doesn’t only mean sharing your weaknesses, it also means sharing your wins.

8. Having a hangout devoted to wins is important. Software Development (and Startups?) means failing 500 times only to have it work the 501st time.  It’s easy to focus on the failures; but the wins are so much more important to the team.  Take time to share nothing but wins.  Brooke set up a Weekly “Wins Hangout”, and it has been beneficial.  The whole team gets together and talks about what their ‘wins’ were that week, no matter how small.

9. Invest in making your workspace better. In an office, you can’t control your environment as much, but since it’s so important to happiness, it’s absolutely crucial for a home office.  We even went so far as to paint the Maroon basement a soft Yellow to reflect light instead of absorb it. It worked wonders.  I also purchased a sit/stand desk that doesn’t break the budget because that little extra control helps.

10. Keep a schedule that works mentally, physically, and emotionally. I’m still struggling with this. Since it’s easy to start work early, and I want to show that I’m valuable, I’ll work at all hours instead of what I’d do at an office: have a schedule. I need to work out to stay fit and work at specific hours.  If I were going into an office, I’d be up at 6, working out by 6:30, and in the office by 8.  That’s harder to replicate remotely (since there’s no gym next to my office), but it’s something I have to do to stay emotionally, mentally, and physically healthy.  This is where coworking spaces near a gym could help, but coworking spaces have their own problems (that’s for another blog post).

What do you do to make remote work work for you?

Post updated to reflect the original recommender of the Music to Code By composition.

Our Kickstarter launched yesterday. There’s been a lot of work to get to this point, but one question I keep hearing is a variation of “I’m not a girl, so why should I care about Jewelbots? Why should I back your product?”

That’s a great question, even if it’s really two questions.

Here are a few reasons why you should be excited about Jewelbots, even if you aren’t a girl.

1. Jewelbots are open source.  You like open source, right? This is your chance to
fund a completely open source product.  From 3D designs for the charm, to the firmware, to the board; it’s all open. We believe part of our mission is to help educate; and part of education is having examples to work from. More over, we want to see all the interesting things that people can do and make with their Jewelbot;  products should encourage that behavior, not inhibit it.

2. Jewelbots have a lot of applications. The inner workings of the Jewelbot are essentially a newest-generation Bluetooth Low Energy device capable of sending and receiving messages to other BLE devices.  Pair this with another Jewelbot or with your phone and you have a tracker for your wayward dog, or an early warning  system, or even a phone finder.

3. You can 3D Print your own Charm. Growing up in the 80s and 90s  we had shows like The Power Rangers, The Legend of Zelda, and Thundercats.  Haven’t you always wanted to have your own Thundercats glowing emblem, or your own Power Morpher, or your own Ether Medallion? Well, I have.  Because we’re engineering Jewelbots to be printable; you don’t need to stick with the stock flower charm; you can customize it based on what you are interested in.

4. Jewelbots are more than a product, they’re a platform. Jewelbots are a mesh network of wearables that can communicate over distances with BLE;  This has lots of untapped potential. Why limit ourselves to wifi or cellular networks to send and receive messages?

5. Supporting Jewelbots supports a social Good. Jewelbots the company is committed to getting girls interested in STEM.  We’ve already run two hackathons geared towards exposing girls and children in general to STEM, and we want to run more.  By supporting Jewelbots, you’re supporting our mission to broaden technology’s appeal.

As a bonus, supporting Jewelbots also means supporting behavior from companies we all want to see more of. Help us make that happen.

While deploying an update to Jewelbots.com (transitioning the site over to node.js so that we can use Mailchimp’s server-side API), I ran into an issue where Elastic Beanstalk’s integrated eb deploy feature will only deploy files git is tracking when a git repository is present.

If you want to deploy API Keys, but don’t want them tracked in git, this presents a problem.

I took to twitter to ask for help:

How do other devs handle custom files that aren't checked into source control (like keys) but need to be deployed with eb deploy? #aws

— George Stocker (@gortok) May 31, 2015

The responses trickled in:

@gortok only answer I have found is have a private repo and when you push to public repo exclude keys, want something better though

— SQL & CI = happyland (@EdDebug) May 31, 2015

This is… sub-optimal, to say the least.

Luckily, a member of the Elastic Beanstalk team responded:

@gortok add a .ebignore file.

— Nick Humrich (@nhumrich) May 31, 2015

And further elaborated:

@gortok http://t.co/iRU1g5ZY6q

— Nick Humrich (@nhumrich) May 31, 2015

@gortok yes, ebignore overrides gitignore, so just add an ebignore with ".git/" in it.

— Nick Humrich (@nhumrich) May 31, 2015

Excellent! By adding an .ebignore file that is set up to ignore files I don’t want deployed, I can ensure that all of my project files are deployed. The .ebignore is in fact, an .ebdontdeploy.

This is a very new development; so new that it was still being requested in April. My hat’s off to the Elastic Beanstalk team (and especially Nick Humrich) for cluing me in to it. I only wish it was linked to by other parts of the Elastic Beanstalk 3.0 CLI docs.

If you need to deploy files that aren’t tracked by git to elastic beanstalk, .ebignore is the answer.

State transitions in AngularJS are surprisingly hard to unit test.

Assume the following scenario:

A user opens their app, and the app checks to see if they’ve paired to a Bluetooth device. If they have, the app sends them to their home screen. If they haven’t, the app sends them to the pairing screen.

Let’s create a test for it, assuming AngularJS as the framework:

The App

var app = angular.module('plunker', ['ui.router']);
app.config(function($stateProvider, $urlRouterProvider) {
  $stateProvider
  .state('home', {
    url:'/',
    controller: 'MainCtrl',
  })
  .state('pair', {
    url:'/pair',
    controller: 'PairCtrl'
  })
  $urlRouterProvider.otherwise('/');
});
app.controller('MainCtrl',['$scope', '$state', function($scope, $state) {
  $scope.name = 'World';
  $scope.isPaired = function(paired) {
    //in place of Service call; just use parameter.
    if (!paired) {
      $state.transitionTo('pair');
    }
    else {
      return paired; 
    }
  };
}]);

And the test:

it('should transition to pairing state if device is not paired',   function() {
  $scope.$apply();
  expect($state.current.name).toBe('home');
  $scope.isPaired(false);
  $scope.$apply();
  expect($state.current.name).toBe('pair');
})

This code works. And it works well. But what happens if you suddenly include `templateUrl`s in your routing code?

$stateProvider
.state('home', {
  url:'/',
  controller: 'MainCtrl',
  templateUrl: '/home.html'
})
  .state('pair', {
  url:'/pair',
  controller: 'PairCtrl',
  templateUrl: '/pair.html'
})

All of a sudden, the unit test breaks with the following error:

Error: Unexpected request: GET /home.html
No more request expected

What happened?

When the templateUrl parameter was included, ui-router suddenly decided it needed to make a request to that URL on $scope.$apply() (also on $scope.$digest()).

Because that URL doesn’t exist in our world (we are unit testing, after all), the test fails.

The way to “fix it” is to include a mock that will ignore requests by responding to them as if they were 200s:

it('should transition to pairing state if device is not paired', function() {
  $httpBackend.when('GET', '/home.html').respond(200);
  $scope.$apply();
  $httpBackend.flush();
  expect($state.current.name).toBe('home');

  $scope.isPaired(false);

  $httpBackend.when('GET', '/pair.html').respond(200);
  $scope.$apply();
  $httpBackend.flush();
  expect($state.current.name).toBe('pair');
})

The downside to this approach is your Unit tests now are much more brittle than they should be. Any time a route is changed/added to your workflow, you have to change these tests, even though you shouldn’t have to.

There is a state-mock.js that encourages mocking out the entire $state so the UI-Router doesn’t take over, but that’s also more plumbing code that shouldn’t exist.

In an ideal world, UI-Router would be patched to allow for easier unit testing.

In building the software infrastructure as a startup, you generally have a few options:

1. Build custom Backends on top of an IaaS provider (AWS, Rackspace, or Azure)

2. Build your own Hardware and COLO at a Data Center,

3. Use one of the Pizza Delivery as a Service Providers; SaaS, PaaS, or MBaaS.

Which you choose is highly dependent on your needs:

1. Is your software infrastructure critical to your business?

2. How much downtime can you withstand?

3. How much control do you want over performance? Latency? Stability? Bugs?

4. How much cash do you have?  Can you afford to weigh multiple approaches that may span tens of thousands of dollars in development time decisions regarding #3?

I’m talking about this because I’m neck deep in these choices.

 My initial plan was to use AWS: I’m familiar with it, it’s run by a giant in the industry, and it’s unlikely that it’s going to go down any time soon.  The problem with choosing AWS is that for our needs, they only go as far as the Infrastructure: All of the Database, Backend, API, and networking infrastructure is left up to me (in this particular use case).  I’m familiar with that, so that that doesn’t bother me, but what does bother me is the time/cost tradeoff.  For the sake of argument, let’s assume a normal developer costs 12-15K per month (assuming NYC or DC; San Fran is probably a bit more).  If we also assume it’ll take a month of development time to build the backend, then we can safely say it’ll cost 12K for the backend  (This doesn’t take into account the cost of the IaaS; which is a few hundred a month, starting out — sometimes less).

The biggest problem with that 12K number isn’t the number itself — it’s non-trivial, to be sure, but the real cost is the opportunity cost.  The time spent building a backend is not spent building a product; it’s not spent making sure the product gets out the door to get traction/testing/money/all those things that Startups depend upon.

Another option for my specific use case is to use a MBaaS, (pronounced “Mmmm Bass”, but not nearly as delicious) or a “Mobile Backend as a Service” as they’re known.

The largest one out there is Parse.com, and they’re powered by Facebook.  They’re by far the most startup-oriented MBaaS provider I’ve seen, but they’re not the only one.  They also frighten me a little bit, especially with their reliability and bugs.

In researching this blog post, I took a look at all of the MBaaS providers mentioned in this Hacker News post, as well as their cost, focus, and whether or not they’re still alive as a MBaaS.

So there you have it, out of 15 providers, 6 are dead (or appear dead), 9 are still around. It appears that most are either targeting Enterprise customers or Game developers.

There are only two conclusions I can draw from this:

1. If you choose to go the MBaaS route, you have a high probability of losing your provider.
2. Go Enterprise or Go Home.

**Update**: Kinvey’s CEO notes that Kinvey has a ‘Starter’ pricing, Essentially free for startups for development.

Nb: In the intervening time, we changed our name to Jewelbots.

“Do you want to change the world?”

I hear it everywhere, and it’s normally crap. Your Uber-meets-Spotify-meets-AirBnB-meets-your-appetite-for-food-at-2am idea is not going to change the world.

I’ve heard it so much I’ve become jaded. I actually repel when I hear those words.

That was before I knew about Jewliebots.

I’ve known Sara Chipps since I’ve known about Twitter. She was one of the first tech people I followed. She produced a rad video on Ada Lovelace, and her enthusiasm about technology has always been inspiring to me.

When she first talked about Jewliebots in her medium posts on building a hardware startup, I became even more interested. My first and sole thought was: How do I become a part of this?

Let me step back. Jewliebots is (in our parlance) wearable jewelry aimed at exposing young girls to programming. It’s one part Minecraft, one part Arduino, and all social. In short, it aims to make programming interesting and accessible for young girls.

It also has the potential to change the world.

After meeting with Sara and Brooke and the rest of the team behind Jewliebots, I was even more on board.  Here I was, interviewing for a startup with a goal I believe in and the potential to work with people I believe in.  Normally it’s either a company I believe in or technology I’m passionate about; I’ve never been in the situation where both apply.

I’ve only been happier three more times than the moment Sara and Brooke offered me the chance to work on Jewliebots: my wedding day and the birth of my two daughters.

I believe in Jewliebots, I believe wholeheartedly in our mission, and I’m proud to say that starting today, I’m employee #1 and VP of Software Engineering at Jewliebots.

My goal: to make sure the software that powers Jewliebots meets our mission and to build a team who shares that goal.

I’ve never felt more strongly about anything in my professional life.

If you’re interested in learning more about Jewliebots and potentially joining us, please drop me a line. I’d love to hear from you.

Today marks my last day at Higher Logic, and with it marks a year+ of working to build up the software infrastructure from startup to sustainable.

I’ve really enjoyed my time here; a year ago I had no knowledge of AWS, and a developer’s knowledge of SQL Server. I had only shipped one JavaScript project, and was still uncomfortable just going out and ‘doing’ on my own.

That year has also included:

• Marking one year as a DBA; and 2 years as a Full Stack Developer.
• migrating 500 databases from SQL Server 2008 to SQL Server 2014
• Planning and implementing a Disaster Recovery solution for 500 databases;
• Shipping Higher Logic’s Widgets platform
• My first, second, and third pull requests into open source projects
• writing fixes for Video.JS playlist plugin
• digging deep on SQL Server improvements; query optimization and production troubleshooting
• Making lots of mistakes along the way
• Refactoring and putting in unit tests (I repeat myself) to allow improvements to infrastructural code including a hand-rolled ORM (not by me)
• Giving several talks; including a talk at the HUG Super Forum on the new Widgets Platform and a talk to developers on Git
• Building tools to provision SQL Server instances on AWS and to set up those instances according to the Brent Ozar SQL Server Setup Checklist
• And even more mistakes and fixing of those mistakes; including two (brief) production outages

I’ve enjoyed my time in the .NET world; but I’m anxious to get back into other technologies, and to immerse myself in the JavaScript world. Time to leave the kiddie pool.

As to what I’m doing next? I’ll give two hints:

• See the title
• My career progression has been: Large Corporate -> Defense Contracting -> Medium Sized Business -> Small business that just left startup mode -> ?