Keep Your React Components Dumb

by Zach Briggs

React is amazing at ensuring that the system you build is reasonable, in other words, changes you make tend to not break unrelated functionality. Thinking back to my days writing Backbone or Angular when any change seemed to be capable of breaking distant features, this reasonable aspect of React’s component tree feels miraculous.

The downside of React’s component tree is that UI change tends to be more expensive than the big ball of mud approaches from the days of yore. Since React UI components ARE the code, a UX change to your system might cause you to restructure your component boundaries. Suddenly a small sounding change can result in 300-400 line diffs across 10 components.

I’ve started to put as much state as possible inside of my Redux store in order to combat the fragile nature of isolated component trees and so far, I’m happy. The dumb component approach makes for slightly more up-front typing, but it allows you to make sweeping changes to your component tree structure much more easily.

I’m still in early days of this Redux first mindset, but so far I’m happy with it. I’ll post back here after using it for a few months.

Use The Asset Pipeline Until It Hurts

by Zach Briggs

The Asset Pipeline has shortcomings and if you use it long enough on a JavaScript or Sass heavy Rails app then you're going to feel that pain. Let us count the ways.

  • The Asset Pipeline lives outside of the npm build tool ecosystem where the most cutting edge tools live. Developers working on Rails apps have no hot module reloading, no css code elimination, and no ES module loading by default.
  • The Asset Pipeline doesn't concatenate files in development, which means each JavaScript file you add makes the page reload time a little bit longer.
  • The Asset Pipeline is very slow when building assets for deploy. I've seen 3 minute builds and I've heard of 10 minute builds.

Why the hell would anybody use it, then? Before you rip it out and replace it with something else on day one of your project, check out this list of features that you'll be responsible for recreating.

  • Your servers, I mean your cloud, is going to need to have node and npm installed.
  • Use Heroku? You'll need a build pack. Use Capistrano? You'll need a custom command or a plugin. Don't forget to cache the node_modules folder, otherwise your node based asset build is going to take just as long as the pig-slow Asset Pipeline one.
  • The per deploy cache busting and smart handling of old asset paths so that email assets don't break. You didn't forget about email assets did you?
  • Once you get your cache busting working you'll need a replacement Rails asset path helper which is used in both Rails views and (s)css files. Good luck finding npm based tools that have good awareness of how Rails views work.
  • File watching with rebuilds. Ideally one that doesn't break whenever you add a new file, I'm looking at you gulp watch.
  • If you're working with really good frontend folk then you'll need Sass.
  • Installing well known CSS frameworks like Bootstrap are a snap with the Asset Pipeline so get ready to set aside time to figure that out. (And if you're not using Bootstrap then you probably don't need the css code elimination and your builds probably aren't that slow, so why are you trying to get rid of the Asset Pipeline?)
  • Planning on using Browserify or Webpack? Great. Don't forget to budget time to figure out how to get your jQuery plugins to work. One such plugin ships with Rails and allows jQuery's $.ajax to work with Rails's CORS protection. Disabling that protection is pretty fucking irresponsible.
  • Don't forget to setup the build for your tests too. Unit tests and integration.

Once you get all of that implemented then you'll have lightning fast builds with the newest tools at your disposal! Here are a couple other things to consider, though.

  • Many Rails gems assume that you have The Asset Pipeline, so if you're using any of those, the best you can hope for is using BOTH The Asset Pipeline and your new build. You'll still get access to the cutting edge npm build tools, but your deploy and development page reload speeds may still be slow.
  • Running rails s won't cut it anymore, you'll need another process running in development.
  • Wiring together frontend tooling is its own skillset. You'll need to budget time to transfer that knowledge to other developers.
  • On the off chance any of that tooling that you wired together had any bugs, you may have trouble finding the answers on Stack Overflow. Your teammates will be using you as their build support. Contrast this to the crap we deal with in The Asset Pipeline. WE. The answers are almost always one Google search away.
  • The cutting edge changes quickly. If you replaced the Asset Pipeline last year then you probably did so with gulp which means that you would need to setup your tooling from scratch this year if you wanted to take advantage of Webpack's hot module reloading. Who knows what the darling build tool of choice will be next year.

I sympathize with the desire to start new Rails projects without facing the inevitable failures of The Asset Pipeline. I really do. However if you begin your project by re-implementing it then you might be putting your project at risk, and a failed project has no asset compilation problems at all.

There are very good reasons to replace the Asset Pipeline but there are even better reasons to live with it for as long as you possibly can.

Introducing The Automatic View Library

by Zach Briggs

Simple things should be easy and hard things should be possible when we’re building web apps. I work in Ruby on Rails which is great at database backed, server rendered apps. What Rails doesn’t help with is dynamic user interfaces, that is web pages that update themselves via JavaScript.

If your Rails project has a UI that isn’t well served by a widget library, such as a jQuery plugin, then you should consider including an automatic view library. This is a term that I needed to invent, and I apologize for that. However, we didn’t have a combination of words that covered the need to create novel and engaging user experiences!

An automatic view library

  • Renders arbitrary trees of DOM nodes
  • Updates the DOM nodes based on user actions and changes to data
  • Loops - able to render a collection
  • If - Conditionally renders
  • Provides a means of abstraction, usually through nested components

If you ever have to worry about an element's inner html, you're not using an automatic view library. If you have to manually re-render a template after data changes, that's not an automatic view library.

Not Automatic View Libraries

  • Handlebars - This is a template library which requires that you manually re-render when data changes.
  • Backbone.js - This isn't even a view library, much less an automatic view library; its render function is a no-op by default.
  • Select2 - Doesn't allow arbitrary DOM trees which makes this a widget library
  • jQuery - Does not automatically update DOM nodes for the user.

Automatic view libraries

Single page app focused frameworks that contain an automatic view library

Automatic view libraries are interesting to me because they allow us to embed islands of interactivity into an otherwise server rendered page. We can compose arbitrary and novel dynamic user experiences without committing to the overhead of a single page app.

Check out The Spice House’s new website. Our team at Table XI constructed it using views that are 90% Rails and 10% Vue, and I am very proud of the work we did.

Angular 2 in Plain JavaScript

by Zach Briggs

Angular sure seemed like a good idea...that is, until Angular 2 was announced. Overhauled syntax, confusing upgrade news, and all the official examples written in TypeScript by default; did we make a huge mistake? I don't know but maybe we can find out together. This session illustrates Angular 2 being used with plain JavaScript. Attendees will leave the session having seen specific examples of Angular 2 being used for routing, network requests, form validation, and basic data binding. More importantly, attendees will leave the session with enough information to make up their own minds about the future of the Angular framework.


Natural Talent Is A Myth

by Zach Briggs

The following is a document supporting my talk: "You're Not Special"

I assert the following: "There is no such thing as natural talent."

A provocative statement, but not specific enough to be proved or disproved. Allow me to be slightly more specific and state my understanding of what the current evidence has shown us.

Given the process of learning a complex skill well enough to become a world class expert

  • Differences in our starting points look like rounding errors.
  • When we are able to factor out the variations in the quality of practice, which is rare, our rate of learning seems to be roughly equivalent.

I am basing this assertion on the following literature:

I would be delighted to be shown that I either interpreted these papers incorrectly or that they've since been debunked.

My speculation, not evidence based:

I suspect that there are fields where "almost identical" and "rounding errors" make a big enough difference to count. I suspect competition based fields like elite athletics fall into this category.

Writing Code Without A Brain

by Zach Briggs

There are times when our body is present but our brain is not.  Writing code when we're not fully engaged can be challenging but it's possible. I might be checked out if I have an especially bad insomnia streak; it becomes much more difficult to concentrate.when I hit my 3rd or 4th day in a row without sleeping much.  The following Bulleted List Of Unsolicited Advice™ contains the insomnia coping strategies that have worked for me.

  • Turn off the obvious distractions. I'm looking at you, Twitter. 
  • Keep the blood sugar level. Being tired sucks, but being tired and hungry is lethal. 
  • Be honest with anybody who's depending on you. Let them know that you're not operating at peak performance and let them know why if you can.
  • Pair. Pair on problems, pair on planning, and pair program. Don't swim alone, kids.  See the above point and let your partner know what state you're in and that you'll be leaning on them.
  • Zoom Out.  The worse off my brain is, the worse I am at making good tactical decisions. When I'm tired, I assume that my code micromanagement abilities are wrong and that my partner is always right. On the flip side, I seem to be better at keeping big picture focus when I stop trying to drive the code directly. In short, if your partner needs to drive the code then you may need to be project manager for a day.
  • Go home. If nothing is literally on fire and your brain just isn't functioning then just go home and get some rest if you can.

I've been lucky enough not to suffer from sleep issues in the past few weeks. Here's hoping that neither you nor I need this list anytime soon.



by Zach Briggs

Edit: October 18th 2019
Dozens of women have reached out to me in the 6 years since I’ve written this post, all with experiences like this. All of them were sexually assaulted in a public place at a tech conference. Tech conferences are dangerous places for women. My only piece of advice is to avoid
Joe O'Brien.

This isn't a post that I want to write. It's a story from my perspective and it's limited by my memory of a night where I witnessed a sexual assault, in a public place, at a tech conference.

The purpose of this post isn't anger and it's not closure. I'm writing this because right now our only recording of the sexual assault is a tweet that the victim since deleted. She deleted it, I’m assuming, because of the tide of tweets blaming her or doubting the fact that she was assaulted.

It's all too easy to close our eyes and wish the assult didn't happen. I know, because that's how I've been spending the last few months. It's so much easier for me, as a able-bodied, CIS gendered, hetero white dude, to pretend that this doesn't happen and tune out. The purpose of the post is to make her experience harder to ignore.

Because this shit happened

Trigger warnings for assault, I think I'm supposed to say.

January at a resort bar for a conference. I had been a member of the Columbus Ruby community for a few months and a professional Ruby developer for slightly less time. It was the first night of my first tech conference and I was standing there talking with another developer from Columbus.

It was slightly before midnight at the resort bar while the other developer and I were talking with a rotating set of people in one end of the space. Being new I knew almost nobody there; it was later and most of the crowd had already headed home.

Looking over, the other developer pointed out a thing. It could end up being an embarrassing story or the last image before a train wreck. I knew of the man, head of operations for North America of a company that ran the largest Ruby shop in Columbus. The woman was at least 15 years younger, at least 100 pounds lighter, and at least 2 tiers lower than him on the corporate hierarchy at the same company.

We went back to whatever conversation, naively not even considering the possibility of a train wreck. What I remember as 5 minutes later the other developer looked over and said something like "oh shit." I looked over and saw a train wreck, now in progress. The executive's posture and actions aggressive; "no" was not a possibility. She was visibly upset and shut down. That's an understatement. I saw somebody trapped in a nightmare, in public. That freeze frame is burned into my brain. 

The other developer was also at least 2 tiers lower than the executive in the same corporate structure.  I think we both expected the universe to right itself.  A few seconds later, when it became apparent that this was not going to stop on its own, the other developer put a stop to it. 

I don't know what would have happened if that other dev, now a dear friend, hadn't been there to step in. How much longer would her nightmare have continued? Would I have noticed? Would I have let myself notice? Would I have walked over and asked if everything was OK?

I don't know the answers to those questions and I hate myself for that. Never again, though. I will never be the bystander who "didn't want to get involved." The pre-trainwreck body language that I could lie to myself about before is now crystal clear. That sense that something's wrong. I will walk over and say something self deprecating to give whatever future woman a chance to disentangle herself. No matter how powerful he might be in a very small community, no matter how little I know about the people or the situation. 

I'll have to because I cannot live with feeling this way again.

JavaScript Learning Resources

by Zach Briggs


(added 9/27/2013) JavaScript The Good Parts Book and Video :
I like Eloquent JavaScript and Secrets of the JavaScript Ninja, but they are both twice as long as they need to be. The Good Parts is a little dated, I don't agree with all of the opinions, but I've still not seen a better book for people coming to JavaScript from another language. 

Effective JavaScript Book and Podcast
This is the reference guide. The manual that should sit by your desk at all times just in case you need it. I'm sitting here typing right now and fighting down an anxiety attack because my copy is packed away in preparation for our move and NOT by my desk. It's comprised of 68 small tips that will make your code delightful to behold.

Small Plates:

  • Scope
    There are many rules to the way scoping works in JavaScript. The two that you should never forget are that omitting var will create an accidental global variable and that the only way to create a new scope is inside of a function.
  • This
    Understand very deeply that when you see this in JavaScript that you have no idea what it's referencing, just like you have no idea what an argument is referencing until a value is passed in upon invocation. That's because unlike self in other languages, this IS an argument.
  • Prototypal Inheritance
    Prototypical Inheritance is less important than you may think considering that JavaScript is often identified by this single feature. Understand it so that JS's method dispatch makes sense and then try to avoid deep object graphs. Cat really doesn't need to be an instance of Animal. Seriously.
  • IIFE's and closures
    Nailing the IIFE (pronounced "iffy") and the closure it creates is probably the most important step to creating reusable JavaScript components. 
  • Style Guide 
    Be mindful of the code's style. This one isn't the single source of truth, but it's as good as any to get started with.
  • Modules
    No matter what anybody tells you, do not use a library like require.js as a beginner. If you're advanced enough to understand the tradeoffs, then by all means.
  • Testing
    Yes, testing in JavaScript is just as important as any other language. 

Ruby Rogues Listening Guide

by Zach Briggs

Update:  I'm adding more episodes to the end as people suggest them.

The Ruby Rogues Podcast is awesome, but not all episodes can be equally awesome. These are the ones that have really stuck with me so they're the ones I recommend to friends.

For the rubyists:

For the programmers: 

For the humans: 

Reader suggestions:


The Next Language You Should Learn

by Zach Briggs

The Pragmatic Programmer recommends learning a new language each year as a way to prevent our skills from atrophying. I couldn't agree more, and I know exactly which language you should learn next.

Whatever the heck it is that you're writing every day. 

Learn that one because I suspect it might just come in handy. Study the little nuances of the workhorse data structures so you never need to read their docs. Be able to split a string, round a number, and forward a method. All from memory.

 Learn your server side framework of choice as an extension of this.  Display text on a webpage, text that came from the database, text that was put into a database via a form submit. From memory, with minimal code generation. Maybe slide your Haskel book aside for an hour and work on this instead.

Oh, and if you must learn a new language right away I have a suggestion for that too.  

Please for the love of God learn JavaScript.
— Julie Pagano

Her slides are here

What To Eat When Eating In Columbus

by Zach Briggs

I often get asked where to eat lunch or where to take guests who are visiting Columbus. This is what I came up with off the top of my head given a 1 hour constraint.

If you have the time then go on a food tour with Columbus Food Adventures.   The tours are a collection of the best places serving the food they are the most proud of.  When you're getting your hand held by obsessive foodies then you are getting the best dining experience in Columbus,

Skillet is my favorite Columbus restaurant. Locally sourced simple fare cooked with skill. The local sourcing isn't just a badge to put on a menu; they find food that's either not available to the bulk restaurant suppliers or of such high quality that it's not worth comparing. Today I had duck egg carbonara where the egg's yolk was so yellow that sunglasses were required. They're known for weekend brunch but their lunches and dinners during the week seem to be a well kept secret.

Bono Pizza is still the best pizza place in Columbus.  They cook pizza in a wood fired oven that's hot enough to leave a slight char on the top of the crust while the rest is cooked to perfection. No A/C and occasional long lines so don't be afraid to order ahead.

 Kitchen Little is where I see more restaurant owners eat than anywhere else I go.

If you allow a guest to leave Columbus without experiencing Jeni's Ice Cream then you are a bad person.

I don't make it to Basi Italia here as often as I would like but they're brilliant every time I do.

 Explorer's Club has gone from great but inconsistent to nailing it every time I walk in the door. I would average 3 lunches and 2 brunches a month here and they were great every time.

I recommend the Columbus Food League restaurants without reservation. Betty's, Surly Girl, Tip Top, Dirty Frank's, Jury Room, and Grass Skirt Tiki Room

For the Scotch fans, visit Wings in Bexley.  

But you don't have to take my word for it. 

Grit vs Hustle

by Zach Briggs

We need both of them, you know. Grit gets the attention; it's sited as one of the most common attributes of wildly successful individuals. Far beyond intelligence, the willingness to stick with a task long past the point of boredom or doubt. The ability to stay focused despite the nay-sayers telling them that it cannot be done. The capacity to string hours and hours together for a self appointed apprenticeship with no pay knowing that success would be mere years away.

What gets less attention is the hustle. That sense of urgency that's only ever felt by somebody fighting a clock. This isn't panicked rushing which only leads to frustration, but obsessive streamlining. The willingness to avoid escapist activities like TV knowing that those hours each week takes away from a pursuit of mastery. The ability to practice right now instead of waiting for the perfect time with just the right wind speed and pollen count.

I recently was faced with the fact that I'm pretty good at the grit and generally awful at the hustle. I'll stick with a task long-term, but I'll find other activities that must be done first or can never quite find the right time to practice consistently. 


My new philosophy is that the time to work on getting better at development is right now. When I figure out what my stupid bug was on a side project  10:00PM after spending 2 hours stuck on it, that leaves another 2 hours of possible work before sleep. 20 minutes of downtime while dinner marinates? Review some submissions on 5 minutes in line at the pharmacy? Review my index cards of stuff I had to look up yesterday.

TIme for me to stop crawling the path and walk it instead.


Selfish Teaching

by Zach Briggs

I find that teaching others is a highly effective way to get better. However, this only works when I'm putting full effort into the task and using feedback to optimize.

If I give instructions to a novice, I should probably use simplified rules and half truths at first.  Giving the nuanced rules to that novice may frustrate them. May put enough of a roadblock in their path to stifle growth. I need to watch the student to see if the answer was complete enough to be useful but not so detailed as to confuse them. Based on that feedback with this student, hopefully I'll limit the damage that I deal to the next one.

However, if I only understand the simple heuristic then I will never advance. To give a simple but effective answer for a complicated question, the teacher MUST understand the nuance. Must assume that they got it wrong and verify those nuanced points with an authority.  

Developers Are Cattle

by Zach Briggs

Dairy cattle, specifically. And that's a very good thing for developers. 

Any drive through rural United States will display a variety of agriculture relics. Skeletons such as a rotting barn, some rusting field equipment, or a lone silo standing sentinel over the ghost of a long abandoned farm. These are monuments to the passing of time, to an age before industry allowed the consolidation of dozens of family farms into large corporations. The family farm has been rendered almost extinct by such efficiencies with a single notable exception. The dairy farm.

The dairy cow doesn't really scale well. Their ability to produce milk will be greatly reduced by the stress caused by over-crowding and other forms of mistreatment. Milk production relies on an active reproduction system in the animal and is crippled by those stressors in all the ways that meat production isn't.  If you attempted to treat your average Holstein the same way Perdue treats its chickens then you're going to get a cow that gives half the milk and lives a quarter as long. See, that cow longevity is of great importance; short of a time machine it takes 2 full years to make a new lactating cow. If you don't treat your cows at least as well as you treat the family pet then that investment is squandered. 

Large dairy farms can and do exist but so do the very small ones. The very large ones have figured out how to treat their animals decently and the small ones survive by staying lean. The same does not hold true for corn, pork, beef, soybeans, or just about any other type of commodity farmer that I can think of. Those farms may be family owned, but they probably a corporation in their own right with a fleet of equipment and many employees. There are delightful exceptions amongst farmers that find their own market and exploit that niche, but that doesn't further my point so lets ignore them.

Right, developers. And a point.

One of my favorite books that I've never read, The Passionate Programmer, is truly excellent and I cannot recommend it highly enough. It's easy to forget though that it's the second edition of My Job Went To India And All I Got Was This Lousy Book. Somewhere between 2005 and 2009 we developers seemed to have lost this anxiety over every last development job being moved overseas. Do you remember how everything was going to be outsourced and all the code was going to be written in India? That never happened. Well, it might have happened to the Purdues of IT like IBM, but it never happened to the rest of our industry. It turns out that the types of conditions that almost work for call centers and industrial chicken farming make for just awful software. 

See, writing effective code is a frigging strange process that is like no other human endeavor. I've heard comparisons to engineering and science and art and a trade. And I say they're all way off the mark. They're just as accurate as comparing the model of an atom to the solar system or comparing a developer to a 1,500 pound lactating bovine. The real answer is that development is none of the above; it requires the empathy of a social worker, the precision of an architect, and the creative flair of a different architect who has creative flairs. Or an artist. They have creative flairs too. Its hard, harder to do well. Developers are actually creatives. Our process isn't turning a crank or pressing a button but requires leaps of intuition and lateral thought. That process breaks down if the developers are under stress or if they are not in a position to empathize with the product owners. It breaks down if we're over-crowded; large teams are notoriously inefficient compared to the small ones.

Developers, like dairy cattle, don't scale.  

We don't scale in this fundamental way that may be the first time seen in human history. And because of the difficulty of the vocation and the rarified conditions required to produce good software, there is a major shortage of us. The demand is outpacing the supply to such degrees that the biggest complaint I hear amongst our peers is all the recruiter spam. You know, how to deal with all those people offering to pay us money.

 Never before have we had this much power over where we work and how. Employers are in abject terror over one or two people leaving at the wrong time and touching off a brain drain. No longer are we crammed into cube farms and buying books about flat worlds featuring outsourcing. 6 digit salaried positions stay open for months because applying for the job involves uploading a Word document and wearing khakis. We developers have serious power and it's not going to go away in our lifetime. 

Unlike the dairy cow we have the choice to do something with our relative privilege. How then shall we expend it? Shall we amass more power? Or maybe we could show the chickens


Rails 4 Heroku asset:precompile

by Zach Briggs

When faced with this error when pushing a Rails 4 app to Heroku:

-----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
       rake aborted!
       could not connect to server: Connection refused
       Is the server running on host "" and accepting
       TCP/IP connections on port 5432?

Start with this guide for the basic setup. If you're still seeing that error, give this a shot:

$ heroku labs:enable user-env-compile

The gist is that the Heroku env variables are not set when your app begins to precompile the assets. Rails 4 is supposed to not load the full app during asset compilation, but sometimes it does anyway. Since those Heroku environment variables aren't set yet, like the location of the database or the Redis server, the app fails. That heroku labs command above makes the environment variables available early enough to prevent this specific brand of failure. 

Here is an alternative solution.

Falling In Love With Being Wrong

by Zach Briggs

I aspire to being wrong.

I prefer to state my wrong uttering as questions or suggestions. These types of wrongnesses (I hope) cause people to think. They drive the team to write better software because they needed to consider my flavor of wrong before shooting it down. Maybe my incorrect statements interact and co-mingle with their almost-correct ideas and produce better ones. Maybe they even adopt my wrong ideas wholesale and we're all surprised together at me being slightly less wrong than expected.

This isn't irony or reverse psychology but my best ideas held with the conviction that I'm wrong. But I must consistently share my wrong ideas freely and without shame. Keeping the ideas to myself will ensure that I walk meekly into a life of mediocrity. 

Sometimes I still slip up and assert loudly that I am right and my rightness should be listened to and that, by extension, others are wrong. This is awful for me and everybody else because it means that either

  • I'm right and I'm an asshole, or
  • I'm full of crap and I'm an asshole. 

In both cases I'm not learning anything and the project becomes worst because other people feel bulldozed and disengaged. They'll shut down a very little bit as they loose a little bit of autonomy and become every so slightly less invested, if not entirely disconnected.

But approaching a technical discussion from the stance that I'm wrong empowers other people. It increases others' investment in the success of the project as they watch their own ideas take flight instead of just being tasked to implement my own.

What if the other idea is truly disastrous and my own is the only one that can save us from ruination? This is a hallucination of mine that reoccurs every once-in-a-while. I must simply remind myself that everybody else working on the project is as smart as me and as invested in success just as much as myself. If that isn't the case then me throwing my weight around and being right very loudly is going to make the situation for-reals worst.

If the project environment is safe for short term failure with non-judgmental, quick feedback then I will have an opportunity to reintroduce my own wrong idea later where it can be re-evaluated and perhaps adopted after all. By taking the stance that I'm wrong and defaulting to the other decision, either

  • I was actually wrong and I learn something, or
  • I was actually right and somebody else learns something

So please accept my apologies as I'm still right every once-in-a-while. I'm only human. 


Change A File's Content In Every Git Branch

by Zach Briggs

Challenge: remove the second line from a given file across all local git branches. Bonus points for spending longer trying to figure out how to do it with a single command than just making 18 changes.

git filter-branch --tree-filter 'touch game_test.rb && sed -i.bak 2d game_test.rb && rm game_test.rb.bak'


  • We can run a command against every branch of a repo with
git filter-branch --tree-filter command 
  • Typically we see a find and replace pattern with sed such as 
sed s/find-me/replace-me/g  file >> another-file
  • Much to my delight we can just remove lines wholesale with the d flag. 
  • sed 2d file outputs the contents of file to standard out with the 2nd line deleted.
sed 2d file >> another-file 
  • Sed's -i flag allows us to operate on a file in place
sed -i pattern file
  • We need to create a backup file for OSX otherwise we get an error: 
sed -i.bak pattern file
  • Putting that together, we can delete the second line of a file without opening it with 
sed -i.bak 2d file
  • The && operator allows us to run two commands on the same line:
command && command
  • Since OSX forces us to create an unwanted backup file when we use the -i flag with sed, we'll need to remove it right after running sed. Let's do it in the same line: 
sed -i.bak 2d file && rm file.bak 
  • Not all of the branches have our target file which will make sed fail. Let's create the file first as a hack.  
touch file &&  sed -i.bak 2d file && rm file.bak
  • Now lets run a destructive command against every local branch!
git filter-branch --tree-filter 'sed -i.bak 2d file && rm file.bak'


Take Risks To Live Longer

by Zach Briggs

On August 22, 2012 I became a professional programmer. I spent the 7 years before that as a Direct Mail Analyst doing repetitive, familiar, nonthreatening work in Lancaster, OH. I lost those 7 years in the blink of an eye.

The last 10 months, though. The last 10 joyous months feel like they've lasted 10 years. 

I started thinking about that perception of time when introduced to the Time Hack Project.  Matt Danzico spent a year trying new experiences to fool his brain into thinking that he was living longer. The reasoning is that we perceive time moving more slowly when trying something new and experience time moving more quickly when engaged in familiar tasks.

Interesting, but I think that we can take a look at this from a different angle. What if we use that perception of time as an alarm? "In Case of Lost Time Break Glass" When May goes by in the blink of an eye, that's a warning flag. When a year disappears on us, that's a klaxon. That's our brain shutting the hell down because we're not throwing anything challenging its way. There is no need for us to pay attention when there are only safe, boring tasks for it to work on.

Maybe when years start to evaporate wholesale then that's a sign that we should start making a change. If I had that insight 7 years ago then maybe I could have avoided sleeping through the better part of my 20's.
It's too late for that chapter of my life, but I'm sure as hell awake now.


by Zach Briggs

Please stop the shame bullshit. 

I have an especially low level of tolerance for loud developers that cause quieter developers to feel bad for not writing code in a specific way. Making people feel crappy doesn't improve their code, it just makes them feel crappy while they write ineffective code.

Shame corrodes the very part of us that believes we are capable of change.

That quote is from this piece on a public shaming ad campaign in NYC. Never mind the crushing, dehumanizing aspects of using shame to change the behavior of others as there is another aspect that's far more damning.

 It doesn't work.

It seems to me that as programmers we should be reviewing data on the efficacy of our technique and adapting appropriately. This applies to unit tests or using shaming language to convince others to unit test in a presentation, a book, or at work. The data is in on both of them. Unit tests work when written first and shaming others does not.