It’s no secret to those that know me that I’ve been really getting into cooking lately. And, no surprise to anyone that knows me, I get obsessed with things really easily. I’ve been sharing photos of what I cook on Instagram, but I thought I would start sharing the recipes of what I make, especially given I’ve been making up some of them. Others, like this one, are mostly inspired by things I’ve seen online. I’ll do my best to share those sources as to not take credit.

And, different than is my personality, I’m not going to be very precise in these recipes. No exact measurements! I’ve not got into baking, so I’m mostly doing things freestyle when it comes to amounts.

I’m going to start with one of my favorite recipes, Lemon Herb Chicken breasts.

The Inspiration

I probably have seen various versions of this online, but the one that most directly inspired this is No Recipe Required’s Rosemary Lemon Chicken, which I first saw in this video:

Below is my version of what I’ve done many times based on Dave’s recipe.

The ingredients

The Marinade:

  • olive oil
  • salt
  • pepper
  • dried rosemary
  • dried thyme
  • zest of 1 or 2 lemons
  • 2 cloves garlic, minced

The dish itself:

  • olive oil
  • salt
  • pepper
  • 3 to 4 chicken breasts or tenders
  • juice of 2 or 3 lemons
  • butter
  • dried rosemary
  • dried thyme



I’ve been buying what I think are labeled “chicken tenders” from the store, which are thin cuts of boneless and skinless chicken breast which cook up easily. If you don’t have those, or want larger portions, I suggest butterflying your breasts and then putting them between plastic wrap and using either a meat mallet or rolling pin to make the breasts an even thickness and thinner so they are easy to cook. Cut away any fatty parts before marinating as well.

Always remember to wash your hands after working with raw chicken!


The easiest way to marinate is to take a large zip top plastic bag and put the raw chicken in it. Combine the ingredients in a bowl, with enough olive oil to cover the chicken. Pour the mixture over the chicken into the bag. Get the air out of the bag, close up tight, and then make sure the chicken is thoroughly coated. Let sit in the refrigerator at least an hour, but even better 4-6 hours.


I cook these in a stainless steel frying pan, but I imagine a no-stick pan would also work well. Put the stove on medium to medium-high, and after the pan is warmed, put a couple tablespoons of olive oil in the pan and make sure the pan is coated. Use kitchen tongs to get each piece of chicken out of the plastic bag and lay it in the pan, laying it away from you to avoid splatter. If you are cooking more than a few pieces, you may have to do the chicken in batches, just note that you might have to put a bit more olive oil in your pan for each batch.

With the thin chicken tenders I use, it really only takes about 3 to 4 minutes per side to cook the chicken through. I usually only flip the chicken once. No sense in messing with it!

After I put the chicken in, and after I flip it, I season it with a bit of salt and pepper. Other than that, I leave it alone. After it has cooked on both sides, I take the chicken out and put it on a plate.

The sauce:

Drain most of the excess oil from the pan. I then add a little bit more of the dried herbs into the pan and give them about 30 seconds to toast. Then, carefully pour the lemon juice into the pan – careful, it might steam up right away and be hot! You may want to add a tablespoon or two of water to dilute it slightly. Use a spoon to deglaze the bottom of the pan. Add a little more salt and pepper to the mixture. After it has reduced a bit, I add the chicken back to the pan to really let it soak up the flavors from the sauce. I usually put a lid on the pan and let it reduce until it’s about half of what it was before. I finish it off by putting a little bit of butter in the pan. After the butter is melted, check the seasoning, it may need a bit more salt to cut the acidity of the lemon.


Place the chicken on your plates. Pour a bit of the pan sauce over top of the chicken. If you want to be fancy, put a slice of lemon on top for a garnish.

Enjoy! This has grown to be one of my favorite quick and easy recipes!

I’ve created a screencast demonstrating making a pull request for open source projects, specifically, Spacemacs. The principles explained here apply to any Git and Github based project. In this screencast, I demonstrate fixing an issue I reported with how bookmarks were being handled in the Spacemacs home buffer:

How to do it

Fork the Repository

Create the fork by visiting the project page on Github. In the case of Spacemacs, it’s at On that page, click the Fork button on the upper right side of the page. If you happen to belong to organizations on Github (which I do, as seen in the video), you will be prompted to select where to fork the repository. Select your user.

This will create a new repository for your user that is a mirror of the current state of the upstream repository.

Note the repository clone URL that is shown on the right-hand side of the page, part way down. This is needed when you add your repository as a remote to your local checkout.

Update your local repository

Next, you need to make sure your local checkout of the Spacemacs repository is up to date. As specified in the Spacemacs Contributor Guidelines, contributions are best done off of the develop branch.

  1. Go to magit-status for the Spacemacs repository by doing SPC u SPC g s (Hit the spacebar, then u, then the spacebar again, then g, then s). Then enter the path of the Spacemacs repository, ~/.emacs.d, and hit RETURN.

  2. Switch to the develop branch, if you are not already there. Hit b b and type develop. One thing I did not cover in the video is the case if you haven’t already checked out the develop branch previously, instead of b b (or, branch checkout), you need to do b B (or, create and checkout). It will prompt you for the branch to base it off of, select or type origin/develop, hit RETURN and then name the branch develop. Note that any time in the magit-status buffer, if you want to know what commands are available, just hit ?.

  3. After you have the develop branch checked out, update it against the remote upstream repository. Hit F for Pulling. Then type -r to rebase. Even though we don’t yet have any local commits, it makes sense to rebase any unpushed commits on the remote branch so that they are up to date and can be merged without merge commits. Hit F to pull and rebase. After this is done, we want to restart Emacs to run any of the latest changes. Hit SPC q q to quit Emacs. Relaunch Emacs.

Adding your remote

We now need to add our newly-forked remote repository as a remote in our Spacemacs repository. There are several strategies that can be taken here. One option is to wipe your ~/.emacs.d directory and clone your fork, making it origin. You would then add the upstream, original repository as a new remote (perhaps named upstream) that you could pull from. But since I am more often than not going to be running and updating code from the upstream repository, I will leave the upstream as origin, and add my fork as mine.

  1. Go to the magit-status buffer again: SPC u SPC g s ~/.emacs.d RET.

  2. Hit M (or, Remoting) and then a (or, Add).

  3. When prompted, give the remote a name. I called it mine.

  4. When prompted for the remote URL, put the URL that you copied from the Clone URL on your project page. For example, mine was

Creating a branch for your changes

Before any changes are made, we need to make a branch to put them in. You could just commit to the develop branch, push your changes to your fork, and then do a pull request off of that. But since I often have multiple pull requests open at one time, I find it simpler to do a branch per pull request. This also allows my branches to have meaningful names.

  1. From the magit-status buffer, hit b B (or, create and checkout branch).

  2. magit will then prompt you for the branch you are branching off of. Choose develop.

  3. Next, it will prompt you for a branch name. I like long descriptive names, so I chose fix/spacemacs-home-buffer-bookmarks-jump.

Check out the Git book chapter on branching for an in-depth discussion of branching.

Make, commit, and push changes

Now that we have a branch we can make our changes. In the video, I used a previously created Git stash to quickly apply changes to my repository. I simply applied it by hitting z p (or, Stash pop). Go ahead and make the changes you want. After you have tested and are satisfied with them, you are ready to commit and push.

  1. Go to the magit-status buffer again: SPC u SPC g s ~/.emacs.d RET.

  2. Stage any unstaged changes you have made. Quickly: hit s on each line under Unstaged changes corresponding to a file you’ve changed.

  3. Hit c c to commit all staged changes.

  4. Type a meaningful commit message. (See this post for a great explanation of what a good commit message is.) Helpfully, the diff of what you have changed is shown on the right-hand side for you to see what you did. Make the first line be a short subject describing the commit. Add a blank line and then in lines wrapped at 78, write a brief description of the changes and why. If you are fixing an issue that has been filed, include something along the lines of ‘Fixes #2431’. Hit C-c C-c (that’s Control and c together, and then again).

  5. Hit P (or, Pushing). Then, -u to set the upstream so subsequent pushes, if needed, default to this remote. Then P (or, Push current). Start typing the name of your remote (in my case, mine), and it will finish the branch name for you – mine/fix/spacemacs-home-buffer-bookmarks-jump. Hit RETURN.

Make the pull request

You are now ready to submit your pull request. Switch back to your browser to the page for your fork.

  1. Github will show your recently pushed branches near the top, in a yellow box. Refresh your page if you don’t see this. Click the green “Compare & pull request” button.

  2. In the next screen, Github will prompt you for a branch to compare against. By default it will show base: master. We want to select develop here. As shown in the video, it may take a minute for the page to update after you have selected the develop branch.

  3. If you’ve done everything right, it will be able to cleanly merge your commit and will indicate so. It will then pull from your commit message the subject and description. If you’ve written a good commit message, there should be no need to add anything here. Click Create pull request.

Congratulations! There you go, you have created your first pull request. Hopefully the project developers will like your pull request and merge it.

Happy Hacking!

My friend Diego Berrocal and I would like to announce the release of nix-emacs v0.0.1.

nix-emacs adds support for searching and completing options in Nix OS configuration files. Nix OS is configured using the Nix expression language. This includes configuration from your hostname to options for various services you may enable. The online documentation lists the abundant options available. There is also a handy interface for searching the options.

But, we found it less than ideal to have to constantly switch back and forth between the browser and our editor while editing our configurations.

Included is support for:

  • A helm source for searching the options and viewing documentation


  • A company backend for completion of option names in nix-mode files.


Check out the README for instructions on how to use nix-emacs.

We’ve submitted pull requests to get this included in MELPA so you can easily install it. Also, we’ve submitted a pull request to Spacemacs, the Emacs configuration we both use, to add a Nix layer, with everything configured out of the box.

This is just an initial release. Hopefully more refinements to come. Feel free to follow along on Github. Submit any issues you may have or submit pull requests.

We also have a Gitter channel, if you want to chat with us. We hope to make it a place to discuss all things Emacs, Spacemacs, and Nix, so please join us.

Updated on 2015-07-21 to add Gitter link.

After an extended break in my career due to chronic illness, I am looking to return to part-time work. Because of my location and inability to drive, this will have to be a remote position.

I am available starting tentatively the second week of September. My goal is to work 15-20 hours a week.

I am experienced in both software development and system administration. Professionally, I’ve primarily done work in Python and Java, and in packaging for and managing Debian and Ubuntu machines. Lately, my interests have led me to use NixOS and to pursue learning Haskell and other functional programming languages. Ideally, I’d love to work with the two of those.

I’ve been busy recently dipping my toes in various technologies and helping with open source projects, including Nix OS, Spacemacs, and the Lowbrow browser. I’ve been doing remote pairing with friends. I’ve been helping out on IRC and bug trackers for the projects that I use.

My primary skill is learning new technologies and learning the best ways to leverage tools.

Please reach out to me if you think I could help you out. Check out my resume for further details on my experience and skills.

I created a quick screencast the other day. It was an introduction to Spacemacs, a starter kit or configuration for Emacs, that is self-proclaimed as an “Emacs advanced Kit focused on Evil: The best editor is neither Emacs nor Vim, it’s Emacs and Vim!”. In this screencast, I cover installation, showing installation in an Ubuntu 15.04 virtual machine.

All that is required is Gnu Emacs 24 and git.

Feel free to check out my Spacemacs configuration. Reach out on Twitter if you have any questions.

I hope to make some more of these soon, about Spacemacs and perhaps other topics.