Comments for Dusty's Diverse Domain

Comment on Trembling Aspen by Chad Whitacre

Chad Whitacre — Fri, 06 Apr 2012 16:16:01 +0000

In 0.14.3, I refactored aspen.tests into an aspen.testing module and a separate tests/ directory (for Aspen’s own tests). The aspen.testing library isn’t super-helpful for testing downstream websites, but there’s room to grow now.

https://github.com/whit537/aspen/commit/3b6936d06046f343b4e23532afb08fbd533ab1a5

Also, I tweaked the docs (in 0.14.4) for request to make redirect clearer and document allow as well:

http://aspen.io/request/

Comment on Add prominent links to your project in your project’s documentation by Chad Whitacre

Chad Whitacre — Thu, 05 Apr 2012 17:25:49 +0000

I trust Aspen wasn’t one of the projects in question?

Comment on Trembling Aspen by Chad Whitacre

Chad Whitacre — Thu, 05 Apr 2012 17:17:11 +0000

Thanks for the review, Dusty! There’s a lot of room for improvement, including better testing support like you mention, but if the foundation is solid I trust these will come along in their own time. Thanks for your work on trembling, for example!

As far as scaling goes, it’s going to depend on your application and the underlying engine you use (Aspen bundles CherryPy’s WSGI server and includes shims for eight others, in addition to the inverted gunicorn option). Aspen compiles simplates to code objects and compiled templates so the request-time overhead is “not too bad.” Here’s a benchmark comparison from a couple years ago in which Aspen and CherryPy fare favorably:

http://nichol.as/benchmark-of-python-web-servers

It would be interesting to see some more modern benchmarks.

P.S. There is a request.redirect method, but it kind of gets lost in the docs currently: http://aspen.io/request/

Comment on Contributing to git projects on github by dusty

dusty — Wed, 28 Mar 2012 15:03:11 +0000

That’s correct. I have altered the explanation a bit. Sometimes you may have to git checkout upstream/some_branch. If you do this, you have checked out a commit on your local repository that is not attached to a branch. You can then attach it to a local branch using git branch some_branch.

Comment on Contributing to git projects on github by Chad Whitacre

Chad Whitacre — Wed, 28 Mar 2012 14:38:32 +0000

I think I get it now. The development_branch_name is a branch that exists in the other person’s repository (as well as mine). The working_branch_name is a branch unique to my repository. Do I have that right?

Comment on Contributing to git projects on github by Chad Whitacre

Chad Whitacre — Wed, 28 Mar 2012 14:32:06 +0000

I’m confused by steps 4 and 5. What’s the difference between a development branch and a working branch?

Also, on step 4 I get:

$ git checkout packaging_fix
error: pathspec ‘packaging_fix’ did not match any file(s) known to git.

I worked around this like so:

$ git branch packaging_fix
$ git branch
* master
packaging_fix
$ git checkout packaging_fix
Switched to branch ‘packaging_fix’
$ git branch
master
* packaging_fix
$

Comment on Why we need Python in the Browser by joe

joe — Tue, 20 Mar 2012 21:33:40 +0000

“more important tasks”

This is a value judgement, and clearly many people place python in the browser as a very important task.

Comment on Contributing to git projects on github by Berry Phillips

Berry Phillips — Mon, 19 Mar 2012 17:02:10 +0000

You need unit tests for your blog

Comment on Contributing to git projects on github by dusty

dusty — Mon, 19 Mar 2012 16:20:21 +0000

Too true. This is what I get for testing out of band.

Comment on Contributing to git projects on github by Daniel Hofstetter

Daniel Hofstetter — Mon, 19 Mar 2012 15:43:52 +0000

#2 & #3: the url of github is github.com, not github.org