I teach two university courses in new media and web development. In these course students build websites, and in the past I have encouraged students to choose whatever platform they like (after various discussions about the considerations in choosing). So, we've had sites built with Drupal, Wordpress, Radiant, and so on. However, I've had some challenges with the "build whatever you like approach," and I'm thinking for next semester that I'll ask the students to all use the same platform: of course, that platform would be Mezzanine.
But there is a challenge to this approach. In the past, students have used their own domains and servers. What I'd like to do is collect their accounts together onto one server, and provide each student an account and space on the server. So, in this scenario they would be able to login, create a Mezzanine project, and build their site. But then I start thinking about deployment, and how to handle Apache and so on.
Apache could be setup to serve all the student sites, but students would not be able to restart Apache. That should be OK, as long as they can restart Mezzanine. So, overall, I suppose this should work. But still, I have two questions:
1. How should we handle the development server, which normally runs on a local machine? If the students are building on a remote server, what's the best approach to allow them to deploy and test using the development server? Is the development server sufficient (ie as an alternative to Apache)? The students just need to be able to run each site in a browser, so that the rest of the class can view the projects.
2. Is there a better way to do this? A different web server than Apache, perhaps, or some type of fancy setup within Mezzanine to facilitate multiple projects?
I'm open to any suggestions. I haven't yet thought this all the way through, so it's likely that I'm overlooking something important. But I think I've described the end goal well enough to give you a sense of what I'm trying to do. Any and all feedback most welcome.
My thoughts are that since the sites really aren't going to be used in
production the development server should work fine. Then you could set up
apache or nginx or whatever webserver so that each students domain
listens/proxies to a specific port on localhost.
With that set up student A for example could run the devserver like so
(assuming their port is 12345 and their domain is studenta.domain.com):
python manage.py runserver 12345
and then the site would be accessible at studenta.domain.com
I don't know how optimal of a solution that is, but it seems like it should
work.
On Thu, Sep 13, 2012 at 9:59 AM, Ross Laird <r...@rosslaird.com> wrote:
> I teach two university courses in new media and web development. In these
> course students build websites, and in the past I have encouraged students
> to choose whatever platform they like (after various discussions about the
> considerations in choosing). So, we've had sites built with Drupal,
> Wordpress, Radiant, and so on. However, I've had some challenges with the
> "build whatever you like approach," and I'm thinking for next semester that
> I'll ask the students to all use the same platform: of course, that
> platform would be Mezzanine.
> But there is a challenge to this approach. In the past, students have used
> their own domains and servers. What I'd like to do is collect their
> accounts together onto one server, and provide each student an account and
> space on the server. So, in this scenario they would be able to login,
> create a Mezzanine project, and build their site. But then I start thinking
> about deployment, and how to handle Apache and so on.
> Apache could be setup to serve all the student sites, but students would
> not be able to restart Apache. That should be OK, as long as they can
> restart Mezzanine. So, overall, I suppose this should work. But still, I
> have two questions:
> 1. How should we handle the development server, which normally runs on a
> local machine? If the students are building on a remote server, what's the
> best approach to allow them to deploy and test using the development
> server? Is the development server sufficient (ie as an alternative to
> Apache)? The students just need to be able to run each site in a browser,
> so that the rest of the class can view the projects.
> 2. Is there a better way to do this? A different web server than Apache,
> perhaps, or some type of fancy setup within Mezzanine to facilitate
> multiple projects?
> I'm open to any suggestions. I haven't yet thought this all the way
> through, so it's likely that I'm overlooking something important. But I
> think I've described the end goal well enough to give you a sense of what
> I'm trying to do. Any and all feedback most welcome.
Have you considered that the users could use their own local development server and use heroku (or anything like heroku) to deploy their own servers? You could run a simple web page on the heroku free plan and you avoid having to manage a web server to deploy the students website.
Doing this way you force the users to use a DVCS (git) to deploy they code and you can examine their progress by sharing the repo. I was thinking on using GitHub, but I'm sure you won't like that every student code is public available on the web. So I will encourage you to mount a private git server with ssh access foreach user ;)
This way the can learn about how to use a public web service and a DVCS, so they learn more :D
> My thoughts are that since the sites really aren't going to be used in > production the development server should work fine. Then you could > set up apache or nginx or whatever webserver so that each students > domain listens/proxies to a specific port on localhost.
> With that set up student A for example could run the devserver like so > (assuming their port is 12345 and their domain is studenta.domain.com > <http://studenta.domain.com>):
> python manage.py runserver 12345
> and then the site would be accessible at studenta.domain.com > <http://studenta.domain.com>
> I don't know how optimal of a solution that is, but it seems like it > should work.
> On Thu, Sep 13, 2012 at 9:59 AM, Ross Laird <r...@rosslaird.com > <mailto:r...@rosslaird.com>> wrote:
> I teach two university courses in new media and web development.
> In these course students build websites, and in the past I have
> encouraged students to choose whatever platform they like (after
> various discussions about the considerations in choosing). So,
> we've had sites built with Drupal, Wordpress, Radiant, and so on.
> However, I've had some challenges with the "build whatever you
> like approach," and I'm thinking for next semester that I'll ask
> the students to all use the same platform: of course, that
> platform would be Mezzanine.
> But there is a challenge to this approach. In the past, students
> have used their own domains and servers. What I'd like to do is
> collect their accounts together onto one server, and provide each
> student an account and space on the server. So, in this scenario
> they would be able to login, create a Mezzanine project, and build
> their site. But then I start thinking about deployment, and how to
> handle Apache and so on.
> Apache could be setup to serve all the student sites, but students
> would not be able to restart Apache. That should be OK, as long as
> they can restart Mezzanine. So, overall, I suppose this should
> work. But still, I have two questions:
> 1. How should we handle the development server, which normally
> runs on a local machine? If the students are building on a remote
> server, what's the best approach to allow them to deploy and test
> using the development server? Is the development server sufficient
> (ie as an alternative to Apache)? The students just need to be
> able to run each site in a browser, so that the rest of the class
> can view the projects.
> 2. Is there a better way to do this? A different web server than
> Apache, perhaps, or some type of fancy setup within Mezzanine to
> facilitate multiple projects?
> I'm open to any suggestions. I haven't yet thought this all the
> way through, so it's likely that I'm overlooking something
> important. But I think I've described the end goal well enough to
> give you a sense of what I'm trying to do. Any and all feedback
> most welcome.
Running the dev server will be fine as long as they leave debug on. The easiest approach would be to create an command alias for students to run the server:
alias run-mezzanine='python manage.py runserver 0.0.0.0:`expr 8000 + \`id -u $USER\``'
Then all you need to do is go to http://hostname:9001 (or whatever) and the students won't collide.
If you want them to reside on and forward custom domains, you could use something like nginx to do proxy forwarding. Build one nginx site file per student like this:
root@ip-10-245-22-95:/etc/nginx/sites-available# more student.domain.com server {
listen 80;
# change student.domain.com here
server_name student.domain.com
access_log /var/log/nginx/student_domain_com.access.log;
error_log /var/log/nginx/student_domain_com.error.log;
Then you can either just use the runserver alias above, or look into django-gunicorn. The above nginx config probably isn't perfect. I hacked out an http redirect to https, but hopefully you will get the idea. This way the main web server stays alive even if the server behind it crashes.
-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Sep 13, 2012, at 12:59 PM, Ross Laird <r...@rosslaird.com> wrote:
> I teach two university courses in new media and web development. In these course students build websites, and in the past I have encouraged students to choose whatever platform they like (after various discussions about the considerations in choosing). So, we've had sites built with Drupal, Wordpress, Radiant, and so on. However, I've had some challenges with the "build whatever you like approach," and I'm thinking for next semester that I'll ask the students to all use the same platform: of course, that platform would be Mezzanine.
> But there is a challenge to this approach. In the past, students have used their own domains and servers. What I'd like to do is collect their accounts together onto one server, and provide each student an account and space on the server. So, in this scenario they would be able to login, create a Mezzanine project, and build their site. But then I start thinking about deployment, and how to handle Apache and so on.
> Apache could be setup to serve all the student sites, but students would not be able to restart Apache. That should be OK, as long as they can restart Mezzanine. So, overall, I suppose this should work. But still, I have two questions:
> 1. How should we handle the development server, which normally runs on a local machine? If the students are building on a remote server, what's the best approach to allow them to deploy and test using the development server? Is the development server sufficient (ie as an alternative to Apache)? The students just need to be able to run each site in a browser, so that the rest of the class can view the projects.
> 2. Is there a better way to do this? A different web server than Apache, perhaps, or some type of fancy setup within Mezzanine to facilitate multiple projects?
> I'm open to any suggestions. I haven't yet thought this all the way through, so it's likely that I'm overlooking something important. But I think I've described the end goal well enough to give you a sense of what I'm trying to do. Any and all feedback most welcome.
I think I would approach this leaning heavily on Mezzanine's Fabric
script. Give each student a personalized settings.FABRIC dict. Use a
modified Mezzanine fabfile with deploy targets 'local' - to provision
a Vagrant - and 'prod' - to deploy her master branch to the central
server and restart appropriate services. The student maintains
individual configuration files in deploy/. If a student deploys a
broken nginx config, she will certainly hear about it from her peers,
but that won't happen because the deploy was tested on the Vagrant.
Maybe the pain of deployment is a teachable moment you want to emphasize.
However you decide to go, I definitely want to hear how it goes.
On Thu, Sep 13, 2012 at 12:59 PM, Ross Laird <r...@rosslaird.com> wrote:
> I teach two university courses in new media and web development. In these
> course students build websites, and in the past I have encouraged students
> to choose whatever platform they like (after various discussions about the
> considerations in choosing). So, we've had sites built with Drupal,
> Wordpress, Radiant, and so on. However, I've had some challenges with the
> "build whatever you like approach," and I'm thinking for next semester that
> I'll ask the students to all use the same platform: of course, that platform
> would be Mezzanine.
> But there is a challenge to this approach. In the past, students have used
> their own domains and servers. What I'd like to do is collect their accounts
> together onto one server, and provide each student an account and space on
> the server. So, in this scenario they would be able to login, create a
> Mezzanine project, and build their site. But then I start thinking about
> deployment, and how to handle Apache and so on.
> Apache could be setup to serve all the student sites, but students would not
> be able to restart Apache. That should be OK, as long as they can restart
> Mezzanine. So, overall, I suppose this should work. But still, I have two
> questions:
> 1. How should we handle the development server, which normally runs on a
> local machine? If the students are building on a remote server, what's the
> best approach to allow them to deploy and test using the development server?
> Is the development server sufficient (ie as an alternative to Apache)? The
> students just need to be able to run each site in a browser, so that the
> rest of the class can view the projects.
> 2. Is there a better way to do this? A different web server than Apache,
> perhaps, or some type of fancy setup within Mezzanine to facilitate multiple
> projects?
> I'm open to any suggestions. I haven't yet thought this all the way through,
> so it's likely that I'm overlooking something important. But I think I've
> described the end goal well enough to give you a sense of what I'm trying to
> do. Any and all feedback most welcome.
Just wanted to second Ken's comments. This is really exciting and would
love to track the progress.
I think Ken's approach of leveraging the bundled fabfile would work really
well - each student would simply need their own set of unique fabric
settings (port, project name, etc). Only thing to keep in mind is that the
bundled fabfile assumes a user account on the server with sudo access, so a
level of trust is involved here.
On Fri, Sep 14, 2012 at 5:38 AM, Ken Bolton <kenbol...@gmail.com> wrote:
> I love this!
> I think I would approach this leaning heavily on Mezzanine's Fabric
> script. Give each student a personalized settings.FABRIC dict. Use a
> modified Mezzanine fabfile with deploy targets 'local' - to provision
> a Vagrant - and 'prod' - to deploy her master branch to the central
> server and restart appropriate services. The student maintains
> individual configuration files in deploy/. If a student deploys a
> broken nginx config, she will certainly hear about it from her peers,
> but that won't happen because the deploy was tested on the Vagrant.
> Maybe the pain of deployment is a teachable moment you want to emphasize.
> However you decide to go, I definitely want to hear how it goes.
> best,
> ken
> On Thu, Sep 13, 2012 at 12:59 PM, Ross Laird <r...@rosslaird.com> wrote:
> > I teach two university courses in new media and web development. In these
> > course students build websites, and in the past I have encouraged
> students
> > to choose whatever platform they like (after various discussions about
> the
> > considerations in choosing). So, we've had sites built with Drupal,
> > Wordpress, Radiant, and so on. However, I've had some challenges with the
> > "build whatever you like approach," and I'm thinking for next semester
> that
> > I'll ask the students to all use the same platform: of course, that
> platform
> > would be Mezzanine.
> > But there is a challenge to this approach. In the past, students have
> used
> > their own domains and servers. What I'd like to do is collect their
> accounts
> > together onto one server, and provide each student an account and space
> on
> > the server. So, in this scenario they would be able to login, create a
> > Mezzanine project, and build their site. But then I start thinking about
> > deployment, and how to handle Apache and so on.
> > Apache could be setup to serve all the student sites, but students would
> not
> > be able to restart Apache. That should be OK, as long as they can restart
> > Mezzanine. So, overall, I suppose this should work. But still, I have two
> > questions:
> > 1. How should we handle the development server, which normally runs on a
> > local machine? If the students are building on a remote server, what's
> the
> > best approach to allow them to deploy and test using the development
> server?
> > Is the development server sufficient (ie as an alternative to Apache)?
> The
> > students just need to be able to run each site in a browser, so that the
> > rest of the class can view the projects.
> > 2. Is there a better way to do this? A different web server than Apache,
> > perhaps, or some type of fancy setup within Mezzanine to facilitate
> multiple
> > projects?
> > I'm open to any suggestions. I haven't yet thought this all the way
> through,
> > so it's likely that I'm overlooking something important. But I think I've
> > described the end goal well enough to give you a sense of what I'm
> trying to
> > do. Any and all feedback most welcome.
Thanks for all these great suggestions. And I'm glad to see the enthusiasm for this. I'll let you know how it goes. I'll discuss these options with the tech folks at the university. I know from experience that they are never going to give any student sudo access on a server, and I know also that I won't be able to use Heroku (the university is in Canada, and we have some strict guidelines about not using services hosted in the US, as Homeland Security and the NSA violate our privacy laws...). I can configure git for the server, though, and I can do most of what is outlined above. So, it does seem that this is going to be eminently doable. And yes, I am definitely trying to create "teachable moments" with this. My experience with my students in these courses is that generally they have very little real experience in actually *building*something, even though they have a good deal of experience in *using* something. The more adept students are able to use the command line proficiently and to deploy sites; but for the vast majority, this kind of thing will be a major undertaking (which is what I want...).
On Thursday, 13 September 2012 14:03:09 UTC-7, Stephen McDonald wrote:
> Just wanted to second Ken's comments. This is really exciting and would > love to track the progress.
> I think Ken's approach of leveraging the bundled fabfile would work really > well - each student would simply need their own set of unique fabric > settings (port, project name, etc). Only thing to keep in mind is that the > bundled fabfile assumes a user account on the server with sudo access, so a > level of trust is involved here.
> On Fri, Sep 14, 2012 at 5:38 AM, Ken Bolton <kenb...@gmail.com<javascript:> > > wrote:
>> I love this!
>> I think I would approach this leaning heavily on Mezzanine's Fabric >> script. Give each student a personalized settings.FABRIC dict. Use a >> modified Mezzanine fabfile with deploy targets 'local' - to provision >> a Vagrant - and 'prod' - to deploy her master branch to the central >> server and restart appropriate services. The student maintains >> individual configuration files in deploy/. If a student deploys a >> broken nginx config, she will certainly hear about it from her peers, >> but that won't happen because the deploy was tested on the Vagrant.
>> Maybe the pain of deployment is a teachable moment you want to emphasize.
>> However you decide to go, I definitely want to hear how it goes.
>> best, >> ken
>> On Thu, Sep 13, 2012 at 12:59 PM, Ross Laird <ro...@rosslaird.com<javascript:>> >> wrote: >> > I teach two university courses in new media and web development. In >> these >> > course students build websites, and in the past I have encouraged >> students >> > to choose whatever platform they like (after various discussions about >> the >> > considerations in choosing). So, we've had sites built with Drupal, >> > Wordpress, Radiant, and so on. However, I've had some challenges with >> the >> > "build whatever you like approach," and I'm thinking for next semester >> that >> > I'll ask the students to all use the same platform: of course, that >> platform >> > would be Mezzanine.
>> > But there is a challenge to this approach. In the past, students have >> used >> > their own domains and servers. What I'd like to do is collect their >> accounts >> > together onto one server, and provide each student an account and space >> on >> > the server. So, in this scenario they would be able to login, create a >> > Mezzanine project, and build their site. But then I start thinking about >> > deployment, and how to handle Apache and so on.
>> > Apache could be setup to serve all the student sites, but students >> would not >> > be able to restart Apache. That should be OK, as long as they can >> restart >> > Mezzanine. So, overall, I suppose this should work. But still, I have >> two >> > questions:
>> > 1. How should we handle the development server, which normally runs on a >> > local machine? If the students are building on a remote server, what's >> the >> > best approach to allow them to deploy and test using the development >> server? >> > Is the development server sufficient (ie as an alternative to Apache)? >> The >> > students just need to be able to run each site in a browser, so that the >> > rest of the class can view the projects.
>> > 2. Is there a better way to do this? A different web server than Apache, >> > perhaps, or some type of fancy setup within Mezzanine to facilitate >> multiple >> > projects?
>> > I'm open to any suggestions. I haven't yet thought this all the way >> through, >> > so it's likely that I'm overlooking something important. But I think >> I've >> > described the end goal well enough to give you a sense of what I'm >> trying to >> > do. Any and all feedback most welcome.
>Thanks for all these great suggestions. And I'm glad to see the
>enthusiasm >for this. I'll let you know how it goes.
>I'll discuss these options with the tech folks at the university. I
>know >from experience that they are never going to give any student sudo
>access >on a server, and I know also that I won't be able to use Heroku (the >university is in Canada, and we have some strict guidelines about not
>using >services hosted in the US, as Homeland Security and the NSA violate our
>privacy laws...). I can configure git for the server, though, and I can
>do >most of what is outlined above. So, it does seem that this is going to
>be >eminently doable. And yes, I am definitely trying to create "teachable >moments" with this. My experience with my students in these courses is
>that >generally they have very little real experience in actually
>*building*something, even though they have a good deal of experience in
>*using* something. The more adept students are able to use the command
>line >proficiently and to deploy sites; but for the vast majority, this kind
>of >thing will be a major undertaking (which is what I want...).
>Thanks again.
>Cheers.
>Ross
>On Thursday, 13 September 2012 14:03:09 UTC-7, Stephen McDonald wrote:
>> Just wanted to second Ken's comments. This is really exciting and
>would >> love to track the progress.
>> I think Ken's approach of leveraging the bundled fabfile would work
>really >> well - each student would simply need their own set of unique fabric >> settings (port, project name, etc). Only thing to keep in mind is
>that the >> bundled fabfile assumes a user account on the server with sudo
>access, so a >> level of trust is involved here.
>> On Fri, Sep 14, 2012 at 5:38 AM, Ken Bolton
><kenb...@gmail.com<javascript:>
>> > wrote:
>>> I love this!
>>> I think I would approach this leaning heavily on Mezzanine's Fabric
>>> script. Give each student a personalized settings.FABRIC dict. Use a
>>> modified Mezzanine fabfile with deploy targets 'local' - to
>provision
>>> a Vagrant - and 'prod' - to deploy her master branch to the central
>>> server and restart appropriate services. The student maintains
>>> individual configuration files in deploy/. If a student deploys a
>>> broken nginx config, she will certainly hear about it from her
>peers,
>>> but that won't happen because the deploy was tested on the Vagrant.
>>> Maybe the pain of deployment is a teachable moment you want to
>emphasize.
>>> However you decide to go, I definitely want to hear how it goes.
>>> best,
>>> ken
>>> On Thu, Sep 13, 2012 at 12:59 PM, Ross Laird
><ro...@rosslaird.com<javascript:>> >>> wrote:
>>> > I teach two university courses in new media and web development.
>In >>> these
>>> > course students build websites, and in the past I have encouraged >>> students
>>> > to choose whatever platform they like (after various discussions
>about >>> the
>>> > considerations in choosing). So, we've had sites built with
>Drupal,
>>> > Wordpress, Radiant, and so on. However, I've had some challenges
>with >>> the
>>> > "build whatever you like approach," and I'm thinking for next
>semester >>> that
>>> > I'll ask the students to all use the same platform: of course,
>that >>> platform
>>> > would be Mezzanine.
>>> > But there is a challenge to this approach. In the past, students
>have >>> used
>>> > their own domains and servers. What I'd like to do is collect
>their >>> accounts
>>> > together onto one server, and provide each student an account and
>space >>> on
>>> > the server. So, in this scenario they would be able to login,
>create a
>>> > Mezzanine project, and build their site. But then I start thinking
>about
>>> > deployment, and how to handle Apache and so on.
>>> > Apache could be setup to serve all the student sites, but students
>>> would not
>>> > be able to restart Apache. That should be OK, as long as they can >>> restart
>>> > Mezzanine. So, overall, I suppose this should work. But still, I
>have >>> two
>>> > questions:
>>> > 1. How should we handle the development server, which normally
>runs on a
>>> > local machine? If the students are building on a remote server,
>what's >>> the
>>> > best approach to allow them to deploy and test using the
>development >>> server?
>>> > Is the development server sufficient (ie as an alternative to
>Apache)? >>> The
>>> > students just need to be able to run each site in a browser, so
>that the
>>> > rest of the class can view the projects.
>>> > 2. Is there a better way to do this? A different web server than
>Apache,
>>> > perhaps, or some type of fancy setup within Mezzanine to
>facilitate >>> multiple
>>> > projects?
>>> > I'm open to any suggestions. I haven't yet thought this all the
>way >>> through,
>>> > so it's likely that I'm overlooking something important. But I
>think >>> I've
>>> > described the end goal well enough to give you a sense of what I'm
>>> trying to
>>> > do. Any and all feedback most welcome.
[WARNING] Personal, controversial opinion follows. I'll be that guy, sorry.
There's a contradiction here between:
Ross Laird wrote:
> I can configure git for the server, though, and I can do most of what
> is outlined above.
and:
> And yes, I am definitely trying to create "teachable moments" with
> this.
git's usability is inadequate. It's bad enough having to use it on the
job: foisting it on unsuspecting students will unnecessarily worsen their
learning experience. They'll be better off with something saner like
Mercurial or Bazaar.
No, the popularity argument does not really matter, otherwise you would
be teaching Java or C++, rather than Python.
I think our policy should be: make the simplest thing that can possibly
work for a narrowly-tailored use case, then make things more generic
*slowly* if there's a demand. No need to be an Architecture Astronaut.
- Adrian Holovaty, Django web framework author, March 2012
On Fri, Sep 14, 2012 at 07:37:38AM +0200, Nicola Larosa wrote:
>[WARNING] Personal, controversial opinion follows. I'll be that guy, sorry.
A wild counter-argument appearss!
>git's usability is inadequate. It's bad enough having to use it on the
>job: foisting it on unsuspecting students will unnecessarily worsen their
>learning experience. They'll be better off with something saner like
>Mercurial or Bazaar.
That depends on where you're coming from. I ran a social experiment
on our intern; she had no experience in version control whatsoever.
She got SmartGit real easy. The trick is to make it sound easy,
because that's what it is, if you don't have legacy debt from CVS days.
Just explain commits and pushes as they are and they'll probably be
fine.
Last I saw hg it looked like the poor man's git. No bzr experience
though. But if these kids are to be taught how to operate in the
real world, git and especially github are worthwhile.
Git, github, runserver and fabric is a workflow that evolved
and became popular for a good reason ;)
A well-crafted /etc/sudoers might mitigate the concerns of the
technologists at your institution. It took a while, but I convinced
sysadmins at a US university where I was formerly employed that a
properly secured OS in use by students required student sudo access.
On Fri, Sep 14, 2012 at 1:37 AM, Nicola Larosa <nicola.lar...@gmail.com> wrote:
> [WARNING] Personal, controversial opinion follows. I'll be that guy, sorry.
> There's a contradiction here between:
> Ross Laird wrote:
>> I can configure git for the server, though, and I can do most of what
>> is outlined above.
> and:
>> And yes, I am definitely trying to create "teachable moments" with
>> this.
> git's usability is inadequate. It's bad enough having to use it on the
> job: foisting it on unsuspecting students will unnecessarily worsen their
> learning experience. They'll be better off with something saner like
> Mercurial or Bazaar.
> No, the popularity argument does not really matter, otherwise you would
> be teaching Java or C++, rather than Python.
> I think our policy should be: make the simplest thing that can possibly
> work for a narrowly-tailored use case, then make things more generic
> *slowly* if there's a demand. No need to be an Architecture Astronaut.
> - Adrian Holovaty, Django web framework author, March 2012
I don't think there is an inherent contradiction between teachable moments in education (all moments in education should be "teachable" moments of learning) and using git. Yes, git can be quite complex, but it can also be quite simple if used only for commits and file tracking (no merges, no cherry-picking, etc). That's what I intend to have the students use it for: simple stuff. The balance between overwhelm and skill development is always tricky in an educational environment such as the one in which I teach. Typically, I use the metaphor of learning to surf: it's easy to miss the wave, to have it pass beneath; and it's easy to be swamped by the wave, to be tumbled into the shore. The sweet spot, the turbulent edge, is where the learning is. It has to be a bit tough to get onto that edge, a bit tough to remain there -- but once you get there, as all students should in an authentically well-tuned learning environment, that turbulent edge is immeasurably rewarding.
On Thursday, 13 September 2012 22:37:43 UTC-7, Nicola Larosa (tekNico) wrote:
> [WARNING] Personal, controversial opinion follows. I'll be that guy, > sorry.
> There's a contradiction here between:
> Ross Laird wrote: > > I can configure git for the server, though, and I can do most of what > > is outlined above.
> and:
> > And yes, I am definitely trying to create "teachable moments" with > > this.
> git's usability is inadequate. It's bad enough having to use it on the > job: foisting it on unsuspecting students will unnecessarily worsen their > learning experience. They'll be better off with something saner like > Mercurial or Bazaar.
> No, the popularity argument does not really matter, otherwise you would > be teaching Java or C++, rather than Python.
> I think our policy should be: make the simplest thing that can possibly > work for a narrowly-tailored use case, then make things more generic > *slowly* if there's a demand. No need to be an Architecture Astronaut. > - Adrian Holovaty, Django web framework author, March 2012
On Friday, 14 September 2012 07:55:59 UTC-7, Kenneth Bolton wrote:
> Hi Ross,
> A well-crafted /etc/sudoers might mitigate the concerns of the > technologists at your institution. It took a while, but I convinced > sysadmins at a US university where I was formerly employed that a > properly secured OS in use by students required student sudo access.
> Ken
> On Fri, Sep 14, 2012 at 1:37 AM, Nicola Larosa <nicola...@gmail.com<javascript:>> > wrote: > > [WARNING] Personal, controversial opinion follows. I'll be that guy, > sorry.
> > There's a contradiction here between:
> > Ross Laird wrote: > >> I can configure git for the server, though, and I can do most of what > >> is outlined above.
> > and:
> >> And yes, I am definitely trying to create "teachable moments" with > >> this.
> > git's usability is inadequate. It's bad enough having to use it on the > > job: foisting it on unsuspecting students will unnecessarily worsen > their > > learning experience. They'll be better off with something saner like > > Mercurial or Bazaar.
> > No, the popularity argument does not really matter, otherwise you would > > be teaching Java or C++, rather than Python.
> > I think our policy should be: make the simplest thing that can possibly > > work for a narrowly-tailored use case, then make things more generic > > *slowly* if there's a demand. No need to be an Architecture Astronaut. > > - Adrian Holovaty, Django web framework author, March 2012
On Fri, Sep 14, 2012 at 3:49 PM, Ross Laird <r...@rosslaird.com> wrote:
> I don't think there is an inherent contradiction between teachable moments
> in education (all moments in education should be "teachable" moments of
> learning) and using git. Yes, git can be quite complex, but it can also be
> quite simple if used only for commits and file tracking (no merges, no
> cherry-picking, etc). That's what I intend to have the students use it for:
> simple stuff. The balance between overwhelm and skill development is always
> tricky in an educational environment such as the one in which I teach.
> Typically, I use the metaphor of learning to surf: it's easy to miss the
> wave, to have it pass beneath; and it's easy to be swamped by the wave, to
> be tumbled into the shore. The sweet spot, the turbulent edge, is where the
> learning is. It has to be a bit tough to get onto that edge, a bit tough to
> remain there -- but once you get there, as all students should in an
> authentically well-tuned learning environment, that turbulent edge is
> immeasurably rewarding.
> On Thursday, 13 September 2012 22:37:43 UTC-7, Nicola Larosa (tekNico)
> wrote:
>> [WARNING] Personal, controversial opinion follows. I'll be that guy,
>> sorry.
>> There's a contradiction here between:
>> Ross Laird wrote:
>> > I can configure git for the server, though, and I can do most of what
>> > is outlined above.
>> and:
>> > And yes, I am definitely trying to create "teachable moments" with
>> > this.
>> git's usability is inadequate. It's bad enough having to use it on the
>> job: foisting it on unsuspecting students will unnecessarily worsen their
>> learning experience. They'll be better off with something saner like
>> Mercurial or Bazaar.
>> No, the popularity argument does not really matter, otherwise you would
>> be teaching Java or C++, rather than Python.
>> I think our policy should be: make the simplest thing that can possibly
>> work for a narrowly-tailored use case, then make things more generic
>> *slowly* if there's a demand. No need to be an Architecture Astronaut.
>> - Adrian Holovaty, Django web framework author, March 2012
