« July 2008 | Main | September 2008 »
August 26, 2008
P3P and Internet Explorer
If your Web service does anything that sets cookies, you'll probably bump up against the fact that Internet Explorer--since version 6--has implemented a fairly strict privacy policy regarding cookies. In a nutshell, if the site does not have the right P3P privacy policy, first-party cookies (i.e. from the site itself) are downgraded to session cookies and not stored in between browser sessions and third party cookies (i.e. from another site) are rejected completely. Here's what to do to solve this problem.
P3P, or the Platform for Privacy Preferences is a W3C "protocol allowing websites to declare their intended use of information they collect about browsing users." In IE 6 and 7, users can use a slider bar to set their desired degree of privacy and then IE will automatically check the privacy policy of the sites they visit and "protect" them according to their preferences. The default setting (medium-high, which most people never change) gives the behavior I describe above.
Deploying a P3P policy actually isn't very hard. There are some great tools for creating the policy itself. But it can be difficult to know exactly what to do. I followed these instructions but still have a few questions, so I'll document exactly what I did below.
The first step is to create the policy. I used IBM's P3P policy editor. It's a Java program, so it will run most anywhere. Using the tool takes a little work since it's not clear at first what you're editing. Create your policy from a template if you can since that will save a lot of decisions later. Once you've done that, select Policy->Policy Properties and fill in the information about your service and organization. If you look at the errors, you see that you have to fill just about everything in. Make sure you add a "privacy seal" even if it's just a notice that your customer service department can answer questions.
The policy itself is in the "groups" on the right. Double click each one and make sure you agree with what it says. Clicking on "Errors" will show you things left undone and clicking on "HTML Policy" will show you the human readable version of what you're creating. At the bottom it provides an analysis of how this policy will play in IE. Very helpful.
When you're done and there are no errors, you need to save four things:
- The policy itself as name.xml where name is the name you selected under "Web Sites" in the Policy Properties pane. You will likely have just one, but you can have many covering different parts of your site.
- A policy reference file as p3p.xml. This file provides discovery services for the policies. Whether you have one or many policies for your site, this file tells programs which policy applies where and how to find them
- A human readable policy
- A compact policy. This is a string of three and four letter acronyms that specify the policy in a compact manner.
Put the first two in http://yoursite.com/w3c/... Put the third in whatever URL you specified the human readable policy would be referenced by.
The compact policy is used in the HTTP headers that your server returns for ant HTTP request. This gets rid of one or more round trips to the server to request the XML version of the policy. In my experience, this was a necessary step to get IE to recognize the policy.
Having Apache return the compact policy in the header requires building and installing the mod_header module. I'd already done that so I simply added this line to my HTTP configuration file:
Header append P3P "CP=\"NOI DSP ADMo DEVo TAIo ... DEM STA\""
Once you've got all this installed, you should be able to open IE, double click on the eyeball with the red slash through it in the status bar and confirm that your cookies are no longer blocked. If there are no blocked cookies, the eyeball is not there at all.
That's it from a technology standpoint. The trickier part is deciding whether you can actually live with the restrictions you'll need to put in place to let IE store your cookies.
The whole thing feels like a waste of time. Your product won't be better and most people won't be any more protected when your done. But you need to do it in an IE world.
1:14 PM | Comments () | Recommend This | Print This
August 21, 2008
Starting a High Tech Business: Sell Before You're Ready
I'm starting a new business called Kynetx. As I go through some of the things I do, I'm planning to blog them. The whole series will be here. This is the fifteenth installment. You may find my efforts instructive. Or you may know a better way---if so, please let me know!
One of the things that ought to strike fear into any technologist's heart is getting your first customer. You've spent months building a product you hope people will buy and find useful and suddenly someone actually is putting their faith in you and your baby.
You're happy, of course. But most of all, you're scared. What if something doesn't work? What if it doesn't scale? What about feature A, B, and Z that we haven't built yet? What about the shortcuts you took here and there to get it done? What about...
I've done this a couple of times now and I'm convinced of two things: (1) you're going to sell your service before you're ready and (2) you should have sold it even earlier.
We're at that stage with Kynetx. We've signed up several good pilot customers and we're actively courting the indirect sales channel. These are sharp, demanding folk with good ideas and little time to waste. That scares me.
Don't get me wrong. I've never built a product or service that has been more ready to scale and that I'm as confident works as promised. We've spent months automating infrastructure. I've written thousands of tests. Still, it's scary. If you asked me, I'd take another couple of months. Of course, at that point, I'd still take another couple of months. You're never ready.
That leads nicely to my second point. Since you're never ready, you might as well start selling even earlier. There are big advantages to having real people kick the tires and give you feedback. The product becomes better faster through that process than anything else you can do. And you invariably plug some of the holes that have crept into things.
But wait. There's more. The best part of selling your product early is that it helps you understand what you do and how you're different from your competitors. These are two key pieces of information when you're going out to raise money.
You may think that it's weird that you could start a company and not know what you do, but in fact it's quite common. Oh, you know what you do on many levels, but telling other people about it can present some challenges. In an earlier post in this series I wrote about finding your story. Same idea.
When you start to tell others about your product or service, they invariably try to understand you by comparison. "Oh, so you're just like [insert company name here]" or "Oh, so you're a [insert product category here]." Often these are the very companies or categories you're trying to distinguish yourself from. You need to understand how your different in ways that you can easily explain.
Going through some VC meetings and pitching events helped us refine our story, but we're reached a whole different level talking about what we do with clients. They're usually more willing share, explore, and engage in a dialogue than VCs who typically hold their cards very close to their vest.
Clients aren't as interested in comparing as VCs because they don't care as much who you're like. They're not trying to find the next category killer. They just want to solve a problem and if your nail will secure their board, then they're game.
Besides, I don't know about you, but in client meetings I'm a whole lot more relaxed than I am in a VC pitch. I'm in my element--showing off the things I'm most passionate about right now. Clients usually want to see what you have and our demo usually wows people. VCs never want to see a demo.
As a consequence of all this, I wish we'd been positioned to start selling well before we started raising money. Unfortunately, because of various timing issues and our own understanding, things didn't work out that way. If I do this again, I'll start selling much earlier.
5:01 PM | Comments () | Recommend This | Print This
August 20, 2008
Anti-Perl Social Engineering
Dave Cross has a piece on why corporations hate Perl. He's being a little hyperbolic (as he admits)--not everyone hates Perl, but he's right in noting that there is a backlash against it. He says:
I was talking to people from one such company last night. The Powers That Be at this company have announced that Perl is no longer their language of choice for web systems and that over time (probably a lot of time) systems will be rewritten in a combination of Java and PHP. Management have started to refer to Perl-based systems as "legacy" and to generally disparage it. This attitude has seeped through to non-technical business users who have started to worry if developers mention a system that is written in Perl. Business users, of course, don't want nasty old, broken Perl code. They want the shiny new technologies.
And so, in a matter of months, the technical managers at this company have create a business environment where Perl is seen as the cause of most of the problems with the current systems. It's an impressive piece of social engineering
From Why Corporates Hate Perl - O'Reilly ONLamp Blog
Referenced Wed Aug 20 2008 10:43:00 GMT-0600 (MDT)
He labels this kind of things "anti-Perl social engineering." I've run into similar feelings.
At Kynetx, our systems are built in Perl and Ruby. We use Rails to create the user facing pieces, but the engine, that part that needs to run fast, is written as an Apache module in Perl.
I've noticed that when I explain the language choice to people I almost always have to answer the spoken or unspoken question: "Perl?? Really? Why Perl?" After I explain the architecture and the reasons behind the decision, they're almost always satisfied, but there's a definite stigma.
I'm doing a talk next week at the Utah Open Source Conference (Friday morning at 10am) on using Apache as an application server. There are some significant advantages and Apache offers some real great application support that is largely untapped. But to talk advantage of it, you're pretty much stuck with C...or Perl. Given that choice the decision is a no-brainer. I'll be putting my thoughts together for the talk later this week or next week and promise to blog the ideas.
Still, the idea that Perl is an old crusty language couldn't be more wrong. I've been programming in Perl for nigh on 15 years now and I don't think it's ever been more interesting. Perl sports the best collection of libraries of any dynamic language and supports modern engineering practices like modules, objects, and testing. I've seen ugly Perl code--heck I've written it--but that's not Perl's fault.
I spoke with a local company last week that has been a Perl shop but is moving to Java. I smiled because I know that means there will be a lot of unhappy Perl programmers there who I can hire later! :-)
I'll continue to proudly carry the torch for Perl.
11:13 AM | Comments () | Recommend This | Print This
CTO Breakfast Next Week in Conjunction with UTOSC
We'll be holding the CTO Breakfast next week on Thursday at 8am in conjunction with the 2008 Utah Open Source Conference. You don't have to be going to the conference to attend the breakfast, but I do have discount codes available for CTO Breakfast attendees. Contact me if you're like one.
The Utah Open Source Conference 2008 will be held at the Salt Lake Community College, Redwood Road campus from August 28 - 30, 2008. We'll be meeting in rooms 221/223 of the Student Center (SC) at the Salt Lake Community College (Redwood Road campus). Here's a map that shows where to park. There is food on campus near where we'll be meeting so you can pick up breakfast.
Even though the venue is different, we'll be doing the same thing: talking about cool technology, building high-tech companies, and what's hot. Come join us.
Here's the schedule for the next several meetings:
- August 28 at UTOSC
- Sept 26 (Friday)
- Oct 30 (Thursday)
- Dec 5 (Friday) - Combined Nov and Dec breakfast
Please mark your calendars.
Remember that you don't have to be a CTO to come. Anyone interested in product development in high tech is welcome.
9:46 AM | Comments () | Recommend This | Print This
August 15, 2008
The Run to Ubiquity
Craig Burton has written a nice essay on why software infrastructure behaves differently, economically speaking, than other products and why that upsets the natural inclination most people have relative to protectionism. That, of course, is what the whole net neutrality debate is about.
As Craig says, artificially disrupting the "run to ubiquity" in the software infrastructure on which we all depend, disrupts all players: all
So here is my point about the inverted supply and demand model; today's core software infrastructure is made up of a core set of services. Roughly, file, print, web, database, directory, security, and the Internet protocol suite. Anything that artificially restricts the growth of this infrastructure compounds growth limitation on almost all technology across the board.From Ruminations of a Software Man
Referenced Fri Aug 15 2008 09:48:23 GMT-0600 (MDT)
9:45 AM | Comments () | Recommend This | Print This
August 14, 2008
The TechCrunch 50 Mosh Pit: Is It Worth It?
We were notified that Kynetx will not be one of the TechCrunch 50. Ah well... The rejection notice said this:
We are sorry to let you know that your company was not selected as a finalist for the TechCrunch50 conference. As you know, we are only able to select a very, very small percentage of the more than 1,000 outstanding applications we receive.
Your company was among a select set of candidates that we considered, and it was a difficult decision driven purely by the limited number of presentation slots. Since we regarded your business so highly, we want to make sure you still get the opportunity to participate in the conference in our DemoPit.
As a DemoPit company, you will have the opportunity to be nominated for the People's Choice award and win the 50th spot on the TechCrunch50 main stage. As the 50th company to present, the People's Choice award winner will be able to compete for the $50,000 TechCrunch50 award. Act fast, as spaces are very limited and first come, first served.
Additionally, all DemoPit companies will benefit from the exposure generated by media attending the event. We do anticipate having approximately 300 members of the international press in attendance.
Participating in the DemoPit costs $3000, a not insignificant sum for our early stage start up. My question is "is it worth it?" Any wisdom out there?
1:58 PM | Comments () | Recommend This | Print This
Namespaces, Twitter, Identi.ca, and Federation
A few days ago I wrote about federating with Identi.ca. Yesterday I had a great chat with Craig Burton about that whole idea. He's not buying. I asked him to respond on his blog so we could move the discussion online.
My argument was essentially that moving Twitter-like functionality onto a distributed platform was a good thing and likely to make more people comfortable with the idea of building out additional functionality in the micro-blogging space (what people have started to call the space that Twitter is in). The fly in the ointment, from my perspective, is the additional friction engendered by the need to subscribe to people on federating systems. Much harder than clicking "follow" on the Twitter page.
Craig's argument is that the advantages of a single namespace are so huge that the friction I mention is a deal-killer. He goes on:
With all of the downsides of Twitter, I still love it. Why? Because it has the big names already in it! Don't you get that?
I chortle at my cohorts--- @stevegillmor and @jessestay (twitter names) that are bad mouthing twitter and claiming that somehow other systems are better from some tech reason or another. The big names are already in Twitter. Ample reason to stay and stick out the growing pains.
From Federated Twitter Look alikes---Ho Hum
Referenced Thu Aug 14 2008 13:07:08 GMT-0600 (MDT)
Craig's got a point that goes beyond what I was considering. The namespace issue and the friction of subscription collide in unpleasant ways. But as I thought about it, I realized that with Laconi.ca based systems, URLs are the namespace. Laconi.ca, and hence Identi.ca, don't create a private namespace. That's why federation works.
So, the friction that subscription creates might the death of these federated systems. Or it might be it's salvation. Things like the gateway that WebDevStudios' put up to link Twitter and Identi.ca might make the whole discussion moot. Or, it might be something else entirely like the fact that Identi.ca doesn't do SMS.
I'm going to be talking to http://evan.prodromou.name/, the man behind Identi.ca and Laconi.ca on Monday as part of my Technometria podcast. I'm really looking forward to it--this whole thing is really heating up.
1:26 PM | Comments () | Recommend This | Print This
August 12, 2008
Federating with Identi.ca
Twitter's performance problems over the past few months have made people skittish about basing businesses, even ideas, on it. The problem isn't just performance problems, however. When one company controls what many come to consider a key piece of infrastructure (who'd have thought they'd read that about Twitter 18 months ago), it creates a brittle situation. What if they can't perform or go out of business?
Enter Identi.ca, a Twitter-like site that's based on open source software called laconi.ca. The key problem with something like Identi.ca is that if it's just another centralized solution, nothing's changed.
Laconi.ca has the ability to federate different servers so that if I have an account on Identi.ca and you have an account on whojusttweeted.com, I can follow you and you can follow me. Until today, I've understood that in theory, but not in practice.
Jay Ridgeway has put together a short instruction page on how to federate two accounts on different Laconi.ca servers. There are seven, count'em, seven steps. That's a little more involved that most people will put up with, but, as Jay says, it's a start.
It really isn't any more involved than subscribing to an RSS feed and over the years we've discovered ways to make that less painful. Still, I'd argue that part of the lag in uptake of RSS by most people is this complicated subscription process.
I think subscriptions are a great answer to complicated syndication problems--whether it be RSS, tweets, or whatever, but we've failed to make that pattern so precise that systems take the pain out of subscriptions for users.
I think I'll set up a Laconi.ca server and play with this a little. There's something here, I think.
6:57 PM | Comments () | Recommend This | Print This
August 11, 2008
Using a Pre-Commit Hook to Check Puppet Syntax
The whole idea of Puppet is to put your machine configuration scripts in a versioned repository. This is good because I've found that a syntax error on a manifest not even used by the current machine will stop the puppet updates from running. One error anywhere kills the whole thing everywhere. So, being able to back out of a change is good.
We can go one better however and keep people from checking in files that aren't syntactically correct using the pre-commit hook in SVN. If you don't use SVN, your repository probably has something similar.
I followed these instructions for the hook and these instructions for installing it.
I ran into a problem however. The pre-commit script wasn't reporting an error condition correctly. I'm not sure what was wrong. Running the puppet command on the command line and then checking $? gave a "1", but inside the script it wasn't working that way. So, I punted and wrote the error output to a file and checked whether or not the file existed and then just cat'd that out to standard err. Messy, but it worked and I need to go home. Here's the file as modified by me:
#!/bin/bash
# SVN pre-commit hook to check Puppet syntax for .pp files
PATH="/usr/bin:/bin"
REPOS="$1"
TXN="$2"
tmpfile=`mktemp`
errfile=`mktemp`
export HOME=/
SVNLOOK=/usr/bin/svnlook
$SVNLOOK changed -t "$TXN" "$REPOS" | awk '{print $2}' \
| grep '\.pp$' | while read line
do
$SVNLOOK cat -t "$TXN" "$REPOS" "$line" > $tmpfile
if [ $? -ne 0 ]
then
echo "Warning: Failed to checkout $line" >&2
fi
/usr/bin/puppet --color=false --confdir=/tmp \
--vardir=/tmp --parseonly --ignoreimport $tmpfile \
>$errfile 2>/dev/null
if [ -s $errfile ]
then
echo "Puppet syntax error in $line." >&2
cat $errfile >&2
exit 2
fi
done
res=$?
rm -f $tmpfile
rm -f $errfile
if [ $res -ne 0 ]
then
exit $res
fi
Note: you may need to combine lines separated by "\\" into a single line.
This works great. Syntax errors are caught before they make it into the repository. I'm still looking for a good way to thoroughly test puppet scripts before they get into the production servers. If you have any best practices in that area, I'd love to hear about them.
4:57 PM | Comments () | Recommend This | Print This
August 7, 2008
Defining the New Singularity
I'm stil catching up on my IT Conversations listening after being gone on vacation for 10 days. This morning I listened to Mark Rolston's talk from the Emerging Communications conference entitled The New Singularity. Contrary to what you might think from the title, this isn't about "the" Singularity, but rather the idea that we typically have one concept about what a product should and the phone belies that. I really enjoyed the thinking about products and designs. I found myself wishing I could ask a few questions!
10:12 AM | Comments () | Recommend This | Print This
August 5, 2008
Puppet Fun
I'm continuing to explore the use of puppet for managing systems. I'm convinced that it's the best system for managing large groups of interacting servers and keeping them all in sync. For example, today I was trying to figure out why a cronjob that processes log files wasn't working. Turns out that it was a system issue and there was also a problem with mail aliases, so we weren't even finding out.
I create a simple puppet recipe for all our machines that simply ensures crond is running. That's basic and now it's ensured on all our machines. This was simple:
class cron {
service { crond:
ensure => running,
enable => true
}
}
Next I created a manifest to installed the correct crontab entry on the right machines to process the logs along with setting the right environment variables for the processing daemon. There's a cron "type" in puppet so it's pretty easy:
class kobj_log_daemon {
cron { kobj_log_daemon:
command => "bin/kobj_log_daemon -v",
user => www,
hour => 0,
minute => 5,
environment => ["WEBROOT=/www", "MAILTO=root"],
}
}
Finally, I took care of mail aliases by putting /etc/aliases under the control of puppet. Here's the class definition that does that:
class aliases {
file { "/etc/aliases":
mode => 640,
source =>
"puppet://puppet.kobj.net/dist/apps/sendmail/aliases",
owner => "root",
group => "root",
before => Exec["create aliases db"]
}
exec { "new_aliases":
command => "/usr/bin/newaliases",
alias => "create aliases db",
subscribe => File["/etc/aliases"],
refreshonly => true,
}
}
Now there's one place--under version control--where all of this is controlled for every machine we own. Managing this any other way would be a recipe for disaster.