Big Dave’s Blog

High Tech Cowboys of the Deep Seas: The Race to Save the Cougar Ace

Photo: Courtesy of US Coast Guard

These guys use some smarts instead of heavy machinery to salvage ships in trouble. When you get offered $30M to save one ship and hold out for more, that extra savings makes for a nice profit. No tugs or cranes are used. Instead, all the equipment is can be put on a plane to the closest airport and a speedboat can get them to the ship fast. Their Dutch competitors can take days or weeks to get a salvage ship with cranes, etc. to the site.

Why is this cool to me? The guys at Titan build an on-the-fly digital replica of the ship in trouble. Then, they use the software to figure out an ingenious way to fix it. It’s a tricky task. If you get the calculations wrong, you end up sinking the ship. Get them right, and you save the ship without lots of heavy equipment and collect 10-70% of the ship’s value. Also, I spent some time after college driving Nissans off these ships in preparation for dealer lots. If you haven’t been up close to or inside a car container ship, let me tell you they are huge.

What a use of technology! Phone rings: “Cold weather or warm, mate?” They’re off…

The only downer is that one man died saving this ship. Unfortunately, technology can’t account for the dangers of moving around on a 60 degree tilt.

Wireless: Google May Buy a Balloon Company to Build Huge Wireless Networks

OK, I’m intrigued. The balloons only last a day or so, and then they come down.  This is my problem. Exactly where do these things come down?  If Google wants to put up bunches of these things every day, that means bunches of 6 pound transmitters come down on my head.  Kind of a minor kink, don’t you think?  Now, if they can solve the gravity problem, then you can cover the entire country with 370 $1500 balloons instead of 22,000 cell towers. I bet the towers are a little more money, and not having towers everywhere would sure make the countryside look a little nicer.

It will be interesting to keep an eye on this one.

It took a while, but I finally got to the top.  Those of you with a name like a celebrity or a common name know what I mean.  Use Google to search for yourself.  What page are you on?  I happen to have the same name as a former Mr. Olympia and actor from from the movie “Pumping Iron.”  For the longest time, his name dominated searches for me.  Now, between this blog, LinkedIn, and a couple of other web voices, I am at the top of the list.  It’s actually pretty impressive considering none of the web sites that mention me get huge amounts of hints, but Google still is able to rank based on relevance and recentness.

Lesson learned.  If you want to get yourself found on the web, start a blog and get people to link to it. Note, reciprocal links don’t count as much (if at all).

The funny thing is that by me linking to the other Dave’s site above, I may have just moved my rank down since a big part of page rank is inbound links.  Now I just need more people to link to this blog…

Body Heat Could Charge Your Cellphone

Saw this article the other day, and I couldn’t get over the possibilities.  As interesting as charging your cellphone from body heat is, think of all the other possibilities.  If you live in the North East like I do, you could generate electricity from the lost heat of your furnace or boiler.  It is unclear how much power you can generate from heat, but making power generation orders of magnitude more efficient is a pretty huge jump.  Power stations being 100x more efficient would sure save a lot of fuel costs.

I normally wouldn’t do this, but this looks too good.

Definitely be checking this out over the summer.

I’ve been a little lax lately with posts, but there is a good reason.  Yesterday afternoon, Inquisix launched Private Beta.  It’s been a very busy few months building the site and getting everything rolling.  Being a very early startup, we operate without a lot of resources, but that makes it fun.  There is nothing like taking a site live and seeing dozens of users jump in and start using the product within minutes of sending an invitation email.

If you are a sales or business development person, check it out and request an invitation.

Now back to the regular posts - I have a lot of new material now.

Chris Herot’s post on Zingdom Communications, formally Convoq, closing its doors recently is a must read for anyone in a startup. While the news is bad, the lessons learned should be posted on every wall. The same mistakes get made too often - especially iterating in the conference room instead of the marketplace. Don’t ever forget the customer! Too often we forget that.

Lessons according to Chris:

• Just because you are using agile methods doesn’t mean you don’t have to plan. Write your stories before you begin an iteration, but don’t waste a lot of time on the details that aren’t needed until later.
• Don’t spend a lot of time and money naming the company until you have the product and positioning figured out.
• If you are depending on paid search to generate traffic then your marketing is broken.
• Raising too much money is almost as dangerous as raising too little - it sets high expectations which then drive high expenditures to deliver the results on time.
• If you want to do a consumer-facing product on the East Coast, stay engaged with the community in Silicon Valley. By the time you read about something in TechCrunch it’s too late.
• Remember the three stages of building a web property: 1. Attract, 2. Engage, 3. Monetize. Don’t skip a step.

Print it. Post it. Remember it.

If you are a software developer or manager of a software development team, how many times have you heard something like “This is cool, we should do it!”? Whenever I hear that, I get nervous. Don’t get me wrong, cool stuff is, well, cool, but that doesn’t mean it is valuable to the customer. Remember the days of the big desktop applications throwing every feature possible into their applications? You still see it to some extent, but not to the level of Lotus vs. Microsoft in the late 80s and early 90s. When I was at Lotus, we had features that were specifically in there because they were cool and demoed well. Very few people would actually use them, but they were cool damn it! At that time, you could almost justify it, but I never bought all the wasted resources.

With small companies and limited budgets, you have to concentrate on valuable. Customers demand it, and my budget can’t afford to build anything that isn’t valuable to the customer. Normally, I hate the term “good enough,” but it applies well to software. Software should be good enough, and no better. Anything else is wasting resources. I’m certainly not the first person to say this, but it works for me.

Now, there are are products and features that are both cool and functional - the iPod comes to mind. If you can find that, then you really win, but no matter what it is, it must be functional above all else.

So, next time you think up some cool feature, take a step back and look at it from the customer perspective. Does my customer really need that fancy Ajax drag & drop tool? Is this going to make my customer’s life easier? If the answer is no, then forget it and move on.

At one point in my career, I had a sign on my desk that read: “No. What part of this don’t you understand?” It was only half joking, but it got the point across that features and changes needed customer value before they got into the project. In the end, I will take functional over cool any day. Cool wears off, but functional usually keeps being functional.

I’ve been a little busy for the last few months. As I hinted at a couple of times, I’ve been working on a new venture. Well, that venture is starting to get more public. My partner and I have been working on Inquisix. Inquisix is a site designed for sales people to help them meet better prospects. I’m having a blast, and it’s great to be able to talk about things more.

Anyway, the interesting technical item that came up is related to our blog. At my last startup, I migrated my team to Ruby from Java, and I haven’t looked back. That made Ruby on Rails an easy choice as a development platform for Inquisix. Of course, we also wanted a blog. There are Ruby alternatives for blogging. Mephisto is probably the best example, but I am more familiar with Wordpress. While it would be great to have a Ruby blog, it’s hard to ignore Wordpress for blogging, and I’m not a big enough Ruby zealot to require that everything must be Ruby. Therefore, I decided on Wordpress.

However, there is one problem. I wanted my blog’s url to be http://inquisix.com/blog. How do I convince PHP and Rails to co-exist on the same server? After a little searching, I found a great blog post by Ilya Grigorik - Integrating Wordpress and Rails. At first, it worked great, but things failed when I tried to change my settings to use permalinks based on dates. Once I did this, only pages with an existing physical file worked.

This is what Ilya proposed for a local installation of Wordpress:

# Check for maintenance file and redirect all requests
RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /system/maintenance.html [L

# Let apache handle the PHP files - all requests that get past this rule
# are routed to the mongrel cluster (aka Rails
#  - wordpress installation assumeed to be in 'public/wordpress'
#  - Options: NC - case insensitive
#  -          QSA - query string append
#  -          L - last rule, aka stop here if rewriterule condition is matched
RewriteRule ^/blog/?(.*)$ %{DOCUMENT_ROOT}/wordpress/$1 [NC,QSA,L]

# Redirect all non-static requests to cluster
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

This is what I ended up with:

# Check for maintenance file and redirect all requests
RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /system/maintenance.html [L]

# Let apache handle the PHP files
RewriteCond /opt/apps%{REQUEST_FILENAME} !-f
RewriteCond /opt/apps%{REQUEST_FILENAME} !-d
RewriteRule ^/blog/?.*$ /opt/apps/blog/index.php [NC,QSA,L]
RewriteRule ^/blog/?(.*)$ /opt/apps/blog/$1 [NC,QSA,L]

# Rewrite rule for Rails static assets
RewriteRule "^/(images|stylesheets|javascripts)/?(.*)" "$0" [NC,QSA,L]

# Rewrite index to check for static
RewriteRule ^/$ /index.html [QSA]

# Rewrite to check for Rails cached page
RewriteRule ^([^.]+)$ $1.html [QSA]

# Redirect all non-static requests to cluster
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

The problem with Ilya’s is that it rewrites everything to a physical file, but when Wordpress is setup to use slugs, this will fail because the physical file doesn’t exist. If the file doesn’t exist, you need to rewrite the url to index.php.

For grins, I also added a line to let Apache handle Rails cached files, images, stylesheets, and javascripts because Mongrel is not that great at delivering static assets.

I’m still a little new to Apache configs, so if someone has a better way to handle this, I’m all ears.

Windbelt - Third World Power - Wind Generator - Video - Breakthrough Awards - Popular Mechanic

I love it when people take something simple and make it useful.  Turning this macro will be a trick, but it is a neat concept regardless.

Put this down as another one of those “Why didn’t anyone think of this sooner?”