This presentation will take a look at the “Python for Everybody” series of courses on the Coursera platform. This course has impacted over 1.3 million students over the last five years. We will look a the history and goals of the course and how the course works to create a learning community. We will show how the free open educational resources (OERs) and book associated with the course have been used by teachers, students, and courses around the world to form a network of educational activities centered around Python. We will also cover briefly the Tsugi (www.tsugi.org) software that is used to build the learning assessments and distribute the OER materials in a way that enables maximum reusability of the materials for other teachers.
As you have been hearing on the Tsugi developer list and in my public presentations, Tsugi is going to build a new approach for adding tools that uses web services rather than a shared database connection across libraries written in multiple languages.
This means that new environments will be easier to build and support over the long-term and Tsugi will be able to provide a tool environment that will meet and exceed the privacy requirements of GDPR and similar privacy oriented measures.
The following efforts that I have put together for Tsugi over the years are now deprecated:
I would also recommend that there be no further investment in Tsugi PHP tools that depend on the Silex framework as it has been deprecated and I don’t expect to upgrade it.
If you have built Tsugi PHP tools that are currently working within Tsugi-PHP – they won’t be broken – what is there currently will be maintained. But some of the deprecated bits will be frozen going forward. If you are building a new tool before the new development model is complete, simply build it in generic (non-framework) PHP like the tools in https://github.com/tsugitools
In time I expect to build new sample code in Laravel, Python, and Node that makes use of the Tsugi APIs and services in time.
These deprecations allow me to “clear the deck” to focus on the next generation and make sure no one starts new work in an Tsugi environment that will not continue to be supported.
(Posted on behalf of Wilma Hodges – Sakai PMC / Community Coordinator)
I’m pleased to announce on behalf of the worldwide community that Sakai 12.5 was released on Nov. 18 and is currently available for downloading  !
Sakai 12.5 has 43 improvements  including
Other areas improved include:
There were 2 security issues fixed in 12.5 (details will be sent to the Sakai Security Announcements list).
Please also note the upgrade information page  for important notes related to performing the upgrade. 2 Quartz jobs need to be run to complete the conversion steps for Sakai 12, including a new one for the Job Scheduler in 12.1.
 Downloading information available at – http://source.sakaiproject.org/release/12.5/
 12.4 Fixes by Tool – https://confluence.sakaiproject.org/display/DOC/12.5+Fixes+by+Tool
Wilma Hodges, Ed.D.
Sakai PMC – Community Coordinator
I love Cloudflare. I use it extensively for any production server I support. I use it for https termination, DDOS mitigation, performance improvement for static content, super flexible DNS management and many more things.
In building my support for IMS LTI Advantage I decided I just needed a server that would run a particular tag or branch of Sakai in production for basic testing rather than pushing everything to master and waiting until the nightly server went through the rebuild.
Here are my notes on putting Sakai behind Cloudflare.
– In CloudFlare under “Overview” Make sure SSL is “Flexible” to keep CloudFlare talking on the backend on port 80
– In CloudFlare, Make a rule for “Automatic HTTPS Rewrites”
– In CloudFlare make a rule that matches
Browser Integrity Check: Off, Always Online: Off, Security Level: Essentially Off, Cache Level: Bypas
– In the Sakai server in the file ./apache-tomcat-8.0.30/conf/server.xml set up the connector like this
This runs an http (port 80) without requiring any key fussing. Since Cloudflare does the SSL we don’t need it in Tomcat. See https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support
Interestingly, one thing I did not need to do was adjust the caching for the “/library” urls in Sakai. Sakai sets all the headers so well that Cloudflare needs no further guidance and neither does the browser. Just as a simple test, the actual un-cached download for the initial page in Sakai Prior to login is 8.8KB. That is *KILO-BYTES*. A normal post-login page in Sakai’s Lessons is 31.4 KB data transferred. Amazingly low bandwidth usage for an enterprise application like Sakai.