Last week I attempted to use the CSS sprites feature of Compass for the second or third time. It's been a struggle each time, but the power and potential is there, so I keep coming back. This time was a bit different, though, because I finally decided to stop relying on the docs and dive into the code.
Before I go into the nitty-gritty, let's take a step back and talk about why I
| task :deploy => ['heroku:push', | |
| 'airbrake:deploy'] | |
| namespace :deploy do | |
| task :migrations => ['heroku:maintenance:on', | |
| 'heroku:db:backup', | |
| 'heroku:push', | |
| 'heroku:db:migrate', | |
| 'heroku:restart', | |
| 'heroku:maintenance:off', |
| ENV = window.ENV || {}; | |
| ENV.VIEW_PRESERVES_CONTEXT = true; |
I clearly remember my first day at EdgeCase, over four years ago. I was new to Ruby, Rails, Vim, Agile, and -- more than anything -- pair programming. It was one of the most painful working days of my career. I was convinced I'd made a terrible decision. I was completely overwhelmed, my confidence was shot, and I dreaded coming in on day two. Of course it got much better. Over time I gained experience and confidence with Ruby, Rails, and Vim. I got comfortable with the continually evolving agile project flow at EdgeCase. Obviously, I fell in love with EdgeCase and the team I was a part of. But I never got used to
| --type-add=ruby=.haml,.rake,.rsel,.builder | |
| --type-add=html=.html.erb,.html.haml | |
| --type-add=js=.js.erb | |
| --type-add=css=.sass,.less,.scss | |
| --type-set=cucumber=.feature | |
| --type-set=coffeescript=.coffee | |
| --ignore-dir=coverage | |
| --ignore-dir=doc | |
| --ignore-dir=log |
A lot can be said about talking face-to-face with someone versus writing back and forth. Voice inflexion, facial expressions, and hand gestures are just a few of the non-verbal cues that can never come across in writing. Actually, let me amend that: they can never have as much precision in writing. Given some lightweight markup, smilies, and pacing, some of this actually can come across in writing, but it's certainly a far cry from what we can communicate in person.
I think I'm ready for a new kind of project planning tool. Tracker has served me well for a couple years, but what I'm finding lately is that it falls short on the most critical component of project planning: the discussion.
Every feature is a discussion. Every bug is a discussion. Every architectural decision is a discussion. Discussions are everything. To paraphrase Joe O'Brien from one of his recent talks, I've never seen a project fail due to technical reasons, it's always communication. But looking at a Tracker project doesn't
You've heard this mantra before, right? Don't bog programmers down in process, just let them get stuff done. Back when I lived in the corporate IT world, we would joke that any problem could be solved with more process. Indeed, at the time it seemed that was management's solution to everything.
But what does this statement even mean? It's started to grate on me because it
A few weeks ago I decided I wanted to hire a personal trainer. The interaction did not go quite how I expected.
Me: So, I'm looking to get buff. I mean big changes. I want to turn heads when I take my shirt off. I've got a trip coming up in three months, so I need to start training as soon as possible.
Trainer: I can definitely help you with that!