[p2pu-dev] Tech call notes: 2013-01-17

Tue Jan 22 14:33:21 UTC 2013

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> 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> 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>
> 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> 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>
> 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>
> >> >> 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> wrote:
> >> >>> > Progress
> >> >>> >
> >> >>> > Check out http://learn.media.mit.edu - look familiar?
> >> >>> >
> >> >>> > Sysadmin
> >> >>> >
> >> >>> > removed spam from 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 to same server running stats
> >> >>> >
> >> >>> > updating p2pu.org OS
> >> >>> >
> >> >>> > moving 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
> >> >>> > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> >> >>> >
> >> >>> _______________________________________________
> >> >>> p2pu-dev mailing list
> >> >>> p2pu-dev at lists.p2pu.org
> >> >>> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> p2pu-dev mailing list
> >> >> p2pu-dev at lists.p2pu.org
> >> >> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > p2pu-dev mailing list
> >> > p2pu-dev at lists.p2pu.org
> >> > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> >> >
> >> _______________________________________________
> >> p2pu-dev mailing list
> >> p2pu-dev at lists.p2pu.org
> >> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> >
> >
> >
> > _______________________________________________
> > p2pu-dev mailing list
> > p2pu-dev at lists.p2pu.org
> > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> >
> _______________________________________________
> p2pu-dev mailing list
> 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/f27d5b74/attachment-0001.html>