On Thu, 24 Jul 2008 12:21:55 -0600, Milo van der Linden <[EMAIL PROTECTED]> wrote:
> - From your comments, I can tell that you have arrived at the right > party! Nice! Are there any party hats left? ;-) > You are hitting target on the perspective of cherokee that interests me > the most too: getting cherokee "in the spotlight" I can help with that. But when I do I want to be sure it's done at a time in which the project has the proper front facing pieces in place such that all I need to do is point people to the site to then let the site speak for itself. Ultimately it's the software that needs to speak for itself, but we all know that isn't the problem. The software speaks. People just need to be sold on trying it out. > I agree mostly, knowing where people visit, how they enter and how long > they stay is only useful to enhance the website content. So I will give > it low priority. I wouldn't really see it as a low priority, and instead as a refinement tool which you use to fine-tune the edges. Kind of like a Disney artist (okay, a Disney artist from the days when they actually drew the animations by hand. ;-)) who sketches out the entire scene before going back and perfecting the edges in post-production work. > I have a virtual machine ready with the latest svn cherokee, lighttpd > and apache to rerun the benchmarks. I am only waiting for the 0.8.0 to > reach stable. Then I hope the new benchmarks will find their way to the > website. I have automated the installation script for > cherokee/apache/lighttpd. It can be re-run with every new release ;-) > Hope that partially answers one of the questions. That helps *tons*! In fact, I would make benchmarking a standard part of an automated build process. You might be amazed at how much info can be gleaned from a benchmark report sent to you at regular intervals. Some of the best improvements to software are made by accident, or, in other words, there are times when you wouldn't have realized that a simple change in a particular revision had drastic effects on performance (both +/- effects.) By benchmarking at regular intervals via an automated build and test framework it's easy to look back and see where something when both right and/or wrong regardless of whether it was intended or accidental. > Thanks! That is indeed my goal. Great! > Would it be good to focus on: > 1- remove dead links Yes. It's simple enough to write a script to crawl your site each day looking for 4xx and 5xx error codes to both internal and external pages. It might even be worth appending a web archive link to the end of each external link (e.g. <a href="http://some.external/link";>foo</a> [<a href="http://webarchive.org/.../http://some.external/link";>cached</a>] Take a look at what we did with the Codev2.cc site as an example > http://codev2.cc/links/ > 2- structure content and documentation I think the site itself looks great and is well structured. It just needs more content, and in particular documentation. Apache is so well documented it's sickening. Lighty not quite as much, but still pretty good. Cherokee needs serious attention in this area. I am willing to help out here and there when I am able, but at present time I am working on a new title for O'Reilly so my time is limited until that project begins to slow down in September. > 3- when 0.8.0 launches: put benchmark online, Put them online as soon as possible. If you can get an automated build and test process in place, I would make the results of those tests available in a prominent location on the site. And make them easy to navigate between. See: http://status.aws.amazon.com/ < as a "Drop Dead *GORGEOUS*" example. > 4- Inform the (online)press of the launch? This should become a standard part of *every* release. I'll definitely take the lead on promoting the project through O'Reilly, but there's obviously a lot a media outlets out there that have interest in this space. I would add a "News" link to the top that links to a news summary page with an Atom/RSS feed. I would also add a column on the left or right of that page which you can easily add links to external articles and blog posts. Emphasizing the benchmarks stuff from above, I would spend considerable time creating a nice looking, bullet-proof portfolio of benchmarks that anyone, anywhere can easily verify for themselves. In fact, I would create a specific EC2 AMI that has Apache, lighty, Cherokee, the free LiteSpeed, Mongrel, nginx, etc. completely setup and ready with a script that starts and stops each web server while invoking the benchmark systematically against each one of them. This portfolio should be separate from any daily automated benchmarking pages. Those benchmarks will contain info that isn't interesting to people who simply want to know the bottom line: How fast is fast? So creating a separate eye candy version that is provided with each new release, with links to the original eye scratching output, would be an effective approach. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: [EMAIL PROTECTED] | [EMAIL PROTECTED] Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 | http://news.oreilly.com/m-david-peterson/ _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
