[CentralOH] Sprints - cohpy.org Web Site

Eric Floehr 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
> http://mail.python.org/mailman/listinfo/centraloh

More information about the CentralOH mailing list