[CentralOH] Sprints - cohpy.org Web Site
eric at intellovations.com
Thu Oct 8 22:31:01 CEST 2009
I think that simple is good and that a static site or static
components is a good first start. I think the key is to get a working
site quickly, keep iterating, while always having a working site.
One other purpose of this project, in addition to the ones I had
listed before, might also be to learn and grow our Python knowledge,
and to collaborate on a Python project (either the website itself or
not). So if that is a goal of the cohpy website, we might consider
areas to carve off in Python :-)...
On Thu, Oct 8, 2009 at 9:19 AM, miles groman <miles.groman at gmail.com> wrote:
> I was going to respond to this list a couple days ago but decided to
> bite my tongue because I felt like I was coming off snarky when I was
> not trying to be.
> On Wed, Oct 7, 2009 at 9:29 PM, Yung-Yu Chen <yungyuc at gmail.com> wrote:
>> What I imagined about the content for the cohpy.org would be mostly static.
>> The name "cohpy.org" sounds like a portal to me, and I guess there won't be
>> frequent changes in cohpy.org. Maybe several updates every months or so.
>> If it is the case, maybe a static site would fit our need, at least
>> initially. No framework, least learning curve, and easy to be maintained.
> I agree with Yung-Yu Chen in that a static site would be best for now.
> What has anyone actually suggested that would warrant the use of a
> framework (yet) ? I am merely trying to be less of a "solution
> looking for a problem" person then I already am.
> Assuming we settle on a static site for now, may I suggest that we use
> an .htaccess file or [ whatever rewrite engine the web server has ] to
> get clean urls.
> As far as something to build on the site, I think it would be cool to
> write some sort of SCM tool. An example of how this might be, after
> Jon gave his Hadoop talk, he could commit his code examples to the
> site for all of cohpy to use. Then, when I got home and wanted to
> check out more about Hadoop, I could check out his code and hit the
> ground running. The major downside to this is the fact that everyone
> would have to agree or settle on the same SCM tool (or we could just
> use github, bitbucket, etc).
> Another suggestion - recording the talks + cohpy youtube channel would
> be a big win in my opinion.
> CentralOH mailing list
> CentralOH at python.org
More information about the CentralOH