<div dir="ltr">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.<div>
<br></div><div style>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?†</div>
<div style><br></div><div style>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.†</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 6:20 AM, Jos Flores <span dir="ltr"><<a href="mailto:josmasflores@gmail.com" target="_blank">josmasflores@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dirk,<br>
<br>
I quite like what I read about blueprints, but it's not the only way<br>
of extending flask; It's a bit confusing (to me) how they<br>
differentiate between Extensions (I'd say this would be a package in<br>
Django), and blueprints. After a quick read, it feels like extensions<br>
are designed to deal with things like 3rd party libraries (DBs and the<br>
likes) and blueprints are a way of encapsulating your business logic;<br>
but I might be wrong.<br>
<br>
In any case, there are Extensions for I18n and L10n, and there seems<br>
to be plenty of support for deployment, including full support on<br>
heroku. The extensions list is quite complete, including several<br>
extensions for SQLAlchemy and even MongoDB + SQLAlchemy, OAuth,<br>
openID, Celery, Gravatar... so plenty of choice<br>
(<a href="http://flask.pocoo.org/extensions/" target="_blank">http://flask.pocoo.org/extensions/</a>).<br>
<br>
But anyway, even though discussion is good, the decision should also<br>
consider what's going to make it easier to deliver. Even though Django<br>
can be a bit too big for this, if it makes your lives easier in terms<br>
or context switching, reusing deployment scripts from Lernanta, and so<br>
on, then it can make sense to go with it.<br>
<br>
Do you guys have any timelines to get this off the ground? I'm hoping<br>
to have 3 or 4 free days at the end of February, if that's any good to<br>
you.<br>
<br>
cheers,<br>
Josť<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 21 January 2013 07:47, Dirk Uys <<a href="mailto:dirk@p2pu.org">dirk@p2pu.org</a>> wrote:<br>
> Hi people!!<br>
><br>
> Great discussion! You guys are sharp as always!<br>
><br>
> A few notes from my side:<br>
><br>
> I've used SQL Alchemy before and I'm a big fan. It gives a great alternative<br>
> to Django's ORM and you can do anything between Django's ORM and very<br>
> customized SQL. I've read somewhere that the only reason why Django isn't<br>
> using SQL Alchemy is because it wasn't around when Django started.<br>
><br>
> I've had a brief look at Flask in the past and in general I like their<br>
> philosophy, but I haven't used it much. They have some strange ideas when it<br>
> comes to larger Flask apps (<a href="http://flask.pocoo.org/docs/blueprints/" target="_blank">http://flask.pocoo.org/docs/blueprints/</a>). I<br>
> haven't look at that, maybe it's actually quite good?<br>
><br>
> I've used Pylons before that is similar to Flask in their philosophy. But<br>
> since then they changed the project name to Pyramid and developed some other<br>
> ideas.<br>
><br>
> Django has some things in it that I do not like: database triggers, generic<br>
> relationships using the content type framework, template tags triggering a<br>
> whole bunch of logic and rendering out templates, etc.<br>
><br>
> But, it's up to use to choose if you want to use those features. It is<br>
> completely possible to implement a rest api using Django. The only part of<br>
> Django that you *need* to use is the routing and the views. Everything else<br>
> is up to you - even the ORM.<br>
><br>
> For any application we have to keep i18n, l16n, deployment, testing, backup,<br>
> etc in mind. If we use Flask, SQLAlchemy or backbone.js, we have to make<br>
> sure that we're not creating a maintenance nightmare for ourselves and the<br>
> people who need to manage and translate the applications.<br>
><br>
> Cheers<br>
> d<br>
><br>
><br>
><br>
> On Mon, Jan 21, 2013 at 1:56 AM, Jos Flores <<a href="mailto:josmasflores@gmail.com">josmasflores@gmail.com</a>> wrote:<br>
>><br>
>> Hi Chris,<br>
>><br>
>> This is a personal opinion, but I wouldn't measure the size of the app<br>
>> by the size of the DB, but by the amount of routing you want to do.<br>
>> I have no experience with flask, but have worked with expressjs in<br>
>> node (same idea of easy, out of the box restful routing), and it can<br>
>> get a bit out of hand if your app starts to get bigger. The whole<br>
>> philosophy in node is to have a number of very small services instead<br>
>> of a monolithic system, which is why I'm a bit concerned about using<br>
>> Django for an app that shouldn't be too big in terms of routes and<br>
>> views. It's like driving a bus to work everyday. Especially if you are<br>
>> going to use Backbone; you end up with an MVC on the server and an MV*<br>
>> on the client, when you only really want backbone to load from your<br>
>> API and forget about server generated html.<br>
>> I never got a chance to go deep into backbone; been playing with<br>
>> AngularJS for a couple of weeks, and it feels quite nice, but any of<br>
>> the two (or other options) feels better than using a big monolithic<br>
>> framework like RoR or Django for rendering user views.<br>
>><br>
>> With regards to ORM for flask, SQL Alchemy seems to be thing I hear<br>
>> most about: <a href="http://www.sqlalchemy.org/" target="_blank">http://www.sqlalchemy.org/</a><br>
>> but I haven't used it myself.<br>
>><br>
>> Another jump here, if the app is going to store a high number of<br>
>> emails, a nosql solution could work better than a relational db. If<br>
>> there is a bunch of unstructured data, that is. Just a thought! :)<br>
>><br>
>> cheers,<br>
>> Josť<br>
>><br>
>><br>
>> On 20 January 2013 22:14, Chris Ewald <<a href="mailto:chris@p2pu.org">chris@p2pu.org</a>> wrote:<br>
>> > @Josť - There are other plans for it. Right now we're calling our<br>
>> > current<br>
>> > tech the Mechanical MOOC and we are going to make, what we're<br>
>> > tentatively<br>
>> > calling the MOOC Maker. The MOOC Maker is the long term goal, which is<br>
>> > going<br>
>> > to have a email scheduler, sign up question configuration, etc. In<br>
>> > theory so<br>
>> > that someone could learn about and set up a MOOC without touching the<br>
>> > code.<br>
>> > Eventually, our current set of scripts will be phased out in favor of<br>
>> > this.<br>
>> ><br>
>> > Flask looks really nice. The new app is going to have a medium sized db.<br>
>> > (<br>
>> > storing emails which have_many scheduled_sends ). With this in mind,<br>
>> > would<br>
>> > you still recommend it, or does it approach the size where django should<br>
>> > be<br>
>> > used? Is there a good ORM that works nicely with Flask?<br>
>> ><br>
>> > I would really like to make the frontend of this using backbone.js -<br>
>> > especially the email scheduler portion. Think a palette of emails that<br>
>> > you<br>
>> > can drag onto a calendar. Page refreshes would be nasty for something<br>
>> > like<br>
>> > this IMHO. So with that, having a restful backend definitely makes<br>
>> > sense.<br>
>> ><br>
>> > @Nadeem - I think it does make sense write this in a restful way.<br>
>> > Although<br>
>> > the idea is to eventually make it self sufficient - where all<br>
>> > configuration<br>
>> > is done through the MOOC Maker - we could still design it restfully.<br>
>> > It's<br>
>> > going to be a while before the whole thing is done. And using a JS<br>
>> > frontend<br>
>> > is at least one immediate example of where rest would be useful.<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > On Fri, Jan 18, 2013 at 12:48 PM, Nadeem Shabir <<a href="mailto:nadeem@p2pu.org">nadeem@p2pu.org</a>> wrote:<br>
>> >><br>
>> >> Hey guys<br>
>> >><br>
>> >> Just chiming in. My understanding is that the MOOC Maker would provide<br>
>> >> an<br>
>> >> interface that allowed someone to enter the sort of configuration<br>
>> >> details<br>
>> >> the current MOOC scripts we have require; in so far as someone (a user)<br>
>> >> wanting to set up a mechanical mooc would not need to look at code to<br>
>> >> be<br>
>> >> able to do that?<br>
>> >><br>
>> >> From that pov it certainly makes sense for the MOOC Maker to at least<br>
>> >> have<br>
>> >> a consistent rest based back end/api which could be implemented in<br>
>> >> anything;<br>
>> >> the rest based interface makes it easier for others to integrate the<br>
>> >> MOOC<br>
>> >> Maker processes into their own apps ( assuming we are hosting it )<br>
>> >> should<br>
>> >> they wish to. I think the key here ( given that it doesn't seem to be<br>
>> >> particularly complex ) might be to get something up and running<br>
>> >> quickly?<br>
>> >> perhaps sticking to python/django might be pragmatic for now? If we<br>
>> >> stick to<br>
>> >> a rest based interface we can always change the underlying<br>
>> >> implementation<br>
>> >> later if we think we would benefit from something different?<br>
>> >><br>
>> >> cheers<br>
>> >> N<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Fri, Jan 18, 2013 at 4:46 PM, Jos Flores <<a href="mailto:josmasflores@gmail.com">josmasflores@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> Hey guys,<br>
>> >>><br>
>> >>> loads of goodies in the list, as usual. One question: moving the MOOC<br>
>> >>> maker to Django?<br>
>> >>> I understand that python/django is the main tech, and I understand why<br>
>> >>> you'd want to stay away from RoR, but I probably got this wrong, but I<br>
>> >>> thought that the mech mooc was more like a set of scripts than a full<br>
>> >>> blown site... is that correct? or are there other plans for it?<br>
>> >>><br>
>> >>> Would it make sense to have a separate, restful back end, and a front<br>
>> >>> end written on top of that? Flask maybe on the back end and a<br>
>> >>> JavaScript MV* library in front?<br>
>> >>><br>
>> >>> cheers,<br>
>> >>> Josť<br>
>> >>><br>
>> >>><br>
>> >>> On 18 January 2013 15:34, Dirk Uys <<a href="mailto:dirk@p2pu.org">dirk@p2pu.org</a>> wrote:<br>
>> >>> > Progress<br>
>> >>> ><br>
>> >>> > Check out <a href="http://learn.media.mit.edu" target="_blank">http://learn.media.mit.edu</a> - look familiar?<br>
>> >>> ><br>
>> >>> > Sysadmin<br>
>> >>> ><br>
>> >>> > removed spam from <a href="http://badges.p2pu.org" target="_blank">badges.p2pu.org</a>!<br>
>> >>> ><br>
>> >>> > backed up etherpad lite database<br>
>> >>> ><br>
>> >>> > figured out where the code is for etherpad...<br>
>> >>> ><br>
>> >>> > Course UX<br>
>> >>> ><br>
>> >>> > show "fresh additions" on course listing page<br>
>> >>> ><br>
>> >>> > notifications for new users in courses<br>
>> >>> ><br>
>> >>> > MOOC<br>
>> >>> ><br>
>> >>> > MOOC blog and documentation<br>
>> >>> ><br>
>> >>> > MOOC Trello - <a href="https://trello.com/board/mooc/50f414bc44cd6ea45b006dd9" target="_blank">https://trello.com/board/mooc/50f414bc44cd6ea45b006dd9</a><br>
>> >>> ><br>
>> >>> > CSS<br>
>> >>> ><br>
>> >>> > Setup seperate project scaffolding and variables<br>
>> >>> ><br>
>> >>> > Make the documentation page look p2pu nice<br>
>> >>> ><br>
>> >>> > lernanta CSS to be finished fo end of month<br>
>> >>> ><br>
>> >>> > Blog posts<br>
>> >>> ><br>
>> >>> > Good blog Chris<br>
>> >>> ><br>
>> >>> > Priorities<br>
>> >>> ><br>
>> >>> > Small tweaks to Mech MOOC software for Media Lab course<br>
>> >>> ><br>
>> >>> > Sysadmin<br>
>> >>> ><br>
>> >>> > moving <a href="http://pad.p2pu.org" target="_blank">pad.p2pu.org</a> to same server running stats<br>
>> >>> ><br>
>> >>> > updating <a href="http://p2pu.org" target="_blank">p2pu.org</a> OS<br>
>> >>> ><br>
>> >>> > moving <a href="http://badges.p2pu.org" target="_blank">badges.p2pu.org</a> to different server from production<br>
>> >>> ><br>
>> >>> > maybe doing it all using Chef<br>
>> >>> ><br>
>> >>> > Course UX<br>
>> >>> ><br>
>> >>> > feedback from community<br>
>> >>> ><br>
>> >>> > support for old courses to list and update on learn page (currently<br>
>> >>> > a 1<br>
>> >>> > time<br>
>> >>> > export)<br>
>> >>> ><br>
>> >>> > CSS<br>
>> >>> ><br>
>> >>> > Course UX fixes<br>
>> >>> ><br>
>> >>> > Proposals:<br>
>> >>> ><br>
>> >>> > MOOC Maker RoR -> Django<br>
>> >>> ><br>
>> >>> > Mismatch between org tech stack and MOOC<br>
>> >>> ><br>
>> >>> > MOOC Maker will be implemeted in Django<br>
>> >>> ><br>
>> >>> > DU, CE to plan<br>
>> >>> ><br>
>> >>> > Problems<br>
>> >>> ><br>
>> >>> > DONE (removed) -- Still have this in our google groups footer:<br>
>> >>> ><br>
>> >>> > "Specific topics such as research, web development and course design<br>
>> >>> > are<br>
>> >>> > discussed in separate working groups:<br>
>> >>> ><br>
>> >>> > <a href="http://wiki.p2pu.org/mailing-lists" target="_blank">http://wiki.p2pu.org/mailing-lists</a>"<br>
>> >>> ><br>
>> >>> > Process<br>
>> >>> ><br>
>> >>> > Trello still underused (is there a MOOC Maker board now?)<br>
>> >>> ><br>
>> >>> > <a href="https://trello.com/board/mooc/50f414bc44cd6ea45b006dd9" target="_blank">https://trello.com/board/mooc/50f414bc44cd6ea45b006dd9</a> - sweet!<br>
>> >>> ><br>
>> >>> > Add a person (who takes the lead) to each Trello card<br>
>> >>> ><br>
>> >>> > this shouldn't substitute communication! (agree!)<br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > _______________________________________________<br>
>> >>> > p2pu-dev mailing list<br>
>> >>> > <a href="mailto:p2pu-dev@lists.p2pu.org">p2pu-dev@lists.p2pu.org</a><br>
>> >>> > <a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
>> >>> ><br>
>> >>> _______________________________________________<br>
>> >>> p2pu-dev mailing list<br>
>> >>> <a href="mailto:p2pu-dev@lists.p2pu.org">p2pu-dev@lists.p2pu.org</a><br>
>> >>> <a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> p2pu-dev mailing list<br>
>> >> <a href="mailto:p2pu-dev@lists.p2pu.org">p2pu-dev@lists.p2pu.org</a><br>
>> >> <a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
>> >><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > p2pu-dev mailing list<br>
>> > <a href="mailto:p2pu-dev@lists.p2pu.org">p2pu-dev@lists.p2pu.org</a><br>
>> > <a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
>> ><br>
>> _______________________________________________<br>
>> p2pu-dev mailing list<br>
>> <a href="mailto:p2pu-dev@lists.p2pu.org">p2pu-dev@lists.p2pu.org</a><br>
>> <a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> p2pu-dev mailing list<br>
> <a href="mailto:p2pu-dev@lists.p2pu.org">p2pu-dev@lists.p2pu.org</a><br>
> <a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
><br>
_______________________________________________<br>
p2pu-dev mailing list<br>
<a href="mailto:p2pu-dev@lists.p2pu.org">p2pu-dev@lists.p2pu.org</a><br>
<a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
</div></div></blockquote></div><br></div>