MacBook Air 13" -- lockup in iTunes, fixed?

My new MacBook Air 13" froze twice last week. (full lockup, requiring reboot), both times as I was launching a fresh install of iTunes. There is an update out this morning to fix that, w00t. Those lock-ups were my only complaint about my new Air. Let's hope this fixes it.

"This update addresses an issue that makes the system unresponsive when using iTunes. It is recommended for all 13" MacBook Air (Late 2010) users running Mac OS X v10.6.7."
-- Mac OS X 10.6.7 Supplemental Update for 13" MacBook Air

In other news, yes, I bought a MacBook Air 13" last Friday. My previous Mac purchase was an 68000 MacSE running 8.6, purchased 20 years ago. Fully pimped out, this was a big impulse buy on Ebay (after a week of watching ebay and craigslist, it still felt like a impulse to start and finish bidding last friday morning). It did run my 3x as much $$ as the Acer (4x retail). What will I do with two tiny laptops?

It is both bigger and smaller than my lovely Acer 1810T. The 13" Air has a hugely larger footprint to the acer, at 13 vs 11. The whole body is slightly lighter and much thinner. Having gotten used to the size of the 11", this feels really big. How do people carry around 17" monsters? The screen is larger and has more pixels at 1400x900 vs 1366x768, albeit at a lower DPI of 130 vs 135 dots per diagonal inch. It also has more pixels than the 13" macbook pro, why are they still using a lower res screen on those?

The 13" Air has a larger battery spec and seems to have considerably larger real-world battery usage. The battery lasts a full workday, though I get nervous when it says an hour or two left. Wake from sleep is wicked fast, and sleep seems to be a very low power situation. I put my acer to hibernate and it takes about 20 seconds to boot with the SSD -- ~8 of that is just the bios time to get to the bootloader. I haven't been able to compare wake from hibernate on the Air since I can't force hibernation -- it happens automatically if it is in sleep mode "long enough."

I'm still trying to get used to the change in keyboards -- the wrist rest area is ginormous on the Air. The large wrist area makes it sit in my lap differently than the Acer, and typing is more awkward. It does rest more softly in the lap -- similar weight over a larger surface area.

I found myself trawling ebay looking for an 11" as a companion to this one. The 11" air is a very close alternative to the 1810T. If you can live without a second mouse button and page-up/page-down dedicated buttons. The larger trackpad really is nicer than the Acer, though I was quite used to that smaller trackpad. The 11" has roughly the same specs, a slightly faster chip, similar quoted battery life, same footprint, much thinner and a tad lighter. Counting the big SSD I put into the 1810T the prices are comparable.

Note, if you are looking to buy an Air, know that the RAM is hard soldered at the factory, so there is a large difference between the 2G and 4G versions. Do the resellers (bestbuy, frys, buy.com etc) even get 4G models to sell? It is possible to replace the SSD, it is non-standard but they are available. The ram you won't get to change.

Startup Toolkit.

I'd like to see a project of a "startup kit," a collection of opensource tools that are known to work well-enough together: revision control + code review + continuous integration + issue tracking + deployment&configuration.

I don't need perfect, but I would like good-enough.

I suppose this is close to what Atlassian provides, but that's a little too much corporate proprietary synergistic kool-aid for me. Maybe I'm judging too harshly after the Rubicon Atlassian experience, which was soured more by the lack of system and sysadmin resources to upgrade/install/approve the tools than by the tools themselves.

Some options I'm considering now:

• Issue Tracking
  • Trac
  • bugzilla
  • redmine
  • github issue tracker
• Source control
  • git, shared via github private account
• Continuous Integration
  • hudson/jenkins
  • buildbot
  • cruise-control / cruise-control-rb
• Code Review
  • mondrian (hosted by google appengine)
• Configuration management and bootstrapping onto ec2
  • chef (pretty far down the chef road at this point)
  • puppet
  • cfengine
• Monigoring (using all of these for different aspects:
  • nagios
  • ylastic
  • aws console
• statistics and graphs
  • ganglia
• log aggregation
  • splunk -- hadn't considered this, but was suggested by friends at GumGum, to monitor logs across a cloud of app-servers

This should be enough to get a scalable environment for developing, testing and deploying an application. After that, it's time to pick the additional infrastructure pieces needed by the application (data persistance, caching, logging, ... )

TODO(andrew): add links for the projects.

using git-flow with github

We've decided to use nvie's "Git Branching Model" for a work project using github as a "central" repository (by convention). The gitflow documentation is aimed at people running their own local repositories and using the default git-flow settings for branch names.

I want to make some branch naming changes from the original model. First I was going to swap develop and master with master and production. I've gone a step further and done away with master. I want my branches to be develop, qa, and production.

First, how to initialize this in a new repo:

% mkdir fakerepo
% cd fakerepo
% git init fakerepo
Initialized empty Git repository in /Users/andrew/src/fakerepo/.git/

% git flow init
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master] production
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] qa
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 

% git branch
* develop
  production

#git flow saves elements to the local repo configuration, .git/config
% git config -l | grep gitflow
gitflow.branch.master=production
gitflow.branch.develop=develop
gitflow.prefix.feature=feature/
gitflow.prefix.release=qa
gitflow.prefix.hotfix=hotfix/
gitflow.prefix.support=support/
gitflow.prefix.versiontag=

Now, how to push to the matching github repository, spazm/fakerepo? Normally I'd use:

 git remote add origin git@github.com:spazm/fakerepo.git
 git push -u origin master

But now I don't have a local master. Should I be using the publish features? #Add manually, rather than via git flow * publish

%  git remote add origin git@github.com:spazm/fakerepo.git

% git push --set-upstream origin develop
Counting objects: 2, done.
Writing objects: 100% (2/2), 173 bytes, done.
Total 2 (delta 0), reused 0 (delta 0)
To git@github.com:/spazm/fakerepo.git
 * [new branch]      develop -> develop
Branch develop set up to track remote branch develop from origin.

% git push --set-upstream origin production
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:/spazm/fakerepo.git
 * [new branch]      production -> production
Branch production set up to track remote branch production from origin.

% git branch
* develop
  production

% git branch -r
  origin/develop
  origin/production

Now, what does the next user need to do after he clones the remote repo?

% git clone git@github.com:spazm/fakerepo.git
% cd fakerepo
% git status
# On branch develop
nothing to commit (working directory clean)

% git branch
* develop

% git branch -r 
  origin/HEAD -> origin/develop
  origin/develop
  origin/production

% git config -l | grep gitflow

#blank, the gitflow configuration items aren't present in the checkout.
% git flow init

Which branch should be used for bringing forth production releases?
   - develop
Branch name for production releases: [] production
Local branch 'production' does not exist.

#manually bring over tracking branches
% git branch --track production origin/production
Branch production set up to track remote branch production from origin.

% git flow init
Which branch should be used for bringing forth production releases?
   - develop
   - production
Branch name for production releases: [production] 

Which branch should be used for integration of the "next release"?
   - develop
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] qa
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 

% git config -l |grep gitflow
gitflow.branch.master=production
gitflow.branch.develop=develop
gitflow.prefix.feature=feature/
gitflow.prefix.release=qa
gitflow.prefix.hotfix=hotfix/
gitflow.prefix.support=support/
gitflow.prefix.versiontag=

Question: Do I really have to manually set up the tracking branches when I clone, prior to running git-init? That seems messy. I'll keep digging and let you know.

[Undisclosed Startup], my new gig

I started working for [Undisclosed Startup] in December, after leaving leaving The Rubicon Project in September.

These four months have flown by.

I'm having a blast getting back into Startup mode. Rubicon is doing great but has grown to hundreds of engineers. [Undisclosed Startup] has a single digit number of employees and ~4 engineers. At some point we'll de-stealth and show the world ... awesomeness.

I'm definitely getting to "wear a lot of hats," ranging from code reviews to company goal planning. I'm now much more familiar with amazon ec2. I've lead the push to switch to git (so far, so awesome) and an SVN layout cleanup. I'm doing a bunch of sysadmin-ish tasks (oh how I loathe the term dev-ops, yet here we are) -- dear opscode/Chef, your documentation is all over the place, but the product is neat. Leveraging my dearly earned hadoop knowledge from Rubicon. Maintaining and extending the perl web ui. Picking up python. testing testing testing! Maybe I'll even use my low-level-manager hat?!

Apologies in advance for my dearth of future entries: startup-land takes a lot of time and energy. I do hope I at least write about some of the multitude of research topics I'm digging into.

patching github projects

Wow, adding changes to projects on github is surprisingly easy, once you figure out the steps. I made a patch for vim-space earlier today, after I found an error in a comment that cost me an hour yesterday.

I nearly got the github flow correct on the first pass. Here's what I did:

1. fork the project (via UI on github)
2. clone locally
   git clone git@github.com/spazm/vim-space.git
3. make change to plugin.vim in my working directory, test:
   vim plugin.vim ...
4. create an issue for the original project (via UI on github)
5. commit change locally:
git add plugin.vim
git commit plugin.vim -m "[issue 7] ..."
6. push change to my cloned repo on github:
   git push origin master
7. create the patch file:
   git format-patch HEAD^..HEAD
8. upload the patch file to the issue. Nope, can't upload files to the issue tracker at github.
9. create pull request:
   git request-pull HEAD^ origin HEAD

   The following changes since commit 9640d4d1ee980e352abd96e2c0ef13372d1c14cd:
   
     Merge remote branch 'remotes/origin/master' (2010-04-13 16:22:27 +0200)
   
   are available in the git repository at:
     git@github.com:spazm/vim-space.git master
   
   Andrew Grangaard (1):
         [issue 8] correct loaded_space to space_loaded in plugin
   
    plugin/space.vim |    4 ++--
    1 files changed, 2 insertions(+), 2 deletions(-)

10. Copy and paste this pull request into issue 7.

This was close to the correct flow. While the issue tracker on github doesn't allow uploaded files in the comments, it does track pull requests. So the flow should look like:

Correct Flow

1. Clone Repo (github UI)
2. clone locally:
   git clone git@github.com/spazm/space-vim
3. Make Changes, test
   vim plugin.vim ...
4. commit locally:
git add plugin.vim
git commit -m "loaded_space fix"
5. push to github:
   git push origin master
6. issue pull request(github UI)
7. done. bask in the warm glow of improving an open source project.

The issue pull request stage will create a tracking issue. Slickness. The Clone and Pull Request are handled in the github UI. Check the Pull Requests as Github UI documentation for pretty pictures.

Proper form would be to create a topic branch in the cloned repository, this becomes more useful if you plan to make any further changes or modifications to the project. Make the upstream girl's job as easy as possible to enhance the likelihood of your changes being accepted.

[LA.pm] March Los Angeles Perl Mongers

LA.pm.org will be back at Rent.com this month. Thanks for hosting again!

What:   Los Angeles Perl Mongers Meeting
When:   7-9pm
Date:   Wednesday, March 23, 2011
Where:  Rent.com - 2425 Olympic Blvd Suite 400 E, Santa Monica, CA 90404
Theme:  Perl!
RSVP:   Responses always appreciated.

As always, I'm looking for presenters. What are you doing in the greater perl infrastructure?

Looking forward to seeing my fellow mongers in 11 days.

RSVP at facebook

Vroom - vim overrides and mapping for presentation remote

The second best thing about using Vroom (Formerly Vroom::Vroom ) for presentations is hearing, "I've never seen a presentation in vim before." The best thing is using vim as both the editing and display platform.

I realized yesterday while cramming to finish my "intro to git" presentation for work that my recently added vim plugin "magic space" (space.vim) interferes with the default Vroom vimrc bindings. Space.vim rebinds space in a variety of ways to repeat the previous movement commands (search, movement, etc).

Disabling the plugin took a couple of iterations because the documentation was incorrect -- it references loaded_space while the code was checking space_loaded. Actually, the documentation was correct, but the comments in the plugin code are incorrect. I opened a ticket, cloned the github repo, pushed the changes, and updated the ticket with a pull request via git request-pull. Not bad for 5 minutes.

This encouraged me to expand my Vroom knowledge. First, I found the syntax for adding a vimrc override to my presentation. Today, I created a user specific vroom vimrc override in $HOME/.vroom/vimrc to disable magic space when I'm running Vroom presentations.

Since I was already adding custom configuration, I dug out my nerdnite presentation remote and found that the buttons are mapped to PageUp, PageDown and b. These are what powerpoint use for previous page, next page and blank screen. They aren't particularly useful while presenting in vim, so I remapped them in the vroom override to previous and next file.

You think people are shocked by a presentation in vim? Wait until you pull out your laser pointer remote to advance the slides. priceless.

My Intro to Git vroom presentation

https://github.com/spazm/presentations/tree/master/open42-git-intro

Vroom vimrc override file:

https://github.com/spazm/config/blob/master/vroom/vimrc

vim-space

https://github.com/spiiph/vim-space

my fork with fix for issue 8

Issue 8

"" Custom .vimrc overrides for Vroom
"" These will be automatically added to all 
"" vroom autogenerated .vimrc files

" disable space.vim during Vroom presentations.
" in my version of space.vim the docs refer to
" g:loaded_space, but the code checks g:space_loaded
let g:space_loaded = 1

" My presentation remote has three buttons
" forward: sends PageDown
" back:    sends PageUp
" blank:   sends b
" Bind PageUp to previous doc and PageDown to next doc
map  :N:gg
map  :n:gg
" map b ???