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

Jos Flores josmasflores at gmail.com
Mon Jan 21 11:20:57 UTC 2013 

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
>

More information about the p2pu-dev mailing list