Archive for the ‘Uncategorized’ Category.

Building an “On Ramp” Curriculum for Tech Jobs

This is another one of those blog posts where someone asked me a question and I wrote an essay as my answer. I figured others might find it interesting so I reproduce it here. The question was also asked of my colleague Colleen van Lent so in my response, I talked about our collective approach.

Building an “On Ramp” Curriculum for Tech Jobs

The changing shape of the workplace towards software and web is something the Colleen and I talk about all the time and spend a lot of our time trying to lay the groundwork to prepare people for this new economy through every chance we get.

We are both highly motivated to build educational experiences that are “on-ramps” that build strong foundations for further tech learning.

So far our efforts have been in the following areas:

Teach broad “on-ramp” classes to our UMSI on campus students like

  • SI502 – Intro Python
  • SI539 – Intro Web Design
  • SI664 – Intro Web Development.

We have taken the material from these courses and made Coursera specializations:

We build these three specializations with an eye to making a free curriculum that anyone can master regardless of background and prepare them for an entry level web programming job We hope they would be able to fix bugs, write new code with supervision, and do QA but probably not ready to start their own professional quality software project on their own. Because we focus on “on ramp”, we want to get a wide range of ages and skills to the “starting line” where they can begin to learn more on their own.

These Coursera specializations are very successful and Coursera is doing a great job of providing certifications that the industry is starting to accept as helpful signals for hiring. These certifications have been the primary source of revenue for Coursera. My Python specialization has over 200K completions over the past 2 years. It is one of the most popular and highest revenue specializations on Coursera.

We are also both very committed to free and open access because we feel that a career in web applications is a great way for those with lower financial means to improve their lives. But increasingly Coursera is putting more and more of the content of a specialization behind a subscription based paywall. While Coursera allows for financial aid, some students do not want to apply for aid. Also any financial barrier effectively blocks students in certain countries.

To insure my content remains 100% free, I have built my own web sites to insure that students can access my content and assessments at no charge. Here are my web sites:

  • Python For Everybody –
  • Web Applications For Everybody – – this is roughly what the Coursera specialization will look like in the Fall

These sites are effectively stand-alone MOOC providers using my Tsugi software. The sites track student progress and even award badges as students make progress. Colleen has not built a separate site for her course materials but that is something I would love to see happen to complete the set.

In terms of ascribing “meaning” to credentials, Coursera has spent 100’s of millions of dollars to build brand awareness and has 25M+ students taking courses and probably >100M certificates in LinkedIn. Coursera is five years old and has several TED talks (1, 2). And at this point – with all of that – Coursera certifications are becoming gradually accepted as a moderately reliable signal of suitability for employment.

Coursera certificates are not yet in the same category as Microsoft Certified Professional or Cisco Network Professional certificates. Those are very detailed and very stringent. Ultimately with all that Colleen and I do, if you get all 15 certificates from all three of our specializations – it is like you took 3 community college courses and got at least a “B”. This turns out to be a wonderful way to get students confident enough to play with tech in their current jobs or prepare them to learn more.

Thoughts on Sessions versus Self-Paced On Coursera

I was asked by a colleague to summarize my thoughts on whether courses should be session based of self-paced on Coursera.

It depends on a few things:

  • If there is low enrollment, self-paced works better because the forums feel less “empty” to a new student. If you are starting a new scheduled session every few weeks and there are only a few hundred students – if can be problematic.
  • One disadvantage of instructor paced is that there is a temptation to put “events” at the end of classes – special instructor hangouts, etc etc. We initially felt that Coursera Capstone courses needed this special attention for each session. While these events are fun the first time a course is taught and when enrollment is high, after a while they are less fun – especially when they happen every 5-6 weeks and few students show up. We moved toward having events for the “whole specialization” and not just for students currently enrolled – that way when you have live or other special events you get the most benefit for the investment of faculty time. My office hours work perfectly for this. Every 8 or so weeks I meet my students in a bar, make a simple YouTube video and send it around. Reasonable effort – high visibility.
  • A key to scheduled is the ability to “roll forward” if a student drops out – Coursera is masterful at this. There is a “session” but if you drop out, and a bit later a new session starts you get an email that says – “Hey – we miss you – a new session is just starting and if you join now your homework results will roll forward to that session so you start part-way done”. Brilliant blend of self-paced and scheduled.

In summary, we went from 100% scheduled 10 week courses 3x per year, to 100% self-paced with five 8-week courses, to this hybrid “scheduled but with easy re-enrollment”. For high enrollment courses like our Python course (1400 new students per week), the semi-scheduled is the best arrangement. For my Internet History low-enrollment course (146 new students per week) – self paced seems to be the right balance.

Upcoming Tsugi things – and a switch to version 0.4.x

I am moving towards a non-upwards compatible change in Tsugi/Koseu if you are using it for a web site like

As I increasingly move towards defining and developing new Tsugi tools and UI with Silex, I am moving functionality like badges.php, login.php, etc into Silex Controllers. The new URLs are sooo pretty and can be mounted at any point in a web hierarchy.

At this moment in the code base, I have duplicated nearly all of the Koseu functionality in the tsugi folder into Silex Controllers and Templates – but I have not yet removed the old files.

The problem is that to use Twig 2.0, I am forced to host in a PHP 7.0 environment. At this point all the legacy files (badges.php, etc) work fine in PHP 5 – but the fancy new “pretty URL” controllers demand PHP 7.

I am going to go for a while with both in the code base – but at some point I will tag the “legacy included” code and then wipe out the legacy code – and at that point Koseu and Tsugi will demand PHP 7.

Like always, when this happens, before anything is deleted, I will snap a 0.3.x tag and then increment the version of tsugi-php, tsugi, and koseu-php to 0.4 and you can switch to a tag and if need be, we can even do a “legacy branch” later if we need to back-port stuff later.

At this moment, my timing is stuck behind getting a PHP 7 environment from UMich – which might be a month or so :(

More later and comments welcome.

Moving “Python for Everybody” to Python 3

We have been teaching the Coursera Python for Everybody specialization for almost two years now and the previous course (Programming for Everybody in Python) started in early 2014. Since 2014, we have touched 1.4 million learners with over 200,000 learners completing at least one course.

We are planning on converting the all five courses in the specialization to Python 3 by June 26, 2017. Things may come up to adjust that date but at this point it looks pretty solid.

This has been about two years of effort with a new textbook, all new slides, a new autograder, and a new web site at, new lecture recordings, new audio podcasts … you get the picture. Actually uploading it all to Coursera turns out to be the easiest part :)

Also, we have unlocked the fifth course (the capstone) and removed the pre-requisite requirements for the capstone. This allows students to take any of the five classes in the specialization in any order.

Why Python 3?

While there are many in the Python community still using Python 2 and many Python libraries that are Python 2, I think the time has come to teach new programmers Python 3. And if you learn Python 3 and then have to go back a bit to Python 2 in a job situation, think of it as learning a new language. But to me the time has come for teachers to teach Python 3.

Ultimately, Python 3 is a superior language and the language that will be suitable for a very long time. Probably the largest non-negotiable feature is the solid support for Unicode and all character sets. Python cannot be successful if it is only fully functional in Latin/ASCII character sets.

Why Not do Both?

We toyed with this idea for a while, letting Coursera students choose between the versions – but the effort required to keep everything working in both languages would stretch our teaching and support teams too thin. A Coursera course requires more effort than a web site. Five courses are challenging enough – if we supported both languages, we would be supporting 10 courses on Coursera.

Transition (i.e. Yikes my next class is in Python 3!)

We will be switching all of the five classes to Python 3 at the same time. This means that you may have taken one or more courses in Python 2 and then “poof” you are in Python 3 in the next course. If you encounter Python 3 for the first time in Course 2 (Data Structures) or Course 3 (Web Data) – the only difference you’ll find in the content for these courses will be thatprint with parenthesis and raw_input() becomes input().

Python 2.x:

    name = raw_input('Enter your name: ')
    print name

Python 3.x:

    name = input('Enter your name: ')

In Course 3 (Using Python to access web data) you will start to see the changes to the Python 3 urllib module and how we work with Beautiful Soup. We provide you with all new sample code in Python 3.

If your first encounter with Python 3 is in Course 4 (Databases) or the Course 5 (Capstone), you will need to learn about encode() and decode() and how they work with data in databases and across the network. To help with students who took Course 3 or 4 in Python 2, we have added a special lecture (Unicode in Python 3) that covers these topics in Courses 4 and 5.

Where Are the Python 2 Materials?

The Python for Informatics textbook will continue to be available on Amazon. In particular, the Chinese, Spanish and Korean versions of the Python 2 textbook will continue to be available. There are no translations of the Python 3 textbook so far.

The web site will continue to exist to support the Python 2 book. If there is interest, I can add the Python 2 auto-graders to that web site once the conversion of the Coursera course is complete.


There are so many people who helped make the conversion to Python 3 possible. Here are a few that I need to thank: Sue Blumenberg, Elliott Hauser, Tamara Brunnock, Mihaela Mack, Stephen Catto, Alex Hancook, Noni Korf, Jen Vetter, Bryon Maxey, Tim O’Brien, Stephanie Haley, Sabah Baxamoosa, Laura Wandres, and many others.

A better .htaccess for Silex/Symfony Applications

I am playing with Silex / Symfony for writing Tsugi applications and had to come up with a better .htaccess file because my old one did not route the “/” into the fallback resource correctly.

The problem is that there is a directory for “/” that stops the final rewrite url from happening because of the (red) RewriteCond.

So we add two very explicit rewrite statements (green) to handle the “standalone slash” and the “standalone slash followed by a query string”.

    <IfModule mod_rewrite.c>
        RewriteEngine on
        RewriteRule ^ - [E=protossl]
        RewriteCond %{HTTPS} on
        RewriteRule ^ - [E=protossl:s]

        # Root folder all alone
        RewriteRule "^/$" silex.php [L]
        # Root folder with GET parameters
        RewriteRule "^/?.*$" silex.php [L]

        RewriteRule "(^|/)\." - [F]
        RewriteCond %{REQUEST_FILENAME} !-f

        RewriteCond %{REQUEST_FILENAME} !-d

        RewriteCond %{REQUEST_URI} !=/favicon.ico
        RewriteRule ^ silex.php [L]
    <IfModule !mod_rewrite.c>
        FallbackResource silex.php

I have a feeling it won’t work well for the FallbackResource – as it will find the “.” folder and not “fall back”. So this kind of means I need mod_rewrite.

Alternatively just rename ‘silex.php’ to ‘index.php’ if I don’t want to have a separate index.php.


New Sakai Project Management Committee (PMC) Members

I am pleased to announce four new members elected to the Sakai Project Management Committee (PMC). Here are the new members and the nomination statements for each:

Wilma Hodges, Longsight
Wilma has been a long-time community supporter and Apereo Fellow. She leads the documentation effort, participates in the Apereo FARM effort, leads the Sakai Virtual Conference, and participates in the Sakai Marketing effort and other community activities.

Dede Hourican, Marist
A long term community member, Dede has most recently directed focus on quality assurance with participation in the Sakai QA committee bringing a team of Marist student employees to bear on the process and teaches them about open source software and global communities and building future sakaigers.

Diego del Blanco, Unicon
Diego has been very active in the Sakai community for some time now and Apereo Fellow. He has been a regular attendee of the weekly calls, made significant contributions to Sakai 11 and put in some large features for 12.

Shawn Foster, Western
Shawn is highly active on community calls, provides code contributions, and is tightly connected with the very important usability and accessibility efforts within the Sakai community.

PMC membership is reflective of significant contributions to the community and a dedication to the shared goals of the Sakai community.

In terms of what PMC membership “means”, the PMC members are already active members in the various groups in the Sakai/Apereo community (QA, Core Team, Marketing, FARM, Accessibility, Teaching and Learning, etc.). Most of the decisions about Sakai are made in those groups without any need for the PMC to take a vote or render an opinion because we believe that those closest to the actual work should make decisions regarding the work whenever possible.

The PMC[1] gets involved when there is a significant or broader issue or a decision needs to be made regarding Sakai’s direction or resource expenditure by Apereo[2] on behalf of Sakai [3]. The PMC does all of its work in full view of the community on a public list[4] except for votes on new PMC members.

Please join me in thanking these new PMC members for their past, present, and future contributions to Sakai and welcoming them as the newest members of the Sakai PMC[5].

Should ICLAs be Required of Every Contributor?

Update: Title changed from “Committer” to “Contributor” based on a suggestion from Andrew Petro (see comments)

In Apereo/Sakai there is discussion of whether or not we need to doggedly require Individual Contributor License Agreements (ICLAs) from every person who sends in a simple github PR. It is generally agreed that if someone will be making significant contributions we need an ICLA – but many (myself included) feel that an ICLA is not necessary for a simple submitted patch. The issue is that this leaves a grey area and soe folks stay a bit conservative on this.

Andrew Petro did some research on this and here are his notes. I keep them here for my own reference.

Here is the thread where we discussed this:!topic/licensing-discuss/c1puG3RKZcA

Since this post, CLAs have come up a few times on Apache legal-discuss@, including in July when I brought up Apereo’s desire for a canonical position.

In February 2017, “it is considered good practice to collect individual CLAs even if the contributors are not committers. Strictly speaking this is unnecessary”. That is, Committers and Projects via their PMCs may require CLAs of Contributors rather than just only of Committers, and it may be a good practice for them to do this under some circumstances, but Apache does not strictly require this. Also, this post again confirmed that while it is a good practice for Committers to secure Corporate Contributor License Agreements of their employers, this is a judgment call on the part of the Contributor.

In December 2016, “our IP provenance relies on both our license, our ICLA/CCLAs, and the fact that we have written policies that define who can be a committer and how PMCs can make releases. It’s usually good if a code author (or someone who could otherwise legally sign an ICLA in terms of granting us the right licensing rights to that code) actually submits the work to some Apache project before we put it in a release.” That is, it’s sufficient that an ICLA-signatory Committer actually merges the code into the canonical codebase.

In August 2016, “To avoid the risk associated with clever or large contributions, most PMCs request a formal ICLA to be filed.” Which is to say that some do not, and that therefore Apache does not require that projects do so; individual PMCs get to locally decide when to go beyond requiring ICLAs of Committers to require it of a Contributor in the context of a given Contribution.

In August 2016, on this very topic, “I don’t see that there’s a ‘canonical position’ that can exist.” and “Stating my understanding of the Apache policy – Apache requires ICLAs of its committers, uses ICLAs or a software license ( for exceptional contributions from contributors and generally relies on clause 5 of theApache License 2.0 for other contributions from contributors.”

There have been opportunities for someone to argue that ICLAs are required of all Contributors, and that position has not been argued on legal-discuss@.

I think it’s also looking likely that this is as canonical a position as one can get from Apache on this matter.

Silex Bridge to Old-Style PHP Sessions ($_SESSION)

I am exploring the Silex framework. I am trying to gently evolve a very nice app from “old school PHP” to “new school PHP”. I have chosen Silex (atop Symfony) as my first framework to try. I like Silex so far because it helps me without lecturing me. I cannot rewrite my whole app overnight – I need to evolve to a Silex App, one feature at a time.

This code uses the Symfony PhpBridgeSessionStorage – and it makes me very happy.


// http://localhost:8888/silex/hello/bob

use Symfony\Component\HttpFoundation\Session\Session;
use Symfony\Component\HttpFoundation\Session\Storage\PhpBridgeSessionStorage;

require_once "vendor/autoload.php";

$session = new Session(new PhpBridgeSessionStorage());
$app = new Silex\Application();
$app['session'] = $session;

$app->get('/hello/{name}', function ($name) use ($app) {
    // New Session
    if ( $app['session']->has('y') ) {
        $app['session']->set('y', $app['session']->get('y')+1);
    } else {
        $app['session']->set('y', 20);

    // Read and write old session
    if ( isset($_SESSION['x'])) {
    } else {
        $_SESSION['x'] = 42;

    return "<p>Hello $name</p>\n";


Sakai Release History (From Matt Jones)

As the Sakai community discuss the timing for the release of Sakai 12, Matt Jones of LongSight went back into history and summarized Sakai release activity for the past 5 years to help inform our plans for the Sakai 12 schedule.

I would add to the information that Matt shares below that Sakai 2.9 and Sakai 11 made a lot of forward progress with new/revised UI/UX features and Sakai 2.8, 10, and 12 put a lot of effort into performance, reliability, and scalability and contained less new UI/UX.

I am recording Matt’s notes it here so I don’t lose them. He did a lot of work to get these details. It also shows how much community effort (and Matt Jones work) work goes into Sakai releases.

From Matt Jones:

I looked at all of the past releases, some takeaways from below

  • The branch to release for the previous two releases (10 and 11) was about the same, 5 months. 10 cut earlier and was released earlier than 11.
  • Even though no release has done branch to (actual) release faster than 5 months, we have planned 2 months for 12
  • The time from .0 to .1 for 11 was 1 month, but for previous releases previously was longer, about 3 months (which is our ideal)
  • The longest time from branch to release was 2.9, almost 13 months
    Sakai 2.8 actually had a Q1 release with Q4 branch. 2.9 was on track for the same but delayed significantly (And ended up with a Q4 release)

Historically there looks to be about a 1-2 month delay from plan to release
Sakai release history 2.8 – 12

Sakai 12
Branch cut: Earliest possible seems 2017-03-22
Release planned: 2017-05-19
Actual release: ???

Sakai 11
Branch cut: 2016-02-17
Release planned: 2016-06-24
Actual released: 2016-07-23
.1 release 2016-08-13

Sakai 10
Branch cut: 2014-01-30
Release planned: 2014-04-30
Actual release: 2014-06-27
.1 release 2014-08-21

Sakai 2.9
Branch cut: 2011-10-17
Release planned: 2012-06-15 (This may have been planned for earlier)
Actual release: 2012-11-09
.1 release 2013-02-07

Sakai 2.8
Branch cut: 2010-09-25
Release planned: 2011-03-01
Actual release: 2011-04-18
.1 release 2011-10-12

What is Tsugi?

tsugi-knifeTsugi is open source software that makes it practical to quickly build and deploy learning sites, tools, and content that is seamlessly integrated into Learning Management Systems using the latest interoperability standards. Tsugi makes it possible for publishers of educational software or content to implement integration with major learning management systems with a relatively low level of developer effort when compared with researching and implementing interoperability standards from scratch.

Who might benefit from Tsugi?

  • Campus IT staff can deploy an extensible local “App Store” integrated into their local learning management system. The App Store can host Tsugi tools developed locally or install and host Tsugi tools from a wide range of sources including free / open source tools provided by the Tsugi project.
  • A faculty member can find and integrate content and tools from their local App Stores and/or other Tsugi-based Learning Object Repositories anywhere on the Internet into their courses.
  • For faculty or campuses producing Open Educational Resources (OER) Tsugi allows easy publishing of reusable and remixable OER content and tools that can seamlessly be imported and/or integrated into learning management systems.
  • For book authors, it is possible to produce a web site for the book that includes supporting materials, quizzes, interactive exercises, and other learning content. Content hosted in the Tsugi Learning Object Repository can be seamlessly integrated into LMS systems, giving independent book authors a way to provide their additional materials and software in a form that is as good or better than integrations provided by the (very expensive) publishers.
  • Instructional designers can work with local developers to quickly develop interoperable learning tools that meet the pedagogical needs of faculty and students. With the productivity gains of the Tsugi library it is feasible to develop unique applications down to the granularity of a particular course. Developer effort goes into building the tool and not developing and debugging low-level code to support interoperability standards.
  • Tsugi is a stand-alone MOOC platform. For a school, individual or even professional society, Tsugi can be deployed on inexpensive hardware to support 100K+ users around the world per course. Tsugi has a built in login, grade-book, badging, and other facilities that allow the quick development and deployment that make it quite simple to share content MOOC-style.
  • Edtech startups can save resources and quickly develop a Minimum Viable Product (MVP) using Tsugi, put it in production and begin showing it to their customers and investors. WHile they may chose to ultimately build their own ground up implementation of IMS standards, since Tsugi is open source they have a nice roadmap and test harness for their own implementation.
  • For a mainstream LMS vendor, encouraging their customers to use Tsugi means that locally developed code at each of their institutions will be consistent, secure, and reliable. LMS vendors will not each have to separately develop “How to make an LTI Tool” documentation – they can just promote the use of Tsugi and leave all the developer training to Tsugi.

What is Tsugi?

Tsugi is a set of flexible “Lego blocks” that work very well together. To meet all of the use cases of Tsugi described above, adopters just pick and choose the elements of Tsugi that are needed.

The primary elements of Tsugi are as follows:

  • A set of library routines that implement standards like IMS Learning Tools Interoperability, IMS Common Cartridge, IMS Content Item, and other standards as they become available. The Tsugi library is broken into three layers:
    • The lowest layer is a direct implementation of each of the standards.
    • The second layer is an “opinionated” API layer that prescribes a relational database model, conventions for the use of session data, compensation for slight differences in LMS implementations of various standards, performance improvements, and reliability improvements taking advantage of the underlying data model.
    • The third layer provides an “UI API” that implements the Tsugi style guide so all Tsugi modules look and function similarly from a UI perspective. As we move from 10’s to 1000’s of independently developed tools, consistency in look and feel across tools from multiple sources will be important.
  • Tsugi has a management console that supports the Tsugi App Store use cases including Tsugi Module installation, providing facilities for API key management as well as the ability to take incoming requests for access keys to hosted Tsugi modules. The management console also makes it so all of the installed modules can be integrated into an LMS using LTI 1.x, LTI 2, or IMS Content Item.
  • A faculty member can develop their course content and host it using Tsugi and then simply import that content into their course shell at the beginning of each semester.
  • Tsugi can also be embedded into a public-facing web site providing learning management system functionality for the web site. When Tsugi is embedded into a web site, it can publish the content and tools hosted on the site as a set of interoperable learning objects using the IMS Common Cartridge or IMS Content Item specifications. Tsugi can transform a static educational content web site into an interoperable Learning Object Repository and a learning community.
  • Tsugi can be further configured to turn a web site into a stand-alone MOOC by supporting login, activity tracking, tool launching, a map of students who are part of the course, and a flexible automated badging system that automatically issues badges that contain the necessary meta data and validation to comply with the Open Badge Initiative (OBI). Examples of this use case include: Web Applications for Everybody and Python for Everybody.

Getting Started with Tsugi

We are developing a free online course (a.k.a. MOOC) to train Tsugi developers and adopters at The training will be a series of modules with assignments, quizzes and peer-graded activities. As developers complete their training they will be automatically awarded OBI compliant badges showing their progress and accomplishments.

And yes, this is kind of “meta” since we are using Tsugi to build a web site that will train Tsugi developers. Why not? Tsugi is the simplest way to build a stand alone training web site. Oh and of course, since Tsugi is also a Learning Object Repository, anyone can integrate the Tsugi training materials into their local LMS and teach their own Tsugi course. It is indeed “Turtles all the way down” with Tsugi.

There is already a set of exercises with sample code and sample implementations suitable for a workshop or short course on Tsugi.

Example Tsugi Tools

There is already an effort within the Apereo foundation to build, review, and share open source Tsugi tools. A number of simple tools are already available in the TsugiTools github repository:

  • A simple attendance tool – This is kept simple so it can be used used as an example of how to build a Tsugi tool
  • A quizzing tool that supports the GIFT format pioneered by Moodle. GIFT is a way to author quizzes using a simple plaintext syntax.
  • A course map that allows students in a class to place themselves on a map an optionally release information about themselves on the map.
  • A peer-grading application the implements a “more social” approach to peer grading. This is quite useful for assessments in MOOCs or social learning situations where there are flexible deadlines and participants are experiencing course material at their own pace.
  • A simple way to create Slack channels for a class and invite all the students to the Slack channel.

These tools from the TsugiTools repository can be automatically installed into a Tsugi instance using the Tsugi application management console.

Another set of Tsugi tools are autograders – but these are generally narrowly focused on one topic and not part of the tsugitools repository.

What Tsugi “Is Not”?

Tsugi is not an enterprise Learning Management System like Sakai, Moodle, Blackboard, Canvas or Desire2Learn. Tsugi works with and enhances all of those LMS’s.

An Enterprise LMS is a “walled garden” shielding course material from anyone except those students and faculty associated with a particular course session. An important use case for an Enterprise LMS is to create a “course shell” for every course section that is taught on a campus. Those course shells are important while the class is in session but become archival as soon as the session is completed. Many schools “clean out” course shells that are older than a certain date. All the courses in an Enterprise LMS are at the same URL – the courses exist “within” the LMS. Faculty / instructional designers must design their student experience using whatever limited facilities the LMS has in terms of content authoring.

When Tsugi is embedded into a web site the use cases are quite different. With Tsugi, each course or set of learning content has its own URL and can be separately hosted (this is why a single Tsugi course can easily scale to >100K users). While Tsugi is highly opinionated as to how tools look and feel, when Tsugi is embedded into a web site, the core content of the web site that surrounds Tsugi is simply web content and can be authored and styled in any way that the owner likes. The web site can “inject” style into Tsugi tools hosted by and used by the web site. It means learning content web sites can be beautiful, engaging, and easily searched. The web site can make use of any of the latest HTML/CSS/JavaScript technologies. Tsugi merely “plugs into” and adds value to the beautiful educational content on the web site.

A Tsugi web site is intended to make its materials available “forever” – long after the end of one semester. A Tsugi web site becomes a source of materials that might be in use in hundreds of classes around the world. Search engines can “find” Tsugi learning content sites.

Programming Languages Supported

Given that Tsugi is intended to level the playing field and make it possible for thousands of new developers to learn to build sophisticated learning tools without requiring a lot of programming experience, Tsugi implements most functionality in PHP first. Choosing PHP also allows small to medium Tsugi installations to run in the commonly available low-cost hosting plans with minimum hardware requirements. Choosing PHP also broadens the developer community that can contribute to, understand and/or expand the core functionality of Tsugi.

But PHP is less popular among professional programmers so there are Tsugi implementations that support multiple programming languages and web environments. Each of these is at a different level of functionality and will be expanded as there is interest.

  • Tsugi Java shares its low-level API implementation with Sakai. It supports LTI 1.x and IMS Content Item. Tsugi Java also has the second-level “opinionated API” implemented for LTI 1.x launches.
  • Tsugi Node has support for the LTI launches with much of the the LTI 1.x standard implemented at both the low level and the “opinionated level”.
  • There is a simple bridge to allow one to use the Tsugi PHP libraries in Laravel applications.

All these implementations depend on the PHP-based management console for services beyond LTI 1.x launches. If there is interest we can build management consoles for other languages.

There is emerging interest and discussions in developing versions of Tsugi for Python/Tornado, Python/Flask, and Rails but these projects have not yet started.

Where is Tsugi Going Next?

Tsugi is still a relatively small open source project and so the roadmap is defined by those who are using Tsugi as they have new needs and interests. That means that those who join the project early will have the ability to influence the early directions of the project. At the same time, Tsugi is continuing to evolve to meet those needs so adopters will need to stay in touch with the Tsugi project to know the latest news about changes, bug fixes, and improvements to the project.

Some of the general areas that Tsugi is likely to expand include:

  • Better support for analytics standards like IMS Caliper and xAPI.
  • More tools like (a) YouTube view tracking, (b) simple scalable threaded discussion tool, (c) a markdown authoring tool for “pages”, (d) a simple “clicker” tool to allow quick polls during a live class, (e) a video quizzing application, (f) a collaborative paper reading / commenting tool, …
  • Of course the support for languages beyond PHP needs to be improved and more programming languages need to be supported.

Tsugi is an Instance of the Next Generation Digital Learning Environment (NGDLE)

The core principles of Tsugi are openness, interoperability, and modularity. Tsugi is not a single product or a single library. It is a set of building blocks that can be composed in a myriad of ways to allow us to take a more flexible, distributed, and engaging approach to building and using learning resources.

Tsugi is trying to build the underlying infrastructure to enable teaching and learning innovation to happen many places independently as part of an ecosystem rather than looking for the “one product” that will solve every problem. While Tsugi is a “learning management system”, a “learning object repository” and an “app store” it takes a distributed approach to all these use cases. This makes it possible to have as many learning-oriented web sites, MOOCs, learning object repositories, and app stores as we like.

Ov course once we make it possible to have thousands of sources of outstanding and easily integrated learning content, we will need to solve the problem of searching and discovery. Which will be a good problem to solve.