[p2pu-dev] Tech call notes: 2013-01-17
Philipp Schmidt
philipp at p2pu.org
Tue Jan 22 18:29:29 UTC 2013
This is a great conversation.
There is no immediate plan to build a larger integrated solution. The advantage of running each MOOC as a separate instance, forking the core code and then modifying it based on needs, is that we can experiment much more easily. Running more of these prototypes will help us identify *if* there is a need & demand for a more integrated hosted solution. We think there might be, but it's too early to say.
The motivation to move to Python comes from not wanting to support Python and Ruby going forward. We are too small to be experts in both, and we have a larger Python footprint.
P
On Tuesday, January 22, 2013 at 12:28 PM, Jos Flores wrote:
> Hey Chris,
>
> that is a very good point, flexibility to evolve the system as
> requirements change; designing for functionality that might never
> happen, as you mention, is just waste.
> But I believe that flexibility won't come by by just choosing one or
> other framework. If you use Django and all your business logic is
> hidden in your views, you won't get any reuse of that, and it will be
> quite difficult to test. But it would be the same with flask. If you
> put all your logic in a decorated route method, you won't be able to
> get any reuse of that, and testing will also be coupled with routing.
> If all your business logic is encapsulated in classes, your domain
> objects will be usable by both Django and flask, and being plain
> objects, can be very testable. But anyway, this is pretty much the
> same you are saying! :)
>
> I would still push the idea of small services that all talk to each
> other. Not sure if this is what you guys have in mind, but imagine
> that all maker instances are individual, but the requirement changes
> and they all should be somehow 'enclosed' in the same maker with many
> instances. A potential solution for that would be to write a small
> booting service that can boot up and register many instances of the
> maker in the same machine. If some of the most general services in the
> maker should not be available anymore (because now those services
> belong to the main Maker, and not the instances), those module could
> be registered with the booting service instead of with each individual
> maker instance.
> This all sounds a lot easier that it would actually be, no doubt of
> that, but starting small and evolving the system sounds like a good
> idea.
>
> Are you guys very familiar with Backbone? or would you have to learn
> as you go? If the latter is the case, I'd recommend AngularJS,
> although I have very little experience with both, but I'm liking
> angular more and more lately... I didn't like it at all when I first
> looked into it, so no idea what's going on in my head!!! :D
>
> Sorry if I missed this, but are there any docs with requirements or
> ideas for the Maker?
>
>
> cheers,
> José
>
>
> On 22 January 2013 14:33, Chris Ewald <chris at p2pu.org (mailto:chris at p2pu.org)> wrote:
> > Good point José. I'd agree that the size of the app is more dependent on the
> > routing rather than the db. It would be worth considering using a nosql db
> > rather than a relational (postgres?) db. I been wanting to play with mongo
> > db for a while now. That being said, I think the emails are the only piece
> > that would be a good fit for a document db - so I'm inclined to think that a
> > relational db would still preferable for this. It would really just be the
> > email bodys - and I think they'll be small enough to fit in a full text
> > column just fine.
> >
> > In general, my preference would be to use a smaller framework like flask as
> > opposed to django. But we have to keep in mind the entire scope of the
> > project which is pretty big. In the long term - we are going to want user
> > accounts that have MOOCs in them and full analytics for the course creators.
> > With this in mind, django feels a lot better. But it's an interesting
> > question as to design for these - eventual features - now. Should we?
> > There's a chance that they won't ever be implemented - where we prefer that
> > each MOOC is it's own instance of the MOOC maker in the long run. How much
> > time / difficulty would be to turn a flask project into a django project? If
> > we start it in flask, could we design it in a way where the model / ORM
> > layer could be easily lifted out and placed into a django project?
> >
> > My instinct would be to do that. Start this using flask with a good
> > modularized model / ORM layer that could be simply reused in a django
> > project if / when that time comes. Does SQLAlchemy work well with both?
> > Also, I really dislike the django view / templating layer so just about
> > anything else is preferable to me. Maybe we could look into a templating
> > tech that works well with both as well. A JS solution preferably as well.
> >
> >
> > On Mon, Jan 21, 2013 at 6:20 AM, Jos Flores <josmasflores at gmail.com (mailto:josmasflores at gmail.com)> wrote:
> > >
> > > Hi Dirk,
> > >
> > > I quite like what I read about blueprints, but it's not the only way
> > > of extending flask; It's a bit confusing (to me) how they
> > > differentiate between Extensions (I'd say this would be a package in
> > > Django), and blueprints. After a quick read, it feels like extensions
> > > are designed to deal with things like 3rd party libraries (DBs and the
> > > likes) and blueprints are a way of encapsulating your business logic;
> > > but I might be wrong.
> > >
> > > In any case, there are Extensions for I18n and L10n, and there seems
> > > to be plenty of support for deployment, including full support on
> > > heroku. The extensions list is quite complete, including several
> > > extensions for SQLAlchemy and even MongoDB + SQLAlchemy, OAuth,
> > > openID, Celery, Gravatar... so plenty of choice
> > > (http://flask.pocoo.org/extensions/).
> > >
> > > But anyway, even though discussion is good, the decision should also
> > > consider what's going to make it easier to deliver. Even though Django
> > > can be a bit too big for this, if it makes your lives easier in terms
> > > or context switching, reusing deployment scripts from Lernanta, and so
> > > on, then it can make sense to go with it.
> > >
> > > Do you guys have any timelines to get this off the ground? I'm hoping
> > > to have 3 or 4 free days at the end of February, if that's any good to
> > > you.
> > >
> > > cheers,
> > > José
> > >
> > >
> > > On 21 January 2013 07:47, Dirk Uys <dirk at p2pu.org (mailto:dirk at p2pu.org)> wrote:
> > > > Hi people!!
> > > >
> > > > Great discussion! You guys are sharp as always!
> > > >
> > > > A few notes from my side:
> > > >
> > > > I've used SQL Alchemy before and I'm a big fan. It gives a great
> > > > alternative
> > > > to Django's ORM and you can do anything between Django's ORM and very
> > > > customized SQL. I've read somewhere that the only reason why Django
> > > > isn't
> > > > using SQL Alchemy is because it wasn't around when Django started.
> > > >
> > > > I've had a brief look at Flask in the past and in general I like their
> > > > philosophy, but I haven't used it much. They have some strange ideas
> > > > when it
> > > > comes to larger Flask apps (http://flask.pocoo.org/docs/blueprints/). I
> > > > haven't look at that, maybe it's actually quite good?
> > > >
> > > > I've used Pylons before that is similar to Flask in their philosophy.
> > > > But
> > > > since then they changed the project name to Pyramid and developed some
> > > > other
> > > > ideas.
> > > >
> > > > Django has some things in it that I do not like: database triggers,
> > > > generic
> > > > relationships using the content type framework, template tags triggering
> > > > a
> > > > whole bunch of logic and rendering out templates, etc.
> > > >
> > > > But, it's up to use to choose if you want to use those features. It is
> > > > completely possible to implement a rest api using Django. The only part
> > > > of
> > > > Django that you *need* to use is the routing and the views. Everything
> > > > else
> > > > is up to you - even the ORM.
> > > >
> > > > For any application we have to keep i18n, l16n, deployment, testing,
> > > > backup,
> > > > etc in mind. If we use Flask, SQLAlchemy or backbone.js, we have to make
> > > > sure that we're not creating a maintenance nightmare for ourselves and
> > > > the
> > > > people who need to manage and translate the applications.
> > > >
> > > > Cheers
> > > > d
> > > >
> > > >
> > > >
> > > > On Mon, Jan 21, 2013 at 1:56 AM, Jos Flores <josmasflores at gmail.com (mailto:josmasflores at gmail.com)>
> > > > wrote:
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > This is a personal opinion, but I wouldn't measure the size of the app
> > > > > by the size of the DB, but by the amount of routing you want to do.
> > > > > I have no experience with flask, but have worked with expressjs in
> > > > > node (same idea of easy, out of the box restful routing), and it can
> > > > > get a bit out of hand if your app starts to get bigger. The whole
> > > > > philosophy in node is to have a number of very small services instead
> > > > > of a monolithic system, which is why I'm a bit concerned about using
> > > > > Django for an app that shouldn't be too big in terms of routes and
> > > > > views. It's like driving a bus to work everyday. Especially if you are
> > > > > going to use Backbone; you end up with an MVC on the server and an MV*
> > > > > on the client, when you only really want backbone to load from your
> > > > > API and forget about server generated html.
> > > > > I never got a chance to go deep into backbone; been playing with
> > > > > AngularJS for a couple of weeks, and it feels quite nice, but any of
> > > > > the two (or other options) feels better than using a big monolithic
> > > > > framework like RoR or Django for rendering user views.
> > > > >
> > > > > With regards to ORM for flask, SQL Alchemy seems to be thing I hear
> > > > > most about: http://www.sqlalchemy.org/
> > > > > but I haven't used it myself.
> > > > >
> > > > > Another jump here, if the app is going to store a high number of
> > > > > emails, a nosql solution could work better than a relational db. If
> > > > > there is a bunch of unstructured data, that is. Just a thought! :)
> > > > >
> > > > > cheers,
> > > > > José
> > > > >
> > > > >
> > > > > On 20 January 2013 22:14, Chris Ewald <chris at p2pu.org (mailto:chris at p2pu.org)> wrote:
> > > > > > @José - There are other plans for it. Right now we're calling our
> > > > > > current
> > > > > > tech the Mechanical MOOC and we are going to make, what we're
> > > > > > tentatively
> > > > > > calling the MOOC Maker. The MOOC Maker is the long term goal, which
> > > > > > is
> > > > > > going
> > > > > > to have a email scheduler, sign up question configuration, etc. In
> > > > > > theory so
> > > > > > that someone could learn about and set up a MOOC without touching the
> > > > > > code.
> > > > > > Eventually, our current set of scripts will be phased out in favor of
> > > > > > this.
> > > > > >
> > > > > > Flask looks really nice. The new app is going to have a medium sized
> > > > > > db.
> > > > > > (
> > > > > > storing emails which have_many scheduled_sends ). With this in mind,
> > > > > > would
> > > > > > you still recommend it, or does it approach the size where django
> > > > > > should
> > > > > > be
> > > > > > used? Is there a good ORM that works nicely with Flask?
> > > > > >
> > > > > > I would really like to make the frontend of this using backbone.js -
> > > > > > especially the email scheduler portion. Think a palette of emails
> > > > > > that
> > > > > > you
> > > > > > can drag onto a calendar. Page refreshes would be nasty for something
> > > > > > like
> > > > > > this IMHO. So with that, having a restful backend definitely makes
> > > > > > sense.
> > > > > >
> > > > > > @Nadeem - I think it does make sense write this in a restful way.
> > > > > > Although
> > > > > > the idea is to eventually make it self sufficient - where all
> > > > > > configuration
> > > > > > is done through the MOOC Maker - we could still design it restfully.
> > > > > > It's
> > > > > > going to be a while before the whole thing is done. And using a JS
> > > > > > frontend
> > > > > > is at least one immediate example of where rest would be useful.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Jan 18, 2013 at 12:48 PM, Nadeem Shabir <nadeem at p2pu.org (mailto:nadeem at p2pu.org)>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hey guys
> > > > > > >
> > > > > > > Just chiming in. My understanding is that the MOOC Maker would
> > > > > > > provide
> > > > > > > an
> > > > > > > interface that allowed someone to enter the sort of configuration
> > > > > > > details
> > > > > > > the current MOOC scripts we have require; in so far as someone (a
> > > > > > > user)
> > > > > > > wanting to set up a mechanical mooc would not need to look at code
> > > > > > > to
> > > > > > > be
> > > > > > > able to do that?
> > > > > > >
> > > > > > > From that pov it certainly makes sense for the MOOC Maker to at
> > > > > > > least
> > > > > > > have
> > > > > > > a consistent rest based back end/api which could be implemented in
> > > > > > > anything;
> > > > > > > the rest based interface makes it easier for others to integrate the
> > > > > > > MOOC
> > > > > > > Maker processes into their own apps ( assuming we are hosting it )
> > > > > > > should
> > > > > > > they wish to. I think the key here ( given that it doesn't seem to
> > > > > > > be
> > > > > > > particularly complex ) might be to get something up and running
> > > > > > > quickly?
> > > > > > > perhaps sticking to python/django might be pragmatic for now? If we
> > > > > > > stick to
> > > > > > > a rest based interface we can always change the underlying
> > > > > > > implementation
> > > > > > > later if we think we would benefit from something different?
> > > > > > >
> > > > > > > cheers
> > > > > > > N
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jan 18, 2013 at 4:46 PM, Jos Flores <josmasflores at gmail.com (mailto:josmasflores at gmail.com)>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hey guys,
> > > > > > > >
> > > > > > > > loads of goodies in the list, as usual. One question: moving the
> > > > > > > > MOOC
> > > > > > > > maker to Django?
> > > > > > > > I understand that python/django is the main tech, and I understand
> > > > > > > > why
> > > > > > > > you'd want to stay away from RoR, but I probably got this wrong,
> > > > > > > > but I
> > > > > > > > thought that the mech mooc was more like a set of scripts than a
> > > > > > > > full
> > > > > > > > blown site... is that correct? or are there other plans for it?
> > > > > > > >
> > > > > > > > Would it make sense to have a separate, restful back end, and a
> > > > > > > > front
> > > > > > > > end written on top of that? Flask maybe on the back end and a
> > > > > > > > JavaScript MV* library in front?
> > > > > > > >
> > > > > > > > cheers,
> > > > > > > > José
> > > > > > > >
> > > > > > > >
> > > > > > > > On 18 January 2013 15:34, Dirk Uys <dirk at p2pu.org (mailto:dirk at p2pu.org)> wrote:
> > > > > > > > > Progress
> > > > > > > > >
> > > > > > > > > Check out http://learn.media.mit.edu - look familiar?
> > > > > > > > >
> > > > > > > > > Sysadmin
> > > > > > > > >
> > > > > > > > > removed spam from badges.p2pu.org (http://badges.p2pu.org)!
> > > > > > > > >
> > > > > > > > > backed up etherpad lite database
> > > > > > > > >
> > > > > > > > > figured out where the code is for etherpad...
> > > > > > > > >
> > > > > > > > > Course UX
> > > > > > > > >
> > > > > > > > > show "fresh additions" on course listing page
> > > > > > > > >
> > > > > > > > > notifications for new users in courses
> > > > > > > > >
> > > > > > > > > MOOC
> > > > > > > > >
> > > > > > > > > MOOC blog and documentation
> > > > > > > > >
> > > > > > > > > MOOC Trello -
> > > > > > > > > https://trello.com/board/mooc/50f414bc44cd6ea45b006dd9
> > > > > > > > >
> > > > > > > > > CSS
> > > > > > > > >
> > > > > > > > > Setup seperate project scaffolding and variables
> > > > > > > > >
> > > > > > > > > Make the documentation page look p2pu nice
> > > > > > > > >
> > > > > > > > > lernanta CSS to be finished fo end of month
> > > > > > > > >
> > > > > > > > > Blog posts
> > > > > > > > >
> > > > > > > > > Good blog Chris
> > > > > > > > >
> > > > > > > > > Priorities
> > > > > > > > >
> > > > > > > > > Small tweaks to Mech MOOC software for Media Lab course
> > > > > > > > >
> > > > > > > > > Sysadmin
> > > > > > > > >
> > > > > > > > > moving pad.p2pu.org (http://pad.p2pu.org) to same server running stats
> > > > > > > > >
> > > > > > > > > updating p2pu.org (http://p2pu.org) OS
> > > > > > > > >
> > > > > > > > > moving badges.p2pu.org (http://badges.p2pu.org) to different server from production
> > > > > > > > >
> > > > > > > > > maybe doing it all using Chef
> > > > > > > > >
> > > > > > > > > Course UX
> > > > > > > > >
> > > > > > > > > feedback from community
> > > > > > > > >
> > > > > > > > > support for old courses to list and update on learn page
> > > > > > > > > (currently
> > > > > > > > > a 1
> > > > > > > > > time
> > > > > > > > > export)
> > > > > > > > >
> > > > > > > > > CSS
> > > > > > > > >
> > > > > > > > > Course UX fixes
> > > > > > > > >
> > > > > > > > > Proposals:
> > > > > > > > >
> > > > > > > > > MOOC Maker RoR -> Django
> > > > > > > > >
> > > > > > > > > Mismatch between org tech stack and MOOC
> > > > > > > > >
> > > > > > > > > MOOC Maker will be implemeted in Django
> > > > > > > > >
> > > > > > > > > DU, CE to plan
> > > > > > > > >
> > > > > > > > > Problems
> > > > > > > > >
> > > > > > > > > DONE (removed) -- Still have this in our google groups footer:
> > > > > > > > >
> > > > > > > > > "Specific topics such as research, web development and course
> > > > > > > > > design
> > > > > > > > > are
> > > > > > > > > discussed in separate working groups:
> > > > > > > > >
> > > > > > > > > http://wiki.p2pu.org/mailing-lists"
> > > > > > > > >
> > > > > > > > > Process
> > > > > > > > >
> > > > > > > > > Trello still underused (is there a MOOC Maker board now?)
> > > > > > > > >
> > > > > > > > > https://trello.com/board/mooc/50f414bc44cd6ea45b006dd9 - sweet!
> > > > > > > > >
> > > > > > > > > Add a person (who takes the lead) to each Trello card
> > > > > > > > >
> > > > > > > > > this shouldn't substitute communication! (agree!)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > p2pu-dev mailing list
> > > > > > > > > p2pu-dev at lists.p2pu.org (mailto:p2pu-dev at lists.p2pu.org)
> > > > > > > > > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> > > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > p2pu-dev mailing list
> > > > > > > > p2pu-dev at lists.p2pu.org (mailto:p2pu-dev at lists.p2pu.org)
> > > > > > > > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > p2pu-dev mailing list
> > > > > > > p2pu-dev at lists.p2pu.org (mailto:p2pu-dev at lists.p2pu.org)
> > > > > > > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > p2pu-dev mailing list
> > > > > > p2pu-dev at lists.p2pu.org (mailto:p2pu-dev at lists.p2pu.org)
> > > > > > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > p2pu-dev mailing list
> > > > > p2pu-dev at lists.p2pu.org (mailto:p2pu-dev at lists.p2pu.org)
> > > > > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > p2pu-dev mailing list
> > > > p2pu-dev at lists.p2pu.org (mailto:p2pu-dev at lists.p2pu.org)
> > > > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> > > >
> > >
> > > _______________________________________________
> > > p2pu-dev mailing list
> > > p2pu-dev at lists.p2pu.org (mailto:p2pu-dev at lists.p2pu.org)
> > > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> > >
> >
> >
> >
> >
> > _______________________________________________
> > p2pu-dev mailing list
> > p2pu-dev at lists.p2pu.org (mailto:p2pu-dev at lists.p2pu.org)
> > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> >
>
> _______________________________________________
> p2pu-dev mailing list
> p2pu-dev at lists.p2pu.org (mailto:p2pu-dev at lists.p2pu.org)
> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p2pu.org/pipermail/p2pu-dev/attachments/20130122/c75ff88a/attachment-0001.html>
More information about the p2pu-dev
mailing list