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 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.<br>
<br>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 (<a href="http://flask.pocoo.org/docs/blueprints/">http://flask.pocoo.org/docs/blueprints/</a>). I 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 since then they changed the project name to Pyramid and developed some other ideas.<br><br>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. <br>
<br>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.<br>
<br>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.<br>
<br>Cheers<br>d<br><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 1:56 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 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>
<div class="HOEnZb"><div class="h5"><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 current<br>
> tech the Mechanical MOOC and we are going to make, what we're tentatively<br>
> calling the MOOC Maker. The MOOC Maker is the long term goal, which is going<br>
> to have a email scheduler, sign up question configuration, etc. In theory so<br>
> that someone could learn about and set up a MOOC without touching the code.<br>
> Eventually, our current set of scripts will be phased out in favor of this.<br>
><br>
> Flask looks really nice. The new app is going to have a medium sized db. (<br>
> storing emails which have_many scheduled_sends ). With this in mind, would<br>
> you still recommend it, or does it approach the size where django should 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 you<br>
> can drag onto a calendar. Page refreshes would be nasty for something like<br>
> this IMHO. So with that, having a restful backend definitely makes sense.<br>
><br>
> @Nadeem - I think it does make sense write this in a restful way. Although<br>
> the idea is to eventually make it self sufficient - where all configuration<br>
> is done through the MOOC Maker - we could still design it restfully. It's<br>
> going to be a while before the whole thing is done. And using a JS 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 an<br>
>> interface that allowed someone to enter the sort of configuration 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 be<br>
>> able to do that?<br>
>><br>
>> From that pov it certainly makes sense for the MOOC Maker to at least have<br>
>> a consistent rest based back end/api which could be implemented in anything;<br>
>> the rest based interface makes it easier for others to integrate the MOOC<br>
>> Maker processes into their own apps ( assuming we are hosting it ) 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 quickly?<br>
>> perhaps sticking to python/django might be pragmatic for now? If we stick to<br>
>> a rest based interface we can always change the underlying 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 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>
</div></div></blockquote></div><br>