An Austin Ruby on Rails Hacker's blog about software & technology

Main menu

Post navigation

You’ve been there … you’ve done some work, then staged or committed it in git and forgotten about it for a bit. Only to hop into the terminal another day thinking you’re on master and wondering why your git pull is doing a merge.

Having neither the time, or patience since you’re running low on coffee and you want to look at that Pull request locally, you’ve run

I accidentally ran git reset --hard on my repo today too while having uncommitted changes too today. To get it back, I ran git fsck --lost-found, which wrote all unreferenced blobs to <path to repo>/.git/lost-found/. Since the files were uncommitted, I found them in the other directory within the <path to repo>/.git/lost-found/. From there, I can see the uncommitted files, copy out the blobs, and rename them.

Note: This only works if you added the files you want to save to the index (using git add .). If the files weren’t in the index, they are lost.

In the case (like mine) where you committed the changes previously, you will find hashes in .git/lost-found/commit that refer to the commits that you lost. You can view what is in them by running

`git show 98b9e853c9c8ffc07b450c61b05313cc4aa9eceb` (for example)

Usually it will just show the diff of the commit which you can re-apply manually line by line, other times you’ll see something like this

on the line that says “Merge”. You can run a git show on one or both those hashes as they point to the parent commits of the one you’re looking at.
You can keep doing that till you get the commit you were looking for. whew!

On OSX this actually updates the plist file that launches puma-dev directly. which brings me to the next point …

Restarting puma-dev manually

On OSX. The puma-dev plist file used by launchd to run puma-dev on startup, seems to be located at /Users/<your username>/Library/LaunchAgents/io.puma.dev.plist

The reason why this is important is that in the puma-dev readme, it says to restart puma-dev by running.

pkill -USR1 puma-dev

However. Lets say, you’ve misconfigured your plist file (like I managed to do), launchd will keep trying to run puma-dev and failing all the while spitting out an error that looks like this in your puma log files every ten seconds

Error listening: accept tcp 0.0.0.0:0: accept: invalid argument

The dead giveaway is entries like this in your system log files located at /private/var/log/system.log

io.puma.dev[1616]): Service exited with abnormal code: 1
Service only ran for 0 seconds. Pushing respawn out by 10 seconds

Running on a different port

If you have Apache running on port 80 and don’t pass in the right command when installing then puma-dev will fail to launch, and keep failing as described above.

This means you have to run `puma-dev install` with the http-port flag, for example

puma-dev -install -http-port 81

I like this, not for the reason you’d think, but because it allows me access my apps on https://<appname>.dev, while still accessing my php apps with apache on port 80!

Something to note though is that you have to run this command everytime you run `puma-dev install`, or else it will overwrite your settings in your plist file and cause you hours of grief as you try to figure out how you broke all the things amidsts rending of hair and gnashing of teeth

To illustrate … say you have your port set to 81 and you run the command we discussed first

puma-dev -install -timeout 180m

This will reset your port to 80 quietly, and puma-dev will start failing as I described previously. so to avoid that you want to run

puma-dev -install -timeout 180m -http-port 81

instead.

This behavior is subtle enough to cause problems for someone who may have installed puma-dev a while ago and forgotten where everything is and how it all works, so I filed a bug report about it.

A few months ago the creator of my favorite rails server (puma) announced a version of puma called puma-dev. This new server bears more than a passing resemblance to pow, because of its goal of making local rails development stupendously easy.

I was a big fan of pow when it first came out but I eventually stopped using it when it as development on it slowly crawled to a halt then eventually stopped. Having come to Rails development from a PHP background, where the server was always available,

I didn’t like having to type `puma` or `rails s` to start working on a local application, or …

having to remember and assign different port numbers if I was working on more than one app at a time. So I was definitely excited about having puma-dev pick up where pow left off.

it also made playing around with subdomains easier

So I was definitely looking forward to having it pick up from where I left off with pow

Setup is super easy. First make sure to include puma in your Gemfile

gem 'puma'

Then run `puma` at the command line and make sure your app starts up with no problems.
Next install puma-dev

I’ve been using this setup for a few months now, and I must say, I find this immensely useful because I have an apache server running on port 80 for my PHP work, so I can actually access a domain on https://mydomain.dev. It also supports websockets!

Things to note

puma-dev will spin down the server after a few minutes of inactivity, so don’t be surprised if your app takes a few seconds to startup after you’ve been gone for a while

To restart the server (in case you’re working on something that doesn’t auto load or isn’t loading correctly) just run `touch tmp/restart.txt` from rails root

Dushka Zapata’s answer: I once hired a woman who did brilliant work but was not a good team player. It’s not that she was destructive or hostile. It was more that, in an industry that typically thrives on collaboration, she was an independent contributor. Another employee was always late. I fel…

the key insight being

People who deliver brilliant work are hard to come by.
It’s our job as managers to make our business environment flexible enough to give every brilliant employee a place to thrive.

I absolutely loved this!

All too often, I find that managers (especially middle managers) are concerned with bringing employees “in line” and getting them to conform to the system, instead of figuring out how to help them do their best work. I imagine following the approach outlined in the article is much easier said than done though.

PS: I bet it would make a very interesting interview question for a management position.

A couple of years ago I worked at a “startup”. I put startup in quotes because it was really a big company pretending to be a small one. Ideas generally flowed from the top down; engineers wound up on the crap end of everything, usually getting overruled and dictated to by PMs and the UX team. Naturally, a lot of the engineers were disillusioned and frustrated with the way things were working.

It was in the middle of this rather cynical time that we got a new PM on the team. He was tasked with improving our onboarding flow and upping conversion numbers, and I was the engineer assigned to work with him on this project.

He had a lot of ideas about how to go about accomplishing this task, and surprisingly, he had actually dug around in the database and pulled some numbers that backed up the direction he was going in (before he came along, very little of what we did was based on data … another source of frustration).

However, on the list of things he wanted to try was something that raised my eyebrow.

“Hey … Pete” (not his real name by the way)
“Hey!”
“Am I reading this right? You want us to leave off the subdomain field on signup?”
“Yes”
“So how will we assign subdomains to the client to access and login to their app?”
“We can just randomly generate a unique string and use that, I think”
“hmmm”

To provide some context, this was 2013, and the subdomain-login-access pattern where a customer was actually a group of people who needed separate logins to access a particular space within an app, had become a mainstay of web apps all over the techie world. The pattern, popularized by 37 Signals and Basecamp almost 8 years earlier, was simply one of those things that everyone just did.

Being the brilliant undiscovered product genius I thought I was at the time, I knew taking away subdomains from the signup form, would be an unqualified disaster. Users would freak out when they signed up and were redirected to random5tring35.app.com to login. They would panic when they couldn’t remember what url to go to login, they would bombard us with emails, and the complaints would force us to roll back this silly change.

I smirked to myself and got to work on getting this and other changes pushed out on the appointed date. After getting everything built out and QA’ed in staging, we rolled out the change and waited …

I’ll spare you the suspense … nobody complained about the subdomains

I was completely blown away. I simply could not understand it … I mean, subdomains were so crucial to the users, how could they not miss that on the sign up?!?!?

Turns out that subdomains are actually confusing for a lot of users, and us taking that off their plate simplified the sign up process. Users mostly didn’t care what the url looked like, and the ones that did, could request a specific one in the settings. (A few years later, 37 Signals would remove subdomains in the newest versions of their apps, citing the exact rationale that we discovered back then)

I learned 2 things that day
– Humble pie is actually pretty delicious, people should eat it more
– You know nothing Jon Snow. (Seriously. You don’t)

Lots of us walk around spouting truisms without any data to support what we’re talking about, and nobody challenges us, so we keep doing the things we’re doing. In reality, if we poke a couple of these “assumptions” we might find that a lot of them come tumbling down like a Jenga tower.

So, whenever you find yourself not wanting to try something because “everyone knows thats how its done”, take a breath then go ahead and test that assumption.

One of the most common pieces of advice you’ll get as a startup is this: Only hire the best. The quality of the people that work at your company will be one of the biggest factors in your success – or failure.

Perhaps worst of all, if the interview process is predicated on zero doubt, total confidence … maybe this candidate doesn’t feel right because they don’t look like you, dress like you, think like you, speak like you, or come from a similar background as you? Are you accidentally maximizing for hidden bias?

Stack fallacy has caused many companies to attempt to capture new markets and fail spectacularly. When you see a database company thinking apps are easy, or a VM company thinking big data is easy? – they are suffering from stack fallacy. Stack fallacy is the mistaken belief that it is trivial to build the layer above yours.

There are two ways to fail and the consequences are orders of magnitude apart. Convincing failures allow us to make better decisions in the future. We tend to agonize over the risk of executing something poorly but the much bigger risk is building the wrong thing to begin with.

“… if you execute to a level of quality that makes it unlikely that another team, even with more time and effort, could succeed, then yours is a convincing failure. This kind of failure is strategically valuable because we can now eliminate an entire development path from consideration. That means subsequent work is dramatically more likely to succeed. A convincing success is unquestionably the goal of every effort, but a convincing failure should be a close second.”

For me the lesson that lies inside of that nugget doesn’t just apply to Engineering teams, it applies to life.

Lots of times, people will try something, but they’ll do it half heartedly. They might open a business, or try to do standup comedy, or try to make a pro team (that was me), but they don’t give it their all … maybe they want to string some wins together so that they can convince their friends and family that this isn’t some flight of fancy, or maybe they’re afraid that they’ll fail, so if they don’t give it everything they’ve got, it won’t hurt as much when things don’t work out. The problem with this approach is that, just like the article says, you’re still left wondering “what if?” when the opportunity finally fades from view. Which in a lot of ways is worse than not trying at all.

I like reading this article because it reminds me that if I try something in my personal life, that I want to either succeed or I fail … hard. No in between.

I’ve worked on high functioning teams, dysfunctional teams, teams of people who absolutely hated each other, teams where everyone loved each other, and I think I’ve zeroed in on one trait that anyone can look for in a team that will tell you how productive and successful they’re going to be.

Before I do this, I’m going to tell a small sports story.

I played at a pretty high level (amateur) when I was younger, and I played with this one guy (lets call him Dick) who was a brilliant player, with a nasty habit of berating players every time they made a mistake. The thing I noticed was that, sometimes players wouldn’t even make a mistake, they’d just do something that he didn’t think they should do, and he’d immediately get on them. Even worse, sometimes he’d make a mistake and blame someone else.

Miscontrolled a ball? “That was a Shit pass!” he’d yell.
Gave the ball away in a bad area of the field? “Why weren’t you covering that guy?!”

If they ignored him, he’d just keep sniping at them or refuse to pass to them in the game/practice. People didn’t really enjoy playing with this guy at all. He was very good though, so you’d just have to suck it up and try to play with the negativity, which is very tough for younger/developing players who were short on confidence sometimes.

There was another player, (lets call him Wayne), who was actually even better than this guy, but it wasn’t apparent because he did a lot of “dirty work”, unglamorous stuff. He rarely did fancy moves, or tried things that made you go “wow” or look around for an ESPN filming crew. But the guy was steady, technically brilliant, rarely made mistakes (which you start to realize is very hard to do at a high level). If you were in trouble, say surrounded by 2 guys and were about to lose the ball, you could knock the ball to his general direction and it didn’t matter how much pressure he was under or how crap the ball you played to him (look up “hospital pass”), he’d pick it up and find a way out. It was amazing.

Want to know the awesome thing about this guy? he never blamed people for anything!
It was actually kind of weird.

If you made a mistake he’d yell
“Don’t worry about it, just recover, go get it back!”,
If you played a bad pass, he’d say
“Go on … go make sure they make the mistake now … win it back!”.
If you missed the shot, even if it was from 2 yards out with an empty goal, he’d say
“Unlucky. You’ll get the next one!”

He was everywhere … always looking for a way to help out. If he was better positioned, he’d tell you where to play the pass. If you were hesitant about what to do, he’d yell out
“hit it” … or “touch that off to Mike” … and if you did something different, he’d wouldn’t skip a beat
“ohhh … even better. love that pass!”
then he’d be off to get open for the next guy.

And it was infectious … because he gave you encouragement, you weren’t afraid to make mistakes, and because nobody else was really as good as this guy, you realized that you really couldn’t get on somebody about how crap they were playing, because at some point in the game you’d probably do something pretty stupid. A side effect of this is that everyone started to play for everyone else, because there was no real thing as a “mistake”, everyone just knew to cover for everyone else, even Dick.

So if your man blew by you, somebody else would step up and mark the loose guy, someone else would take his guy, etc etc, and you could just go find an open guy and mark him. Everybody covered for everyone else … it became part of the game, part of the team DNA … and it was a very good team indeed.

I bet by now you know what that trait is in teams I’ve seen that predicts how well they work together. There is no fear of failure.

If you get some bad code into production, you don’t get thrown under the bus, or get walked into a small room with fluorescent lights to get reamed by your boss, instead people swarm around and try to help you, and you do the same when someone else makes a mistake, or misses a deadline. The culture of blame is non-existent, so people fix problems, not the blame. If a deadline was missed, then the team didn’t make a good estimate NOT that Kathy is a shitty engineer.

This is very important to note, because most corporate environments, for whatever reason, seem to embrace a culture of blame. If something goes wrong, everyone wants to know who’s at fault.

“yeah Mike wrote that code 2 weeks ago, we told him not to push it live, but he did it anyway, this is what happens.” … usually followed by a self righteous sigh.

People point fingers quickly, because a culture of blame stems from a culture of fear. Fear of failure, fear of not living up to “high standards” … fear of not being an “A player”. If someone else is to blame for something, then you can still stay secure in your illusion of awesomeness, or maybe you are really fantastic and all your shitty co-workers are just bringing you down, or maybe nobody will listen to your brilliant ideas, so this is what they get.

Now does this mean that you should constantly cover for and try to baby along players who can’t hack it at the level of everyone else? Absolutely not.

On the soccer team I was on, you had to meet a certain (high) standard to make the squad … if you weren’t good enough you simply wouldn’t make the team … simple.You had to have a particular skill level to play, but once you were in, you were one of us, and we’d work our socks off for you, just like we’d work our socks off for Lionel Messi if he chose to join (look him up, he’s only the best player in the world). Its the same way on the great teams I worked with.

Teams that work well together don’t fear failure, High functioning teams that work well together, have amazingly talented and driven people working together for each other who don’t fear failure. They embrace it.

They can do this because they have great team players, men and women who constantly work for each other, push each other, encourage each other, and pick up the slack when somebody falls down or trips up, without even thinking about it. Great teams are stacked with people who say

“What can I do to help”
instead of
“I’ve done my job”

You know … quintessential team players. The real tell-tale sign of a great team.

Being that person that makes everybody else great, isn’t that hard. It’s all about being like Wayne, performing at your best, being a pro no matter what and adopting an attitude that there is no real mistake, because you’re going to cover for your teammate, and trusting that they’re going to cover for you.

Most people know what it takes to be considered a professional at something, High levels of competence, reliability and exceptionalism … but I want to talk about the last 2% of what it takes to become a consummate professional. It involves how you react to things, specifically shitty situations and people. I’m going to throw out a couple of scenarios to illustrate what I’m talking about

– What do you do when a coworker has just told your boss that your work is awful and you don’t deserve to be at the level that you’re at in the company, and then that coworker comes over to ask for your help with something?

– What do you do when an engineer comes to you (as the lead) with 2 days to launch a big project and tells you the launch date won’t happen because a bug they were trying to fix, quietly (emphasis on quietly, nobody else knew about it) turns out to be much more serious than they thought?

– What do you do when you think a client is clearly stretching out final payment by sending you on wild goose-chases after bugs that aren’t really bugs, or arguing that things you uncovered as issues before the project started are actually your fault; insisting you fix them without charge before you get paid?

– What do you do when your boss takes credit for your work and ideas in the big presentation after weeks of insisting that they would never work, and gets a promotion because of it?

– What do you do when during a friendly debate with a coworker at lunch, they suddenly get personal and heated for no particular reason?

– What do you do when the team lead who shot down your approach for testing and releasing your feature at the last minute, has no problem when someone else attempts the same thing a week later?

– What do you do when you catch your coworker lying about the cause of a bug, trying to throw someone else under the bus for something that was their fault?

– What do you do when a previous company tries to screw you over after you’ve given notice that you’re quitting, examples include messing up your health insurance paperwork, or insisting that you return the company phone even though usually you can pay a fee to keep it upon separation, or badmouthing you through back channels in a small town (workwise)?

– What do you do when you realize a client of your company has a problem with you being gay/black/latino/Middle Eastern/White/a Woman, is trying to get you off their project and your company is refusing to back you up?

– What about if a coworker uses disparaging or condescending language in addressing you on slack or in JIRA tickets?

What I’ve learned over the course of my career is that the times when you need to be at your most professional are the moments when you least feel like it. Responding to underhanded coworkers, dickish bosses, an executive team with no backbone or angry clients when you’re angry and justifiably so, without losing your cool, is one of the hardest things you might ever have to face in your career. Just because you feel justified in responding in kind to a put down or dressing down an underperformer, doesn’t mean that you should. The top professionals I’ve met respond to these kinds of situations by

– Staying completely calm
– Trying to take the emotion out of it
– Trying to resolve the situation without ascribing blame
– Not getting drawn into an emotional exchange
– If the other party is unreasonable or shitty, ending the interaction as quickly as they can or escalating it to someone with more authority (this might mean involving a lawyer if you’re your own boss)
– Avoiding shitty people, but remaining pleasant and polite in all your interactions with them

Taking the high road has the key benefit of getting the crappy situation/person off your mind faster than if you engaged with it. For example, say you respond to a coworker questioning your abilities by getting annoyed and attacking their own abilities. Very quickly the situation escalates into one that requires people to pick sides, or one where everyone is walking on eggshells for several weeks till both of you or one of you is fired or disciplined. Maybe you win, maybe you lose … but what could have been out of your mind after that day, has now turned into a month long ordeal that has lessened everyone’s opinion of you.

High price to pay for “showing them” hunh?

Naturally, this is a very high bar to attain, and in my life, I think I’ve only met 2 people I would consider total pros in this way. My big problem is that its hard for me to remain calm when I’m dealing with people that I think are jerks, its a personal trigger for various reasons, but I think over the last few years I’ve improved very drastically in this area, mainly by coming to the epiphany that just because I may think of someone as a jerk doesn’t necessarily make them one. Like the old saying goes

“If you run into an asshole in the morning, you ran into an asshole.
If you run into assholes all day … you’re the asshole”