Today’s discussion:

Inspired by flickr user nickwheeleroz, and his beer bottle pictures, I went out to the local DIY store today and picked up two pieces of 8×10″ plexiglas. A couple of bucks each. I also got a 12 pack of self-adhesive velcro squares and a roll of black duct tape. Combine that with three sheets of white foam core board, a pair of CLS-enabled speedlights and a Nikon DSLR, and you have everything a budding strobist needs to do product photography. Well, as long as the product is no wider than about 5 inches.

My first set of test shots were with a mini Southern Comfort bottle. Putting a piece of foam core down on the kitchen table, putting a piece of plexi on it, and then putting the bottle on top of the plexi gives you a nice, reflective surface that doesn’t show the table through the shadows. A small kids chair on the table balancing a second piece of foam core creates a white softbox to make sure the plexi is fully reflective. The third and final piece of foam core goes against the wall, to catch the light of an SB-600 fired at ¹⁄₃₂ power @18mm zoom. (A small gobo, attached via an ultrastrap, keeps the light going up and back.) The final bit of lighting is an SB-800 at ¹⁄₁₂₈ power with a dome diffuser camera right, illuminating the label of the bottle. A second gobo is attached to that speed light, to keep it from casting light on the lens. Here is a wider angle of the setup:

This will teach me to type config files from memory: don’t set the device in the qpage.cf file to /dev/ttyS3. Instead, create a symlink to <strong>/dev/ttyS2</strong> called /dev/modem. Like so:

`This will teach me to type config files from memory: _don't_ set the device in the qpage.cf file to/dev/ttyS3. Instead, create a symlink to/dev/ttyS2called/dev/modem`. Like so:

``

I’ve already fixed the initial post, but qpage insists on the name being /dev/modem – likely due to the fact that it’s really old code. I’ve not got the time or the interest to hunt about in the source and try to fix it.

Finally, we’re here. It’s time to set up the modem from part I and part II so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let’s use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple /etc/qpage.cf file:

``Finally, we’re here. It’s time to set up the modem from part I and part II so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let’s use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple /etc/qpage.cf file:

``

Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we’re talking from localhost to the modem (so we’re not relying on the network being up to send the pages). Send pages with

  qpage -f from_address user_1_pager <em>message</em>

or

  qpage -f from_address server_admins_pager <em>message</em>

The first example will hit user_1’s pager, and the second should hit both. Once this is working, create a simple script to queue messages. I’ve written a quick one in perl, but you can use pretty much any language you like. Shove it into your nagios/libexec directory, and make sure it’s owned and executable by the nagios user.

```Finally, we’re here. It’s time to set up the modem from part I and part II so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let’s use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple /etc/qpage.cf file:

``Finally, we’re here. It’s time to set up the modem from part I and part II so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let’s use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple /etc/qpage.cf file:

``

Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we’re talking from localhost to the modem (so we’re not relying on the network being up to send the pages). Send pages with

  qpage -f from_address user_1_pager <em>message</em>

or

  qpage -f from_address server_admins_pager <em>message</em>

The first example will hit user_1’s pager, and the second should hit both. Once this is working, create a simple script to queue messages. I’ve written a quick one in perl, but you can use pretty much any language you like. Shove it into your nagios/libexec directory, and make sure it’s owned and executable by the nagios user.

Finally, add create a new user definition in Nagios, which you'll add to the hostgroups as normal, but instead of giving the user object an email address, give it the phone number. You aren't going to actually use it, but consistency is king here.

````Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

`` 

Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
  
&nbsp;&nbsp;`qpage -f from_address user_1_pager <em>message</em>`
   
or
  
&nbsp;&nbsp;`qpage -f from_address server_admins_pager <em>message</em>`

The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.

```Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

`` 

Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
  
&nbsp;&nbsp;`qpage -f from_address user_1_pager <em>message</em>`
   
or
  
&nbsp;&nbsp;`qpage -f from_address server_admins_pager <em>message</em>`

The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.

Finally, add create a new user definition in Nagios, which you’ll add to the hostgroups as normal, but instead of giving the user object an email address, give it the phone number. You aren’t going to actually use it, but consistency is king here.

Finally, add the contact handlers in Nagios, copying out the standard email contact and replacing it with something like this:

`````Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

`` 

Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
  
&nbsp;&nbsp;`qpage -f from_address user_1_pager <em>message</em>`
   
or
  
&nbsp;&nbsp;`qpage -f from_address server_admins_pager <em>message</em>`

The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.

```Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

`` 

Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
  
&nbsp;&nbsp;`qpage -f from_address user_1_pager <em>message</em>`
   
or
  
&nbsp;&nbsp;`qpage -f from_address server_admins_pager <em>message</em>`

The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.

``` 

Finally, add create a new user definition in Nagios, which you'll add to the hostgroups as normal, but instead of giving the user object an email address, give it the phone number. You aren't going to actually use it, but consistency is king here.

````Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

`` 

Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
  
&nbsp;&nbsp;`qpage -f from_address user_1_pager <em>message</em>`
   
or
  
&nbsp;&nbsp;`qpage -f from_address server_admins_pager <em>message</em>`

The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.

```Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

``Finally, we're here. It's time to set up the modem from [part I][1] and [part II][2] so you can it them from Nagios directly. If you run this along side SMS alerts (as I do at work), you now have two fully redundant out-of-band networks to use for alerting on call sysadmins. You are going to need a list of the administrators pager numbers. This should be in your emergency contact file next to their email addresses and phone numbers, under lock and key, only to be opened when the SAN shuts down again and you need EVERYONE, NOW. You are also going to need the TAP numbers to dial into the various wireless services to send the pages via qpage, a notification script that can be called, and you will need to add that notification handler to your Nagios configs.

Let's use a simple example: all your administrators are using pagers on the same operator, you only have one on-call emergency group, and you are using the modem I suggested in the last part in this series. Here is a simple `/etc/qpage.cf` file:

`` 

Now, when you start up the qpaged service, it will read this file, and setup a queue to which pages can be submitted. The default port is TCP 444, but we're talking from localhost to the modem (so we're not relying on the network being up to send the pages). Send pages with
  
&nbsp;&nbsp;`qpage -f from_address user_1_pager <em>message</em>`
   
or
  
&nbsp;&nbsp;`qpage -f from_address server_admins_pager <em>message</em>`

The first example will hit user_1's pager, and the second should hit both. Once this is working, create a simple script to queue messages. I've written a quick one in perl, but you can use pretty much any language you like. Shove it into your `nagios/libexec` directory, and make sure it's owned and executable by the nagios user.

``` 

Finally, add create a new user definition in Nagios, which you'll add to the hostgroups as normal, but instead of giving the user object an email address, give it the phone number. You aren't going to actually use it, but consistency is king here.

Finally, add the contact handlers in Nagios, copying out the standard email contact and replacing it with something like this:

`````

Now, when the appropriate service flags itself, qpage will dispatch a message to the listening daemon, and send a page in addition to an email, a jabber message, an SMS, or whatever system you like. If there’s an interest, I’ll also walk through how to setup Google Talk (jabber) notifications and SMS notifications with gnokii-smsd.

Just decompressed from Joe McNally and David Hobby’s Flash Bus off-camera lighting workshop. It was beyond excellent. Several times it made me truly wish I had the experience to be a professional photographer.

Working towards that goal, I ordered a bunch of the key light modifiers that I’ve been needing and putting off (shoot-through umbrellas, real light stands, a small softbox, etc). I also tried to get back into the filter-refine-comment-upload process: I went through 366 photos I took at the event, and in an hour, got them down to the 18 I really liked, titled them properly and uploaded them to flickr.

Enjoy!

Here are some tips to get the most out of a Nikon 7000’s internal image buffer, where images are stored after being taken, but before they are transferred to your SD card. This buffer limits the number of shots you can take in a single high-speed burst. This is particularly important when shooting in RAW, and you are trying to eke out every last frame in a burst. Out of the box, the buffer when shooting in RAW is 7 images, much less than the marketing value of 15 for RAW. This is because a number of options are set for the consumer market. I guess Nikon figures prosumers can figure all of this out.

First, turn off high ISO noise reduction, long exposure noise reduction, distortion correction, and active-d lighting. Even though most of them don’t apply to the RAW images themselves, they *do* apply to the JPEG preview saved inside of every RAW file – even when you aren’t shooting in RAW+JPG mode. Also, go ahead an set the RAW mode to 12-bit compressed (not lossless) – the size of the RAW images matters a lot in how fast you fill the internal buffer of the camera.

Finally, use a high speed SD card. Slow cards basically guarantee that you won’t write more than one or two frames out to the card while shooting your burst. With a fast card, you may get three or four. If you are looking for a fast SD card, there’s a new line of Ultra-High Speed cards out from Sandisk that are very expensive, but are rated very well. There is a new line of faster UHs cards from Sandisk that are expensive but super quick. ($140 for a 32GB card, at the time of this writing.)

All of this will push the buffer itself from 7 images to 11, and the faster card will let the image write out of the buffer to the card quicker. With a sufficiently fast card, you will be able to pull off 15 shots in about 3.5 seconds, which is pretty good, and the fast card will help the buffer clear quicker so you can get back to shooting the next burst.

As a final note, if you shoot JPEG, not RAW, simply dialing down the image size will make the buffer go crazy. With the settings from above, and the Small JPEG setting, you can easily run into the 100-shot limitation Nikon has set for a single depression of the shutter release. The good news about that is it doesn’t fill the buffer, so when it stops shooting, just lift off and hit it again, and you’re back in for another 100 shots.

Egon was right. Print is dead.

The New York Times Paywall went live yesterday. Sad to see a giant of the print media come to such an end. Instead of embracing new technologies, they are trying to stifle them, and in doing so, will cause their own death. And I don’t care what the argument is, but charging for each separate rates for each digital edition (web, iPhone, iPad), and then saying those are all free if you get the dead-tree edition (which costs less, natch)… is the worst kind of insult to the people they are trying to reach: savvy, technically literate, affluent consumers.

The really sad part is that the world needs more in-depth investigative journalism, and that kind of reporting and research takes time and money. Bloggers, while important to the media landscape, can’t take their place, and the 24-hours Cable News Panic Cycle isn’t interested in stories that aren’t soundbites.

The Mac App store is really a cool thing, especially in that it lets you run the software on every computer you’ve authorized with your Apple ID. However, I’m already syncing a number of important apps between my various Macs with Dropbox. Today I’m going to show you how easy it is to combine Dropbox and the Mac App Store.

This whole scheme relies on a part of OSX brought in from NeXT and rarely acknowledged by users of OSX: the ability to have more than one Applications folder. Just like there are multiple Library folders on every OSX box (/System/Library, /Library, and ~/Library), you can create an ~/Applications folder and any application in there will be treated like a first-class application in /Applications. System Services work, installation checks and upgrades work, the whole nine yards. The only thing that doesn’t work is that other user accounts of the same computer can’t and won’t see your installed applications. Which, when talking about Mac App Store apps, is just fine, as they need your account credentials to make it work anyway.

So, to set this up, fire up Terminal, and issue these commands:

`The Mac App store is really a cool thing, especially in that it lets you run the software on every computer you’ve authorized with your Apple ID. However, I’m already syncing a number of important apps between my various Macs with Dropbox. Today I’m going to show you how easy it is to combine Dropbox and the Mac App Store.

This whole scheme relies on a part of OSX brought in from NeXT and rarely acknowledged by users of OSX: the ability to have more than one Applications folder. Just like there are multiple Library folders on every OSX box (/System/Library, /Library, and ~/Library), you can create an ~/Applications folder and any application in there will be treated like a first-class application in /Applications. System Services work, installation checks and upgrades work, the whole nine yards. The only thing that doesn’t work is that other user accounts of the same computer can’t and won’t see your installed applications. Which, when talking about Mac App Store apps, is just fine, as they need your account credentials to make it work anyway.

So, to set this up, fire up Terminal, and issue these commands:

`

On the rest of your Macs that are sync’ed with Dropbox, the second one is the only necessary one. It creates the ~/Applications folder as a link to the Dropbox/Applications folder. Now, anything put into the Dropbox folder is sync’ed to the rest of your Macs. Updating Apps from the App Store is seamless – the copy in Dropbox is upgraded and changes are pushed all around the place seamlessly.