gabriel guzman

Read this first

Nest Protect


After calling Nest support, they replaced my unit for me, no charge. The new unit arrived and has been sitting in it’s place, behaving properly for a week now. We’ll see how long it lasts. Fingers crossed.

After about six months of faithful service, the Nest Protect ended up with all the other less intelligent smoke detectors: On the table with the batteries out.

Let me back up. About six months ago, I purchased a Nest Protect. I like gadgets, and a smart smoke detector seemed like a pretty cool gadget. Setup was a breeze, and before long it was mounted to the ceiling in my hallway. Aside from one incident involving over cooked bacon, I proceeded to forget the thing was even there.

About a week ago, I was at work, doing what I do (writing code and breaking things) when suddenly my phone beeped and a pleasant notification told me there was smoke in my apartment

Continue reading →

arcanist - lint, unit test, and submit for code review

I briefly mentioned arcanist in a previous article. It is a command line tool that wraps around git, hg, and svn and provides some handy features for working on a shared codebase. It is meant to be used in conjunction with phabricator, and all my examples assume that situation. As I mentioned previously, a typical workflow while using arc might look something like this:

  1. Create a local branch git checkout -b mygreatfeature
  2. hack on that branch
  3. Run arc lint to run your changes through several possible code linters
  4. Run arc unit to run the unit tests that are associated with your changes
  5. Run arc diff to submit your patch for review

(Note: just running arc diff will call both the lint and the unit test steps if you have them configured)

arc lint

I have arc configured to run php codesniffer to enforce a common coding standard, a text linter to warn about line-length

Continue reading →

Code review before commit

I’ve started implementing code review before commit/push on my team. We theoretically had a code review system in place before this, but it went something like this:

  1. Write code
  2. Commit code
  3. Push code
  4. Roll a d20
  5. If die came up greater than 2, no one will review your code.
  6. Otherwise, someone tries to retroactively review a billion commits in 30 minutes.

That process wasn’t really the best didn’t work. In my experience, once the code is in the tree, there is a near zero chance that it will be reviewed.

Code review before commit (or push depending on your vcs) is a much simpler way to do things, and it helps promote best practices and communication on your team.

By reviewing the code before someone commits it to the tree, you can spot potential problems early, and teach your team to keep their commits small enough to easily review. It’s much easier to glance at a small diff

Continue reading →

OpenBSD and the Intel NUC

Update - A reader pointed out that the intel i5-4250U Processor only has 2 cores and not 4. I’ve changed the article to reflect that. It has 4 threads and so the OS sees 4 processors, but in fact it only has 2 cores. Thanks to Jeff for pointing that out.

While shopping around for a small form factor PC, I came across the Intel NUC. It was the machine our IT department had decided to use to drive all the 50" TV’s that they had put up all over the office. I was initially drawn to its tiny size, and neat look. It’s a very clean looking box.

Although the NUC is a tiny computer, it’s packed with power. The model I purchased has a 1.3GHz i5 with two cores. I added 16GB’s of RAM (the maximum) and a 250GB mSATA SSD. The NUC comes standard with gigabit Ethernet and four USB 3.0 ports. There is also a mini PCI Express slot for adding wifi, if wanted. Since the NUC was going to be

Continue reading →

more continuous integration

So, in a previous post, Continuous Integration I gave a quick overview of our continuous integration setup, and mentioned that I’d like to explore allowing jenkins to push our deploys for us. That work is now done. The basic workflow is now:

  1. Developer develops new feature
  2. Developer runs unit tests locally
  3. Developer submits patch for code review via Phabricator
  4. Code is approved by another person on the team
  5. Developer lands (pushes to master) changes
  6. Jenkins initiates a build, and if all tests pass, promotes the build automatically to the integration server.
  7. Developer, after integration testing, may promote an integration build to staging
  8. Developer, after staging testing, may promote a staging build to production

The two promotion steps are handled with a single click (yay one click deploy), that’s one more point for us on the Joel Test. And can be executed by any developer on the

Continue reading →

backup to twitter?

Ridiculous? Yes.

Pointless? Arguably, Yes.

Possible? Yes.

While catching up on some tweets last night, I came across this:

Which, naturally made me wonder if you could actually use twitter as a backup service. Never mind that no one in their right mind would ever want to do this, I had to see if I could. My first thought was, encode, split, post? My first action was

$ man -k encode

Oh, neat, uuencode(1) will let me encode binary data to text. If you work in the web world, like I do, you might think of php’s base64_encode() function. uuencode(1) does the same thing, but on the command line. Basically it takes binary data and converts it to printable ASCII data. This happens to be exactly what twitter accepts, so it seemed a perfect match.

So, what am I going to

Continue reading →

Continuous Integration

I finally got around to setting up Jenkins for some continuous integration on one of the projects I contribute to at work. It’s been a long time coming and we’ve been talking about it for awhile. Finally getting it done ended up taking longer than expected. No surprise there, with the constant pressure to deliver and release, we often forget that quality and quality assurance are an important aspect of shipping. If you deliver something that’s broken, then you’re not really delivering at all.

The main thing we wanted to get from Jenkins was the ability to fire off our unit tests in an integration environment on each git push. We managed to do this with a server side git hook, which curls Jenkins after each successful push to the git repository. What I didn’t realize at the time was that Jenkins can do so much more than just run your unit tests for you. After playing with it

Continue reading →