Update: Eric Shepherd already has some great documentation of the new JavaScript error reporting regime up on MDC.
Update: Note also that most errors will be reported by default, so the pref only turns on a few additional cases. Read the MDC article for full details.
I’ve been doing a lot of JavaScript development as part of my work on Prism, and I noticed a few weeks ago that a lot of errors I was used to seeing in the console weren’t showing up anymore. Unsure of the cause, I first took the expedient route of sprinkling my code with dump() statements whenever I had to track down a problem. This is tedious and time-consuming, however, and after a while I got fed up and (with Shaver’s prodding) spent some time trawling through the JS error reporting code trying to figure out what had broken.
Luckily for me, Sergey Yanovich noticed my incessant whinging on IRC and pointed me at bug 393627. It seems that some changes had been made to a JavaScript component that threw an exception that was expected, caught and managed in C++ code. Nonetheless, an error was being displayed in the console by XPConnect, so a patch was committed to suppress reporting of exceptions in these circumstances. Unfortunately this had the side effect of turning off useful and desirable reporting for a huge swath of errors.
A few weeks and 21871 bugs later found us embroiled in a heated discussion in the comments of bug 415498. The problem, it transpires, is a tricky one, as Ben Turner explained:
Ok, so here’s our basic problem: Some folks think that throwing exceptions is a perfectly valid way to communicate with C++, others try to avoid any unhandled exceptions and want to know if any make it back to C++. There is no way to consolidate those opinions, and we’ve argued back and forth about it many times already. A functional Components.resultCode might make this situation better, but that’s been broken for far too long to hope we’ll see it fixed in the next week.
Ben’s solution was to implement a preference, dom.report_all_js_exceptions, that turns on the verbose error reporting so vital to JavaScript developers. So even if you just skimmed the last few paragraphs, please pay attention because if you code in JavaScript in Firefox 3 you want to know this. Grab yourself a recent trunk (Ben says the fix landed last Wednesday or so). Set that preference. Watch your error reporting woes vanish before your eyes. There should be real documentation on this soon, but in the meantime hopefully this information will be of use to some.
TechCrunch is running a guest post of mine about the exciting new field of site-specific browsers. Needless to say, it’s a honor to be on TechCrunch, and I hope my article will help to increase awareness of what SSBs are and why they’re important. Personally I’m convinced that they represent the future of web apps.
I haven’t seen any sign yet of the “gaggles of groupies” that Mike promises in the post’s comments, but I’m sneaking out the back door to pick up a sombrero and some wraparound sunglasses, just in case.
Although AllPeers didn’t produce the kind of outcome that we had hoped for and expected, it’s been a tremendous learning experience. Hopefully others will be able to benefit from what I consider to be the main lessons.
Luck and ambition
Naturally the success of any startup is dependent to some degree on luck, and the luck factor rises in proportion to your ambitions. If your plan is to sell T-shirts online then execution is probably the main consideration. If you make really cool designs, have an easy-to-use website and do good marketing then you’ll probably make money, though you’re unlikely to be buying a private island in the South Pacific any time soon. If, on the other hand, you plan to dethrone Facebook by adding state-of-the-art social features to the fabric of the web, transforming the internet experience of billions of people, you’re going to have to execute to perfection and still get really really lucky if your company is to succeed. Of course, if you make it you’ll be assured a very comfortable early retirement.
Neither of these approaches is inherently wrong but you should be aware of what you’re getting yourself into. If you can’t stand the thought of failure, make sure you’re not tackling a problem that is too big and ambitious. In the case of AllPeers, we knew that there was going to be a lot of luck involved (as there is with any product that relies on network effects and viral adoption), and we were pretty well prepared for the challenges we would face. It is comforting to see failure in this way because we certainly wouldn’t have sacrificed our lofty ambitions to increase our chance of moderate success.
Raise as much as you can
I’m not the first one to say this, but let me express my wholehearted agreement: raise as much as you can, as soon as you can, and not a penny less. In early 2006, before we had released even a private alpha of AllPeers, we suddenly became a minor web star thanks to a couple of white-hot buzzwords (”Firefox” and “BitTorrent”) and a very positive writeup on TechCrunch. (And in fact we owe a great deal to Mike Arrington, who grasped our vision immediately and did a great job of articulating why it was exciting. It’s easy and intellectually lazy to be pessimistic before the fact and snarky afterwards, while it takes courage to go out on a limb and predict success.) We believed our own hype a bit too much, unfortunately, and didn’t take advantage of the opportunity to raise a lot of cash at a high valuation. Instead we brought in a very modest amount under the assumption that we’d be in a great position in a few short months to close a much bigger round.
As a result, we were under constant pressure to get user numbers up so we could raise more money. This isn’t the way to run a company, particularly one with an ambitious technological vision. We ended up making a string of tactical moves rather than taking a step back and looking at the big picture. As a consequence, we ran out of money before we could get the product to where it needed to be. Don’t make this mistake.
This shouldn’t be construed as a criticism of Mangrove Capital Partners, who led our series A investment round. They are a fantastic group of individuals whom I wouldn’t hesitate to recommend to any entrepreneur seeking funding, and a classic example of a VC who really does offer much more than money to a budding startup (something they all claim to do). But only a company’s founder has a single-minded focus on the company’s success, and this includes acquiring a war chest to deal with unforeseen contingencies.
It is with deep regret that we inform our users, friends and fans that we will be shutting down the AllPeers service today. We are tremendously proud of the product that our team has built, and we remain convinced of the potential of adding social features like file sharing to the web browser. However, we have not achieved the kind of growth in our user base that our investors were expecting, and as a result we are not able to continue operating the service.
The past few years have been an incredible adventure for us. We would like to thank all of the amazing people who have helped us along the way. This includes countless users who provided us with valuable feedback about how to improve our product; the Mozilla community, who has proven to us that “community” is more than just a word when it comes to open source software; the many volunteers who spent hours translating each AllPeers version into fifteen different languages to make it available to non-English speakers across the world; and the friends and family who have supported us as we pursued what undoubtedly seemed like a crazy dream.
Being an entrepreneur is the most rewarding and exhilarating job we can imagine. Being able to build on a vision you have one morning and watch as it grows into reality is quite an experience. Seeing people get excited by what you are building is incredibly gratifying. The praise, devotion and even harsh criticism of the user community is what keeps you going despite long working hours, frequent stress and periods of uncertainty.
When we started working on AllPeers, we knew that it was an ambitious project with no guarantee of success. Such is the nature of any software startup. Sometimes it works, sometimes it doesn’t. Although we are deeply disappointed with the way this adventure has ended, we hope that fear of failure will never prevent us from daring to act on our inspiration.
We have met many many new friends thanks to AllPeers (you know who you are). This is a fantastic silver lining that gives us great comfort. We hope you will stay in touch as we move on to new pastures.
The success of this blog has also been one of the best experiences to come out of AllPeers. We will continue to operate it under the “Peer Pressure” name, posting our random thoughts about the web, the software industry, the evolution of media and whatever else strikes our fancy. We hope you’ll keep on reading. Matt will also continue writing his Just Browsing blog with a focus on web browsers and browser technology.
You haven’t heard the last from us. See you in our next life!
Honza Odvárko, our user interface developer extraordinaire, has been doing some work on the excellent Firebug extension. He’s published the first two parts of a tutorial on extending Firebug on his new blog: Software is Hard (part one and part two). Anyone interested in developing and debugging web applications should check it out.
You think you’ve put it all behind you, but one tiny script and you tumble off the wagon. Such is the fate of the Greasemonkey addict. Someone mentioned yesterday that MXR search results should include a link to CVS Blame. (Regular readers of this blog are used to ignoring me when they don’t know what I’m talking about, right?) Rumor has it that real support for this is in the works, but I went ahead and wrote a script, just because I could. After all, the hallmarks of a good Greasemonkey script are quick-and-dirty hacks and planned obsolescence, and this one emphatically has both:
// ==UserScript==
// @name Add MXR blame links
// @namespace http://justdiscourse.com
// @description Add links to CVS Blame to MXR search results
// @include http://mxr.mozilla.org/*search?string*
// ==/UserScript==
var results = document.getElementsByTagName("ul");
for (var i = 0; i < results.length; i++) {
var ul = results[i];
var anchor = ul.previousSibling.previousSibling;
var span = document.createElement("span");
var blame = document.createElement("a");
blame.href = "http://bonsai.mozilla.org/cvsblame.cgi?&file=/mozilla"
+ anchor.href.substring(anchor.href.indexOf("/source")+7);
blame.appendChild(document.createTextNode("blame annotations"));
span.appendChild(document.createTextNode(" (View "));
span.appendChild(blame);
span.appendChild(document.createTextNode(")"));
ul.parentNode.insertBefore(span, ul);
}
Click here to install (Greasemonkey required).
It’s incredibly empowering to have this kind of client-side control over your browsing experience. One of these days someone is going to do this right and it’ll take over the world.
It’s a minor thing, to be sure, but it’s always irked me that Bugzilla defaults the platform and OS for a new bug to those of the reporter. This makes sense for bugs from “normal users” since it’s important to know where the bug occurred, but for the most part I file generic bugs or enhancements requests. So the first thing I have to do every time I file a new bug is to set those two fields manually to “All”. This takes me about five seconds, so if I file a bug a day (on average) that could be as many as 25 minutes a year. Twenty-five minutes that I could have spent taking movie quizzes on Facebook! This is unacceptable.
I asked around, and apparently fixing the problem is hard for some reason. Just now it dawned on me that I could take matters into my own hands. I used to be a Greasemonkey maniac, and I wrote a few pretty complex scripts back in the day. (None of these work anymore, I’m sure, due to changes in the associated websites, Firefox and Greasemonkey itself, but perusing the source code will bring you hours of enjoyment.) Wikiproxy and Bloglines Sidebar Squeezer even made it into Mark Pilgrim’s Greasemonkey Hacks.
Anyway, here’s the script I wrote to fix the Bugzilla nit:
// ==UserScript==
// @name Bugzilla Platform Defaults
// @namespace http://justdiscourse.com
// @description Changes the default platform and OS to ALL
// when filing a new bug
// @include https://bugzilla.mozilla.org/enter_bug.cgi*
// ==/UserScript==
resetDropDownList("//select[@name='rep_platform']");
resetDropDownList("//select[@name='op_sys']");
function resetDropDownList(xpath) {
var dropdown = document.evaluate(xpath, document, null, 9, null).
singleNodeValue;
dropdown.selectedIndex = 0;
}
Click here to give it a spin. (You must have Greasemonkey installed.)
Since Internet slang coinages based on “phishing” are apparently in vogue, I decided to try my hand at it. Whishing: “Posting an indirect comment about some problem you’re having on IRC in the hope that someone will chime in and help you without you asking directly.”
Examples:
plasticmillion wonders why he’s getting strange linker errors when building Spidermonkey on the latest trunk
plasticmillion can’t remember where he put his car keys
plasticmillion could sure go for a pizza
etc.
Tristan Nitot wrote up a good description of the open-source free-for-all that is FOSDEM. I’m still not a proper open source person (though I’m getting better at Unix shell scripting, which probably means I’m on the verge of shedding any lingering capitalist bent), and at the last two FOSDEMs I didn’t go to many (any?) of the general sessions. But this, after all, is the big European Mozilla bash, and that’s more than enough reason to make the trip. I’m sure that, like last year, some of my AllPeers colleagues will come along as well.
I first met John Lilly in late 2005 when I stopped by the Mozilla offices in Mountain View for an informal “getting to know you” meeting. His title at the time was Vice President of Business Development. My next interaction with John was in February 2007, by which time he was Mozilla’s Chief Operating Officer. Yesterday, Mitchell Baker announced that she was officially handing him the keys to the corner office and giving him the CEO title. I think I can sense the way the wind is blowing, so let me be the first to say: John Lilly for President in 2008!
Read the rest…
When I started this blog in August 2004, I claimed that my main motivation was to learn about blogging as part of my broader investigation into the present and future of social software. I’ve certainly achieved that and a whole lot more over the past three years. I’ve met a lot of well-informed, articulate and opinionated people, I’ve developed my views on a broad range of topics and, more than anything perhaps, I’ve effectively taken a crash course in grassroots marketing. Budding marketers take note: you’ll find out more by starting a blog and trying to get noticed than any school could teach you.
But I’m the kind of person who gets bored if he doesn’t feel like he’s moving forward (insert shark cliché here), and lately I’ve been thinking about how to take my blogging activities to the next level. Peer Pressure is all over the map, serving as it does as the official AllPeers blog, a receptacle for my Mozilla-related posts and a vehicle for my (and Cedric’s) random musings on everything from online identity to paid content. What I want to do, I think, is to get more focused on a specific topic.
The posts that seem to attract the most attention (judging from the number of comments) concern web browsers and browser technology. Luckily that’s also the topic that interests me the most right now. So I’ve set up a new blog specifically on that topic: Just Browsing. Peer Pressure will live on, of course, but with a tighter focus on AllPeers-related posts.
Please take a minute to check out my description of what Just Browsing is all about and my first post. If you have a blog, I’d really appreciate a quick link if you think the content might be of interest to your readers. The hardest thing with a new blog is rising above the noise. Garnering some incoming link love is the best way to do so.
I can’t resist this one. I was already shaking my head in disbelief when prominent Wall Street idiot Henry Blodget pipped the blogging world at the post by publishing what is doubtless the worst idea of 2007 on December 29th. Does anyone still believe the laughable notion that a failed, tired brand has some great intrinsic value? If so, perhaps they should consider for a moment the purchase of the Napster brand by Roxio in 2002 for $5 million. Brands have momentum, and if someone had snapped up the Napster name in its heyday to launch a legal music service, it would doubtless have been worth much, much more. As it transpires, Napster was dead and gone in letter and spirit by the time Roxio bought it, and as of May 2006 the service had lost them a further $175 million. But hey, the Netscape brand has done so much for AOL, right? It takes some serious balls to make this proposal in the face of (nay, as a consequence of) direct proof that it has already resulted in one dismal failure.
His previous bout of Mozilla blathering having presumably resulted in a satisfying bump in traffic, Blodget is back with an even stupider idea: a Mozilla IPO. My issue with the post isn’t that an IPO would be counter to the open source ethos or that it would alienate the all-important Firefox community, although there are strong cases to be made for both of these. I’ve argued in the past that Mozilla would benefit from stronger capitalist motivations. Nor do I dispute his assessment of Mozilla’s value. If anything, $4 billion seems conservative for a company with its assets.
No, the real issue is his total lack of understanding of the Mozilla community ethos. Again, this mind set often frustrates me, but the reality is that Mozilla management would never, ever contemplate an IPO, anymore than they would plaster ads on the Firefox start page to generate more revenue (another of Blodget’s priceless suggestions). It’s more than a bit like suggesting that the Dalai Lama could make a mint by setting up an international “Dalai’s Lama Hut” franchise chain (”buy two tender Bodhisattva Burgers and get a Spiritual Strawberry Shake absolutely free of charge!”). Ain’t gonna happen. Sorry.
Even more to the point: isn’t this totally, utterly illegal? Can a non-profit launch a multibillion dollar IPO? Wouldn’t that amount to tax evasion on a stupendously massive scale? Maybe I’m wrong, but I would have thought that Blodget, supposedly a financial expert, would have at least addressed this.
But then let’s remember why he’s famous in the first place: for jumping on the dot.com hype bandwagon in front of the curve and looking like a genius for a total of, what, two odd years, until it all crashed back to earth around him? Why should we care that he turned out to be completely off target, or that he was then booted off Wall Street for securities-related improprieties? I guess it’s oddly appropriate that in the modern media environment, you can become famous and influential simply for being wrong on a sufficiently heroic scale.
I’ve already received some encouraging feedback to my latest Mozpad post (I’ll be posting a followup soon). Further positive news is that I’ve made good, in a small way at least, on my pledge to devote some time to the Mozpad documentation project.
Having labored to get Prism to build using the Mozilla build system, I was struck by the lack of documentation on this topic for XULRunner developers in general. There’s a blog post by Songbird’s Ben Turner and there’s Dave Townsend’s McCoy project, which is a great practical example of how to do it. But nothing comprehensive on the documentation site.
So I decided to turn my original “Creating Custom Firefox Extensions with the Mozilla Build System” article into a franchise with “Creating XULRunner Apps with the Mozilla Build System”. The article has yet to be reviewed, and to quote Douglas Adams, “it has many omissions and contains much that is apocryphal, or at least wildly inaccurate.” (Unfortunately I didn’t think to adorn it with a prominent “Don’t Panic” label, although this would certainly have been apt.)
Stay tuned for new additions to the series, including “Traditional Chinese Calligraphy with the Mozilla Build System”, “Mastering the Mental Game of Golf with the Mozilla Build System” and the much-anticipated “12 Days to a Flatter Stomach with the Mozilla Build System”.
Mike Shaver asked me about Mozpad the other day, and a few hours later Brian King posed the same question on his blog. Clearly it’s high time to take a step back and evaluate where we are and where we’re going.
The short answer is that not much has happened on the Mozpad front recently. To some degree this is just a case of things taking time. There is definitely ongoing interest in a XULRunner IDE, and ActiveState has brought this a whole whack closer to reality with their Open Komodo initiative. But the initial excitement and momentum has largely dissipated.
I was musing months ago that the group lacked a clear raison d’être. The problem isn’t so much a dearth of things to do, but the commitment and time investment that would be necessary to do them right. This isn’t just a case of setting up some discussion forums for technical support (Mozilla already has them) or an IRC chat room (Mozilla has several) or a great, user-editable documentation site (cause, well, you get the point). Turning XULRunner into a real product with branding, packaging, development tools and marketing is perhaps too big a task for a volunteer organization without any full-time participants. Once folks realized how hard it was going to be to achieve anything substantive without jeopardizing their other projects (including the ones that pay the rent), their initial enthusiasm cooled. I can’t claim to be an exception in this regard.
There are other issues as well. First of all, where are all those XULRunner projects we’ve heard so much about? When we started Mozpad, I was expecting a lot of that XUL dark matter to come out of hiding and express interest in what we were up to. This simply didn’t happen. We got a lot of love from Mozilla die hards who find the idea of an open, multiplatform application development framework appealing, but virtually none from companies that are actually using the technology. It has to be said that Robert O’Callahan’s speculation about “hundreds or even thousands” of stealth XUL projects was based on rather scant evidence. Or perhaps the main interest is in developing intranet applications using a web server and XUL, rather than desktop apps on top of XULRunner. Or, equally plausibly, people are using XULRunner but weren’t aware of Mozpad or were waiting to see concrete results before making their interest known.
Moreover, I have to admit that I’ve cooled somewhat on the idea of XULRunner as a general purpose framework because I’m so excited about the potential of Prism. Since I believe rich web apps are the future, I’d rather spend whatever time I have for Mozilla platform work improving Prism rather than documenting XULRunner APIs and the like. And whereas Mozilla has stated unequivocally that a standalone XULRunner product is not a priority, Prism clearly is. I proposed Mozpad to a large degree because I felt that Mozilla had dropped the ball on the whole “future of apps” thing. Now I’ve got crow casserole heating in the oven as they pick up the ball and sprint for the goal line. (And with that let me pledge publicly: no more ball metaphors in 2007.)
(To be absolutely clear: none of this should be construed in any way as diminishing the heroic work that has been put into making XULRunner a viable platform and getting Firefox to run on top of libxul. Apart from anything else, Prism is a natural consequence of this extraordinary vision, which has been gestating for over three years.)
All this to say that a lot has changed since May, and I’m not sure that we need a Mozpad to further our goal of helping Mozilla to play a defining role in the future of applications. ActiveState has expressed interest in helping out with the development of a XULRunner IDE on top of Open Komodo. All the usual mechanisms are available for those who want to contribute ideas, bug reports and code to the Mozilla platform. Personally I’ve been spending a fair amount of time working on Prism. From my perspective, things are going great despite Mozpad’s lackluster second act.
In part one of this series I lamented Microsoft’s unwillingness to conform to web standards and the stifling effect this has on web innovation. I suggested two possible solutions: a paradigm shift (such as a move towards Rich Internet Applications) that makes it easier to deploy alternate runtimes without having to convince the user to switch browsers, or the use of ActiveX to integrate new web standards into Internet Explorer in spite of Microsoft. Yesterday Opera announced that it was adopting a third approach: sue the bastards.
It’s hard not to feel sympathetic to Opera’s cause. IE boasts a considerable majority of web users not through intrinsic merit but as a direct result of Window’s dominance. Like any market leader, Microsoft has the most to lose from browser interoperability, so it’s dug in its heels and refused to support fully standards such as CSS, JavaScript 2 and HTML 5. The main losers are not just browser vendors like Opera and Mozilla but anyone who uses the web, since much-needed improvement in web application infrastructure is massively hampered when the space’s two ton gorilla (with around 80% market share) refuses to play along.
Nonetheless, Opera’s tactics are problematic. First of all, it’s hard to shake the feeling that the litigation is at least partially a ploy on Opera’s part to garner publicity for its browser. Their CTO, Håkon Wium Lie, categorically denies this, but phrases like the following are bound to raise suspicions:
Opera has long held the position of innovator in the Web browser market, having introduced and pioneered features like tabbed browsing, Speed Dial, integrated search bar, mouse gestures, Opera Link™ and many others.
I have the greatest respect for Opera’s engineering prowess, and Håkon is a brilliant and genuinely nice guy. (Not to mention that he sports a cool little circle over his first name. Where can I get me one of those?) But even if there was no malice intended, it might have been a good idea to tone down the chest-thumping a bit in order to avoid a potential backlash from mean-spirited cynics like yours truly.
More critically, Mary Jo Foley is absolutely correct in pointing out that we don’t want the European Commission deciding what’s a proper web standard and what isn’t. The main web standards consortium, the W3C, doesn’t make real standards at all because it has no official standing. Instead it issues “recommendations”. There is thus no objective basis for deciding which technologies a browser vendor is supposed to support. As frustrating as this can sometimes be, we have to let the market make this determination.
Perhaps Opera will win its case and Microsoft will be forced to offer an IE-free Windows. This wouldn’t bother me one whit. But even were this to come to pass, I’m not sure how much it would accomplish. Both Firefox and Opera are free and could easily be bundled by hardware OEMs today if they felt this would offer them a competitive advantage. In fact, I predicted this would happen back in January 2006, and I’ve been sorely disappointed (for reasons I don’t entirely grasp). Microsoft’s intransigence is undeniably a tough nut to crack, but I’m not sure that litigation is the answer.
|
|
|
