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