Someone put together gallery of all of Apple’s Think Different ads.
I wrote a blog post over at Eng5 outlining how we use TomDoc and GitHub pages for documentation at Site5. Check it out!
I stumbled across this video for the Tomy Racing Turbo. I totally remember using this when I was 4 or 5 years old.
I read an interesting article today about the show Mastercrafts. Mastering a craft like blacksmithing or stone masonry seems a lot like mastering computer programming, but much less forgiving. Definitely worth a read.
The new Designed by Apple commercial is absolutely brilliant.
This is it.
This is what matters.
The experience of a product.
How it makes someone feel.
When you start by imagining
What that might be like,
You step back.
Who will this help?
Will it make life better?
Does this deserve to exist?
If you are busy making everything,
How can you perfect anything?
We don’t believe in coincidence.
Or dumb luck.
There are a thousand “no’s”
For every “yes.”
We spend a lot of time
On a few great things.
Until every idea we touch
Enhances each life it touches.
We’re engineers and artists.
Craftsmen and inventors.
We sign our work.
You may rarely look at it.
But you’ll always feel it.
This is our signature.
And it means everything.
Designed by Apple in California
I came across this document a few months ago. It is an inside look at Gears, the game engine used to develop Final Fantasy VII.
I played this game before I ever thought I’d be a programmer. Now that I am a programmer, it’s great to see what made one of my favorite childhood games tick.
Now, I simply run
:Dispatch[!] rspec [ARGS]. Errors open in a Quickfix
window, and you can jump directly to the failing spec.
If I am working on a particularly tricky example group, I use
example, to focus on a
context starting on line 25 of the current file:
:Focus rspec %:25. Now, I can run
:Dispatch without arguments to run just
that example group.
I’ve really enjoyed how vim-dispatch has changed my workflow.
Hacking for Site5 Engineering is an awesome gig. I work with an amazing team of highly opinionated developers from a wide background. In early 2012, we adopted a semi-formal process for working on software. We’ve been very happy with how this has worked out, so I thought it was time to share.
Step 1: Discuss the change
Code written for Site5 projects usually falls under one of four categories:
- new features
- bug fixes
- code refactoring
- library upgrades
Before someone starts coding, they will typically discuss the changes they intend to make or the bug to be fixed. Developers use GitHub issues for most communications on a project.
Sometimes this discussion happens in real-time using our company chat room or Teamspeak. GitHub issues also make it easy to report bugs or request features to be discussed at a later date.
We tried Basecamp for these discussions, but found it was a bit difficult for developers to change context. We did find, however, that it was a great tool to discuss features with non-developers.
Wherever possible, we try to stick to one topic at a time and keep changes as small as possible. For example, features are added one at a time, bugs are fixed one at a time. We’ve found this makes it much easier for other developers to review code changes.
Step 2: Create a new git topic branch
Once a developer is sure of what they are working on, the next step is to create a new topic branch in git. We try to namespace these using one of the following:
This just makes it easier to determine what a branch is for using just its name.
Step 3: Write the code and commit changes
At this point, it is time to start coding. We are pretty much free to code things as we see fit, unless specifics were mentioned in the original discussion.
We’re strong proponents of BDD, so if a project has a test suite (and most of them do), we try to follow that process while working.
Where it makes sense, we will usually make one commit describing the changes that are being made.
If we need to test things on a staging environment, this is where it happens.
Step 4: Open a new Pull Request and solicit feedback
Once code has been committed, it is time to open a new pull request and solicit feedback from the rest of the team.
Other developers review the code to ensure that there are no issues with it, or to offer ideas for refactories. If there are any changes to be made, the original author will then make them. The new changes will be discussed for any further feedback, and the process continues.
At least one reviewer must informally sign off on a Pull Request in order for
it to be merged. This is usually just an emoji
Step 5: Rebase if needed
We try to avoid cluttering a project’s git history with a lot of extra
commits. If there are additional changes added from feedback in Step 4, we
git rebase -i master to squash them down into one commit. Of
course, this is only done where it makes sense – two commits are better than
one if they better describe the intended changes.
Step 6: Verify CI build and merge Pull Request
If the project has a test suite, we wait for our CI server (either Jenkins or Travis CI) to verify the build succeeds. After that, any reviewer can merge the Pull Request. As a rule, we don’t merge our own Pull Requests.
Step 7: Tie up loose ends
After a Pull Request is merged, we may need to tie up some loose ends such as deploying an updated Rails app, or replying to customers or staff to inform them a bug was fixed. This obviously depends on the situation, but it is an important step nonetheless.
Step 8: Beer (or Red Bull)
After all that work, it is time to enjoy a beer or a tasty Red Bull!
Today, I learned about a bunch of escape sequences that SSH supports.
||terminate connection (and any multiplexed sessions)|
||send a BREAK to the remote system|
||open a command line|
||Request rekey (SSH protocol 2 only)|
||list forwarded connections|
||background ssh (when waiting for connections to terminate)|
||send the escape character by typing it twice|
For example, you can suspend the SSH process itself to return to your local
shell by typing
~ + ctrl + z). I’ve been using SSH for years,
but had no idea these existed.
Just over a year ago, I left for Railsconf and made one of the best decisions of my life: I was going to use the week in Austin to force myself to quit smoking.
At the time, I had been smoking cigarettes for about 9 years. I had never actually tried to quit smoking, although, I always told myself I would eventually. I thought that being in a non-smoking environment for a week would be the perfect time to try.
I knew going in that it would be a challenge, and that I would need some help. I immediately ruled out Chantix – I had some friends try it who turned into crazy assholes on it. I briefly considered using an electronic cigarette, like Bluecig, but decided against it. I didn’t want to replace one form of smoking with another. I ended up choosing the nicotine patch for the entire 10 weeks they recommend.
The patch was an interesting experience. In the beginning, I felt like I needed to apply a fresh patch each morning. For the first few days, applying the new patch definitely had a sensation like smoking a cigarette did. I came to enjoy the tingly sensation it gave my arm after I applied it. Every few weeks you switch to a smaller patch, so by the end of the 10 weeks, I barely noticed it’s effects.
Most people say that the first week without smoking is the hardest. For me, my first week was easy because I was constantly in a non-smoking environment at Railsconf. My second week without smoking, my first week back to work after Railsconf, was definitely the most difficult for me. The moment I got back from Austin, I wanted to drive straight to the store to buy a pack. I managed to avoid doing that when I realized what an accomplishment it was to have gone 7 full days without smoking – something I hadn’t done in years.
That second week was really, really hard. I found myself being easily frustrated by problems with code I was working on. I almost convinced myself that my performance was slipping to the point where I needed to start smoking again. Thankfully, that wasn’t really the case, and I talked myself out of it. I also found myself getting a little impatient with people, but I was able to acknowledge and control this. I never allowed myself to pissed off at anyone and use the excuse of “well I’m trying to quit smoking!”
During these first few weeks, anything and everything reminded me of the “joy” of smoking. TV shows with characters that smoked seemed to cause particularly strong cravings, surprisingly, stronger than those caused by being in the company of other smokers lighting up. I had unknowingly trained myself to expect a cigarette after meals, after completing tasks, to help with frustration, during a ride in the car, right when I woke up. At first it was difficult to relearn how to do these things without a cigarette, but as each week passed, it became easier.
About 5 weeks in, I started to notice a change: I was going hours at a time without even thinking about cigarettes. I still had cravings, but they happening less frequently. I finally got those improved senses of taste and smell everyone always mentions when they quit smoking. Saving $10.25 per pack, per day, my wallet definitely noticed a change, too!
When the 10th week approached, the last week I was to use the patch, I remember wondering how I could ever survive without them. At first, I felt I really need the patch again, but that went away after about a week.
After this milestone, it was more or less smooth sailing. I still get cravings here and there, but they are easy to say “no” to and go away very fast. I’ve had a few dreams where I buy a pack and smoke again, and I end up feeling guilty in the dream and wake myself up.
After a few more months, winter hit, and I laughed as I saw people freezing outside in the snow to smoke. When spring hit, I laughed again as I saw people freezing outside in the rain to smoke. I don’t miss that at all!
Each month became another milestone, until almost a year had passed. At that point, I knew I was done for good. Today, I’m happy to say, marks one year since my last cigarette!