Archive by Author

Super-handy new premium feature: Access via email

21 Aug

Here’s a great new feature especially handy for our businesses, education, and government users: Access-via-email lets you set an email domain, and anyone with an email under that domain can grant themselves Contributor access to your wiki. An example will make this a lot more obvious – here at PBwiki we run a bunch of internal wikis and this feature makes it easy to set up self-service — no more “hey, what’s the password for that wiki?” with new employees and new wikis. I set ‘’ in the ‘Access via email’ section of the wiki settings and now anyone on the PBwiki team can let themselves in using their address. Easy!


The “Access via email” feature is available for all Silver, Gold, and Platinum wikis (it depends on the wiki being configured with a Contributor user level).

New feature for premium wikis: Accelerated access and search

8 Aug

The PBwiki team is on our annual office offsite, and we’ve been spending lots of quality time together brainstorming about new product possibilities, ways to make PBwiki more useful to our users, and how to make PBwiki the obvious answer for your online collaborative needs. In addition to the longer-term strategic planning and such, we’ve also been doing some late-night hacking of ‘hey, you know what would be cool…’ features and enhancements — ideas we’ve had in our heads for a while but weren’t fleshed-out enough for prime-time or didn’t fit into the development schedule.

Tonight we’ve deployed the results of some kung-fu from last night, a new feature for premium wikis. All of your wiki’s pages are stored in memory, ready for display to you and to search through. While we’ve got a super-efficient distributed file storage for every page revision and attachment (millions!), it’s still on disks on remote machines. We’re restricting this to paying customers because it consumes by far the most expensive resource on our servers, RAM. There’s no downside for non-premium wikis and we’re not making them any slower. As we build out our server hardware we’ll make sure we have enough RAM to accommodate all of the premium wikis this way in addition to our normal caching mechanisms.

The result: Pages on premium wikis load 10-40% faster depending on size, and searches are up to 10 times faster. We’re pretty happy with the new speed boost, and think you will be too.

PBwiki = paintball wiki

7 Aug

The PBwiki team is Colorado for our annual offsite this week, and on top of a bunch of regular work we’re doing a couple of great activities — here’s some photos from our paintball session this morning.

Continue reading

PBwiki versus the speed of light

27 Jul

Here’s some timing data for a simple request to one of our development servers.

  1 ms - server A (San Francisco) -> server A (San Francisco)
  7 ms - server B (San Jose) -> server A (San Francisco)
 55 ms - PBwiki office (DSL + Ethernet, San Bruno) -> server A (San Francisco)
137 ms - PBwiki office (DSL + WiFi, San Bruno) -> server A (San Francisco)

Here’s something I hadn’t really put my head around before: The convenience of using WiFi comes at a huge cost — it adds 80 ms to an otherwise identical request.

Hmm. What this data says is that no matter how fast we make our servers, and no matter how efficiently we tune our code, the speed of light and other things we don’t really have control over (like that 48ms of ‘DSL stinks’ penalty) are major factors for your perception of PBwiki’s speed and overall ‘snappiness’. Let’s say wiki pages take 80ms to generate instead of the trivial test above that took 1ms. Let’s say we optimize our in-memory caching, then tune some other things and end up shaving 10% off of that, down to 72ms. An end user with DSL and WiFi would see their 220ms round trip time go down to 212ms — less than 4% improvement, and that’s assuming they’re right here in the Bay Area, which most of you aren’t.

That 80ms WiFi penalty is coincidentally about the same lag you get for being on the East Coast when accessing anybody’s servers in San Francisco. That’s one of a number of reasons we’re drawing up plans for an additional data center, likely in Virginia. We have a lot of users in New York and Washington DC in particular. That east coast presence will go a long way to improve the browsing experience for our European users as well, and as demand grows and revenues permit we’ll be bringing on a Continental data center, too. We’re working hard behind the scenes to make your wiki experience better.

Unicode support in PDF output

20 Jul

It’s been on our to-do list for a long time but now it’s good enough for general use — our PDF export feature now supports more interesting characters such as what you’d find, oh, anywhere in the world other than the US. We’ve also thrown in image embedding and some basic support for tables and hyperlinks. It turns out the PDF standard is pretty hard to do well, and we’ve been gnawing away at this matter for months. (Aside: guess what an ‘Acrobat error 135 is’ — we had to, it’s not documented) In order to fully support the kinds of html you can (and have) put in your wikis we’d have to basically rewrite the layout and printing engines of a web browser, and we’re not really equipped to do that right now. What we’ve come up with is a good balance between utility and scope — making it incrementally more capable would require a pretty substantial rework.

Statshot — PBwiki by the numbers

6 Jul

I’ve been running some internal stats on the various activity levels across the PBwiki landscape. This set of numbers breaks categories down by volume of activity rather than unique users.

How much activity on private versus public wikis?

Around 2/3 of our activity is on private wikis. Takeaway: Our users have found lots of uses for PBwiki that we don’t know about, and we’d love to hear your stories.

How much activity on free versus premium wikis?

More than 16% of user activity is on premium wikis. Takeaway: Lots of people are taking advantage of our great premium features and enhanced security. Yay!

How much activity among major browser families?

Around 56% IE, 39% Firefox, 5% Safari, <1% everybody else.

How much activity over SSL versus unencrypted?

5.5% of our activity is over end-to-end SSL, which is available for our Platinum and custom SMB and business packages. Lots of companies trust PBwiki with their most sensitive documents.

No loafing at the PBwiki HQ

6 Jul

And Fridays are very serious.


Apparently some kid by our local Vietnamese place was making balloon … pbj sandwiches. They’re not usually that chewy.

Hard drives – a proper sendoff

3 Jul

These drives we’ve pulled from some old servers are about to head to the big drill press in the sky (i.e. destroying them and the data on them) but I’m kinda obsessive-compulsive so I had to sort them into piles by model. Horray, order!


We do [not] like spam

31 May

As part of our spam abatement we’ve been doing some research about how to identify various kinds of Spam. The following data is from our test of Spam musubi. Initial results are promising.


Brief PBwiki outage

24 Apr

We and the rest of the world were unable to access our San Jose data center for a few minutes this evening (around 5pm PST) — apparently somebody bumped the wrong fiber optic cable. Your wiki’s data was completely safe and most users were able to access their wikis at all times.

We’ve discovered a subtle case which could cause those wikis with a tabbed sidebar to be unavailable or to load very slowly during this outage. It’s been fixed in our version control system already, and won’t happen again. We’re taking other measures now to ensure we’re able to better tolerate this kind of rare network problem.

Thanks for your patience, and thanks for using PBwiki!