Archive for January, 2010

Apple iPad: The Computer for Somebody Else |

January 28, 2010

Being a long-time Mac user I watched with millions of others as Steve Jobs introduced us to the iPad. It was pretty much as expected using the iPhone platform to deliver a tablet experience with no keyboard. Everything about the product makes sense in terms of it being a device for casual use of the Internet (email, facebook, etc.) and a dispenser of iTunes (needs a new name now) content (movies, music, books, apps, etc.).

Will they sell millions? Yes. Will I buy one? Most likely not in the near term. It simply does not add enough value between my MacBook and my iPhone to justify being another object in my life. So from my perspective it is a product for “somebody else”. Somebody that does not have a MacBook, somebody that is not a consultant by day creating complex documents and power using the Internet and a mobile DJ with a 500G music library to haul around at night.

Then who is this “somebody else”? These people are the ones that iTunes and Facebook have brought to the Internet and computers. These people have to be connected to maintain their connections to their friends and families. They listen to music, watch movies, exchange emails, they tweet and look at pictures on the web. There are milions upon millions of these folks out there. But they are not me. I build media centers out of Mac Minis, have terabytes of media, and maintain 10 web sites and 3 social networks.

So I do think it will be a BIG money maker for Apple. It’s a true consumer product… for some other consumer.

The Macintosh was labeled “The Computer for the Rest of Us” back when it was introduced in 1984. Today they went back and picked up the stragglers.


Spigit Brings SAAS Social Networking Tool to SMBs

January 19, 2010

via eWeek – RSS Feeds on 1/19/10

Spigit, Jan. 19 launched WE by Spigit for SMBs of 500 employees or less to work on specific projects within the Spigit construct, which ranks contributors’ reputations. Spigit communities are hosted on Spigit’s servers and delivered via the Web as a SAAS (software as a service) solution. Spigit rivals include’s Ideas application, as well as other startups such as BrightIdea and SuccessFactors.
– Spigit, a startup whose social networking application helps enterprise employees work together on specific goals, is moving downstream. The company Jan. 19 launched WE by Spigit for SMBs of 500 employees or less to work on specific projects within the Spigit construct, which rank…

David Letterman – Dave Discusses Conan, Leno & NBC

January 16, 2010

As usual, Dave knows best how to sum things up. – Mike

Dave analyzes the latest developments in the NBC late-night debacle. … cbsepisode late show david letterman conan o'brien jay leno nbc late …

Simple backup script for Rackspace Cloud

January 16, 2010

I will have to look at implementing this one a couple of sites. – Mike

via Capellic by Stephen Musgrave on 12/21/09

I could have installed the Drupal Backup & Migrate module for this, but then that's yet another module and yet another activity during cron — and how would it play with my caching done at cron? I didn't want to find out.

There was a very simple backup script that I found in Rackspace Cloud’s knowledge base, but it didn't have rolling backups.  I've found the errors in data aren't found for a couple of days, so a backup down at 4:00 AM that morning wasn't going to be very helpful. 

I wanted rolling backups for 4 days, and I found this script which did just that.  I added some variables for the Rackspace Cloud environment, added some debugging statements and I was done.

The script will create a total of 4 backup directories with directory "01" always having the most current backup and "04" having the oldest backup.  Two archive files will be created in each folder – one for the database and one for the file system.

While I am using this to backup my Drupal sites, it certainly isn't limited to it.  In fact, if it was truly setup for Drupal, I would have some code in here that would put the site in maintenance mode, run the backup and then turn the site back on.  I would proabably also opt not to backup all tables – excluding access_log, cache_* and watchdog.  I'll get that in the new year.

Note that this script can also be used to run backups for any time interval.  It would be easy to copy this script to use for a weekly backup.  Just change the backup directory names so that they don't overwrite your daily backups and then setup the cron to run once a week.  Or it might be better to copy the existing backup to a new folder once a week.

Installing the Script

Follow these steps to setup on Rackspace Cloud:

  1. Create directory "
  2. Create script,, in backup directory
  3. Change variables at the top of
  4. Add cron job to run once a day that isn’t running when your cron.php job is running (Drupal)
    1. Task name: Daily Backup
    2. Email Address for Output: (or your email address for testing)
    3. Command language: perl
    4. Command to run: backup/

The Script

Just change the variables at the top of the file to match your website settings and you don’t have to touch anything under that.

Of course you can remove all the echo lines, but I find they are useful for debugging.  I like to have the resutls of the cron emailed to me for a week and then I'm reassured that the script is running consistently.  (Cron can be moody.)

 #!/bin/bash # Modeled after #### VARIABLES # ACCOUNT_ROOT can be found on the Features tab in the control panel for the site export ACCOUNT_ROOT="/mnt/stor2-wc1-dfw1/394655/394685/" export WEB_ROOT="${ACCOUNT_ROOT}/web/content" export DB_HOST="DB_SERVER_INTERNAL_NAME" export DB_USER="DB_USERNAME" export DB_PASSWORD="DB_PASSWORD" export DB_NAME="DB_NAME" #### PROGRAM - NO EDITING AFTER THIS LINE SHOULD BE NECESSARY echo "Rotating backups..." rm -rf $ACCOUNT_ROOT/backup/04 mv $ACCOUNT_ROOT/backup/03 $ACCOUNT_ROOT/backup/04 mv $ACCOUNT_ROOT/backup/02 $ACCOUNT_ROOT/backup/03 mv $ACCOUNT_ROOT/backup/01 $ACCOUNT_ROOT/backup/02 mkdir $ACCOUNT_ROOT/backup/01 echo "... done rotating backups." echo "Starting database backup..." mysqldump --host=$DB_HOST --user=$DB_USER --password=$DB_PASSWORD --all-databases | bzip2 > $ACCOUNT_ROOT/backup/01/mysql-`date +%Y-%m-%d`.bz2 echo "... database backup complete." echo "Starting file system backup..." tar czf $ACCOUNT_ROOT/backup/01/web_backup.tgz $ACCOUNT_ROOT/web/content/ echo "... file system backup complete." exit 0 #### END PROGRAM

Ambient Tunes While You Ride Your Bike

January 15, 2010

This could be a very big hit with the cycling and scooter crowds.


via Fast Company by Cliff Kuang on 1/15/10

Tunebug turns the helmet itself into a flat-panel speaker

Tunebug Shake

January 30th, a tech start-up, Tunebug, is set to release one of the weirdest speaker designs we’ve ever seen, the Shake. By itself, it’s not a speaker. Rather, the $120, puck-like device affixes to anything from a tabletop to a bike helmet, and transmits sound waves through that medium. Thus, the surface itself transmits the sound, like one big flat panel speaker.

So why wouldn’t you simply design tiny speakers, rather than relying on what has to be degraded sound quality? Tunebug claims that the appeal is getting lots of volume from a tiny, compact, and durable package. But the killer app might be for bike riders, snowboarders, and the like.

For all those activities, headphones are a no-no–sealed off from the environment, without situational awareness, you’re asking for a accident. Tunebug Shake is supposed to solve that problem, by still allowing you to hear what’s going on around you, and turning the soundwave into something that envelops you so that you’re not concentrating on it too much. (Think of the sound system in your car.)


Of course, the key issue has to be sound quality–who cares if you can hear through your helmet, if it sounds like a bunch of bumblebees behind a wall. But we’re eager to see if it works–this could be pretty amazing.

[Via Gizmag]

Military Deluged in Drone Intelligence – New York Times

January 11, 2010

HAMPTON, Va. — As the military rushes to place more spy drones over Afghanistan, the remote-controlled planes are producing so much video intelligence that analysts are finding it more and more difficult to keep up.

Skip to next paragraph

Daniel Rosenbaum for The New York Times

Col. Daniel R. Johnson, right, in the intelligence center at Langley Air Force Base in Hampton, Va., where analysts watch every second of drones’ video footage live as it is streamed there.

Master Sgt. Demetrius Lester/U.S. Air Force, via EPA

An MQ-1 Predator drone returned from a mission to Bagram Air Base in Afghanistan in 2008.

Air Force drones collected nearly three times as much video over Afghanistan and Iraq last year as in 2007 — about 24 years’ worth if watched continuously. That volume is expected to multiply in the coming years as drones are added to the fleet and as some start using multiple cameras to shoot in many directions.

A group of young analysts already watches every second of the footage live as it is streamed to Langley Air Force Base here and to other intelligence centers, and they quickly pass warnings about insurgents and roadside bombs to troops in the field.

But military officials also see much potential in using the archives of video collected by the drones for later analysis, like searching for patterns of insurgent activity over time. To date, only a small fraction of the stored video has been retrieved for such intelligence purposes.

Government agencies are still having trouble making sense of the flood of data they collect for intelligence purposes, a point underscored by the 9/11 Commission and, more recently, by President Obama after the attempted bombing of a Detroit-bound passenger flight on Christmas Day.

Mindful of those lapses, the Air Force and other military units are trying to prevent an overload of video collected by the drones, and they are turning to the television industry to learn how to quickly share video clips and display a mix of data in ways that make analysis faster and easier.

They are even testing some of the splashier techniques used by broadcasters, like the telestrator that John Madden popularized for scrawling football plays. It could be used to warn troops about a threatening vehicle or to circle a compound that a drone should attack.

“Imagine you are tuning in to a football game without all the graphics,” said Lucius Stone, an executive at Harris Broadcast Communications, a provider of commercial technology that is working with the military. “You don’t know what the score is. You don’t know what the down is. It’s just raw video. And that’s how the guys in the military have been using it.”

The demand for the Predator and Reaper drones has surged since the terror attacks in 2001, and they have become among the most critical weapons for hunting insurgent leaders and protecting allied forces.

The military relies on the video feeds to catch insurgents burying roadside bombs and to find their houses or weapons caches. Most commanders are now reluctant to send a convoy down a road without an armed drone watching over it.

The Army, the Marines and the special forces are also deploying hundreds of smaller surveillance drones. And the C.I.A. uses drones to mount missile strikes against Al Qaeda leaders in Pakistan.

Air Force officials, who take the lead in analyzing the video from Iraq and Afghanistan, say they have managed to keep up with the most urgent assignments. And it was clear, on a visit to the analysis center in an old hangar here, that they were often able to correlate the video data with clues in still images and intercepted phone conversations to build a fuller picture of the biggest threats.

But as the Obama administration sends more troops to Afghanistan, the task of monitoring the video will become more challenging.

Instead of carrying just one camera, the Reaper drones, which are newer and larger than the Predators, will soon be able to record video in 10 directions at once. By 2011, that will increase to 30 directions with plans for as many as 65 after that. Even the Air Force’s top intelligence official, Lt. Gen. David A. Deptula, says it could soon be “swimming in sensors and drowning in data.”

He said the Air Force would have to funnel many of those feeds directly to ground troops to keep from overwhelming its intelligence centers. He said the Air Force was working more closely with field commanders to identify the most important targets, and it was adding 2,500 analysts to help handle the growing volume of data.

With a new $500 million computer system that is being installed now, the Air Force will be able to start using some of the television techniques and to send out automatic alerts when important information comes in, complete with highlight clips and even text and graphics.

“If automation can provide a cue for our people that would make better use of their time, that would help us significantly,” said Gen. Norton A. Schwartz, the Air Force’s chief of staff.

Officials acknowledge that in many ways, the military is just catching up to features that have long been familiar to users of YouTube and Google.

John R. Peele, a chief in the counterterrorism office at the National Geospatial-Intelligence Agency, which helps the Air Force analyze videos, said the drones “proliferated so quickly, and we didn’t have very much experience using them.

“So we’re kind of learning as we go along which tools would be helpful,” he said.

Sign in to Recommend
Next Article in
Business (3 of
32) »

A version of this article appeared in print on January 11, 2010, on page A1 of the New York edition.

Now this is a really interesting problem and domain. It seems we need to have “producers” covering a theater of battle to coordinate all of the video feeds from the field and synthesize it down to a meaningful experience. Amazing!

How to Write a Client Proposal | ITworld

January 4, 2010

December 30, 2009, 05:29 PM — 


Software developers, web designers, and other IT professionals who are trying to build up a consulting business are often asked to provide the prospective client with a formal proposal explaining how they’ll serve the company’s needs. If you’re new at this, you may be amenable but also unsure what to actually say. Let me give you a little guidance.

Anybody can use open source. You might depend on open source software if you’re responsible for IT in a large enterprise or as a consumer who prefers FOSS apps for her own personal computing needs. That’s true whether you’re simply a software developer contributing code to the open source project, a techie who customizes software that just-so-happens to be open source (such as a web developer building sites using Drupal), or an end user who appreciates the price (free!) and quality of FOSS apps.

However, while I’m not sure whether the statistics back this up, by my observation the open source community has a higher-than-usual percentage of consultants, value added resellers (VARs), design studios, and other “independent” techies who pay the rent by making a client happy. This blog post is directed to them. (This is nominally part of my random series on building a career in open source. It is the other side of the writing a résumé issue since consultants rarely need such documents to get work.)

My suggestions also might be helpful for staff developers and designers serving an internal audience. After all, as Jerry Weinberg pointed out in my most-favorite consulting book, Secrets of Consulting, anyone who offers advice is a consultant. However, mainly I’m talking to techies who, on a part-time or full-time basis, intend to get paid (by someone other than a full-time employer) for making software work.

The problem that techies have is that they want to talk about and use technology, and they hate having to “sell” anything — particularly themselves or their skills. Often, or at least to begin with, the work comes to them, either because they’ve developed a reputation for excellence (“My brother-in-law says you’re good at creating websites”) or because of a relationship with another techie who needs assistance (“A client asked me to take this on and I’m already busy; could you write the back-end code and I’ll deal with the company?”). That’s fine — and with the right connections you can make a living that way.

But at some point, a prospective client will ask you to give them a proposal. For example, a client may tell you what they have in mind, and end with, “Could you put together a proposal for the project, broken down by cost for the individual components?” You’re willing, but sheesh, what are you going to say?

Proposal writing is an art unto itself, and I don’t promise to be brilliant at it. I’m sure you can find how-to books at your local library, though back when I needed to write these documents regularly, I found the “write a proposal” books were tuned more for people writing government proposals worth millions of dollars, not a solo practitioner or small business trying to win a deal. The books were overkill, then; perhaps they’re better now.

However, I did eventually learn the skill, and it got me plenty of consulting work and related gigs. This advice is what worked for me. I don’t promise it’s best from you, but maybe it will get you started.

There’s a few distinct parts to a proposal. Length is rarely an issue — the proposal can be four paragraphs, four pages, or forty pages — but it usually covers the following:



  • Identify the problem.
  • Describe the solution, and the steps to get there.
  • Explain why you’re the right person to do it.
  • Tell them what it costs.
  • The key part is to figure out what your prospective client wants — a matter of empathy and research. What problem do they want to solve? In the proposal, you restate the problem in your own words, backing up how you’ll help them achieve their goals. In other words: “You say you want a site to serve left-handed beer brewers with editorial content that’ll draw them to your e-commerce site where you sell left-handed equipment; here’s what I’ll do to help you succeed.”

    The hard part is to get into their heads. If you understand what success looks like to them, then it’s mostly a matter of explaining what the steps are to get there (and pointing out how each step, or component, helps move the site towards their goals). There’s several good reasons to include the problem description. One of them is to show the client that you were listening and that you understand their pain. After all, if you got the wrong idea in your head about the problem to be solved, you probably can’t deliver something that will make the client happy.

    If you can’t write that “problem statement” then recognize it as a danger sign. It may mean that they blathered for an hour but you never understood the goal (“What does ‘success’ look like to this client?”). It may mean that the client doesn’t actually know what they want — an extremely common situation. (Determining what the client actually wants is a mysterious subject best left to another discussion. One that includes a lot of beer.) But this is not only about client cluelessness; it’s also a way for you to establish your own project guidelines. If you find that it’s hard to answer, “What’s the problem here?” you may need another round of user interviews, which is why I recommend that you don’t write the proposal the night before it’s due. (Not that I’m speaking from experience, you understand.)

    The last two steps in the proposal are relatively easy. You probably know why you’re the right person to solve the client’s problem (“I’ve done lots of stuff like this before, and here’s the references to prove it”), and “how much it costs” is just a number. How to reach that number, i.e. “How much should I charge?” is yet another discussion, but in proposal terms it’s easy: This is what it’ll cost you. If you’ve done your work well in the rest of the document, the implication will be, “…and I’m worth every cent.”

    The meat of the proposal is explaining the solution you think is best to solve their problem.

    As a techie, you may be tempted to give the prospective client a vague arm-wave about the technologies you use, links to previous sites you worked on, and a laundry list of what would be involved for the project. (“I’d set up your DNS, install the software, create a custom theme….”) There’s a temptation to write the proposal as if it’s a To Do list you’d show another software developer. Don’t. Few clients will have the first idea of what you’re talking about. All you’ll do is demonstrate that software people speak gobbledegook and cannot be trusted. You won’t get the assignment.

    You’ll note that none of this discussion, so far, has been about open source. There’s a reason for that: It generally isn’t a big part of the proposal. (But lots of open source consultants think it has to be, which is why the topic is relevant.) Here’s the part that the FOSS people care about: You might be tempted to turn the proposal into a chest-beating document extolling the virtues of the open source (or other) technology in which you specialize. And, if you’re certain you know don’t know how to sell, you might copy-and-paste descriptions from the FOSS project documentation and clutter it up with other people’s praise of the open source software you’ll use.

    Again: Don’t. You’ll have expended your effort on selling the open source philosophy instead of selling your blazingly brilliant software design and development skills. Either the client won’t care that you use open source (because what they want to buy from you is a working solution, and they don’t care about the box it doesn’t come in), or you’ll sell them on open source but forget to sell them on you. And you still won’t get the assignment.

    Clients want their computing problem solved with the ease of getting a pizza delivered: call a number, tell them what you want, and it shows up soon afterward. The ingredients you use in the pizza rarely matter to the hungry person who wants dinner. (When they do quiz you on the software you’ll use, that’s the time to bring out the open source marching band and play up its benefits. Usually, their qualms are answered when you say, “It’s saving you money since I don’t have to charge you for a software license, too.” But you’ll be amazed at how little clients care.)

    Instead, the proposal should identify functional categories. That is, a proposal to build the client’s website might have one stage in which you establish the Site Structure (which includes setting the DNS, installing software), another for design issues (working with client to identify custom themes, choose photos), still another for content creation functionality (get existing content uploaded, teach them how to use the system), perhaps a stage for getting the site noticed (SEO, etc.). Describe those steps in English with headings that your most non-techie relative would understand. You might care whether “install Askimet” goes into “Site Structure” or a different category, and you may want to document it in that section (under a “tools” list) if the proposal will also serve as the starting project spec (it often does). But each functional category should represent a stage in the project, accompanied by a paragraph that explains how it contributes to the client’s goal. (Everything keeps coming back to that.)

    Each phase also gets a time estimate and what it depends on (e.g. “4-6 weeks, starts after design signoff, requires meetings with client’s marketing director”); some of this may be included in the consulting contract, which is usually but not always a separate document.

    When possible, organize the phases based on the personal interaction necessary. Some chunks of project functionality require the client’s input; those are the bits that I’d prefer to bill on an hourly rate or estimate with a worst-case view (meetings are scheduling pains, and you have less control over them: “Oh sorry we put that off until next week!” leaving you twiddling your thumbs). Other project phases let you work alone, without client participation (such as the DNS and installation stuff, which you’re probably comfy enough with to bid on a fixed price). Whether or not you say so explicitly in the proposal, at the end of each function there’s a clear product: a live site ready for content, a wireframe with a client signature, a system to track site analytics. (Do find some way to get them to sign off on each phase… but that’s a getting-paid issue rather than proposal writing skill.)

    Or to think of these functional categories another way: Break it up into sections that let you invoice regularly. If nothing else this means you could finish one piece of the project, invoice for it — and see if they actually pay on time. And if everything went to hell in a handbasket, they’d have that one part “done” without you needing to talk to them ever again. (Can you tell that I learned to plan for worst contingencies?)

    I recommend that you include an optional phase that you think they client doesn’t really have to have for the project to achieve success. Some clients need something to throw out; it seems to give them a sense of power to say No to something, and you don’t want them doing that on something vital. But it shouldn’t be really silly because they might want it, and it shouldn’t make you sorry you offered. (“Social media services” perhaps?) Also, if they decide that they want you but can’t afford everything you proposed, it lets you knock an item off the list and reduce the price without making it seem like you’re cutting your rate.

    Don’t worry about the granularity of what you propose. I’ve known people who worry that the client will use your brilliantly-written proposal as a spec that they hand over to another consultant (who presumably will do it cheaper because you did all the hard design work). This does happen occasionally, but you have to learn to take it as a gift from the universe. If the client is so unethical or clueless as to imagine that’s okay, almost certainly they would qualify as a client from hell.

    There’s more to successful proposal writing, I think, but that should be a start for those who are new to the game.

    (Note: Inspiration for this post came from a thread on the Wise Women discussion lists. It’s a high-volume, supportive, friendly community that I heartily recommend.)

    You probably should follow me on Twitter. Because, y’know, you just should.

    Sign up for ITworld’s Daily newsletter
    Follow ITworld on Twitter @IT_world

    This is by no means a comprehensive tutorial on the subject but there are some very good ideas in this article to digest. I will try to compose something on the topic soon.