Piotr Banaszkiewicz

Peer instruction: update 6

On Monday 14 Jul, 2014

I missed one post last week and this one is already delayed by two days (compared to my typical writings that appeared on Saturdays).

For­tu­nate­ly, I have good excuses.

First, I wanted to get something done. Second, I was buried under real-life super exhausting stuff like post-exams leisure. ;)

Progress

Okay, good news: Pitt has new interface:

Pitt's fresh interface

Pitt’s fresh interface.

And I’m in the middle of rewriting JavaScript code (again…). Now the code uses good JavaScript patterns (and I don’t consider myself a JS newbie anymore).

I separated ap­pli­ca­tion logic code from ap­pli­ca­tion appearance code. Overall, the code should be easier to understand for newcomers and a lot easier to maintain.

The list of issues is updated and available here.

I’m also starting to think about Software Carpentry Sprint that takes place on July 22-23. I’ll post some update soon…

Peer instruction: update 5

On Sunday 29 Jun, 2014

This is gonna be a short one. Because of exams, I have to study a lot. And because there was not much progress on Pitt during this week.

Current release

Current version is v0.3.1, and it’s tagged in git repository. I’m in­cor­po­rat­ing git-flow model.

What I wanted to get in was two major features:

  1. countdown before switch from group split to broad­cast­ing mode,
  2. small groups of students of variable-defined size.

I can tell that I was successful and these features are now part of v0.3.1 release.

Bugs

While testing with Greg and Mike at their office and me here in Kraków, I couldn’t connect to them and vice versa. Con­nec­tions between Mike and Greg worked as intended.

This was strange, because I didn’t change the code so much that it’d break. More so: last week while testing with Greg alone it worked!

So I conducted few more tests:

  1. Pitt: Kraków ↔ Kraków
  2. Pitt: Kraków ↔ Toronto Mozilla Office
  3. Pitt older version: Kraków ↔ Toronto Mozilla Office
  4. Other WebRTC ap­pli­ca­tion: Kraków ↔ Toronto Mozilla Office

In the previous week, I’m guessing Greg worked from his home. We wanted to try Pitt in this con­fig­u­ra­tion (Kraków ↔ Greg’s home), but due to holidays in Canada we were not able to.

From what I can tell, the issue lies in the client IP addresses resolution. Here’s a lengthy article about how hard it is to do WebRTC properly: http://www.html5rocks.com/en/tutorials/webrtc/basics/#toc-signaling

Anyway, I hopefully will be able to easily overcome this issue.

Peer instruction: update 4

On Sunday 22 Jun, 2014

This week me and Greg Wilson, my mentor, we decided to test run Pitt. It was a success and, while revealing some annoying bugs, it made Greg really excited.

Current release

Current version is v0.3, altough I might have tagged it wrong in git. For­tu­nate­ly it seems that tag was not published to the GitHub repository.

Current features

This is a quick recap on what Pitt is capable of right now.

  1. Users coming in and quitting: thanks to signalling, as soon as someone appears online, they’re being logged in and everyone can see them.
  2. Quick switch mode: the instructor can easily and very quickly switch modes from broad­cast­ing (to all students) to work in small groups (students are split into pairs or groups of 3).

The code is decent. I presume there are some bugs with saved state of the ap­pli­ca­tion. For example, what to do if the instructor is broad­cast­ing and someone joins in? What if another instructor joins in? What if there are two in­struc­tors and one starts broad­cast­ing, should other in­struc­tors see their stream too?

These kind of questions will be addressed for the v0.4 release. Right now I’m working to get v0.3.1 release by Friday, 27.06.2014.

Exposed bugs

During my test run with Greg we quickly found out one super annoying bug.

There’s a very in­ter­est­ing human behavior: people slow down their talk when they hear themselves with small delay. It’s really hard to overcome this basic reflex.

Back to the bug: we found out that local stream video (ie. the one where you can see yourself, because browser plays the video from your webcam) is not muted by default. Add the playback delay to the mix and as a result Greg was struggling to speak.

This bug was really easy to fix (in HTML5: <video src=”…” muted=”muted”>) and the fix is included in the recent code.

There was also issue with the state of the ap­pli­ca­tion - it somehow broke for Greg (when he was a student). I have yet to discover the actual bug.

Missing features

Greg wants me to add these two new features to the upcoming release:

  1. Countdown. The instructor presses “back to broadcast mode” button and the switch doesn’t happen im­me­di­ate­ly. First there’s 30 seconds countdown so that no students are in­ter­rupt­ed in the middle of the sentence.
  2. Variable group size. The instructor can specify if the students are split into pairs or groups of 3, or groups of 6. This task is more chal­leng­ing than it seems: I have to ensure that no students are left alone (what is often the case when there’s odd number of students).

Next release

I’m planning to release next version, v0.3.1, on Friday 27.06.2014 or earlier.

I have 3 exams before Friday and 2 after it. Ouch…

Peer instruction: update 3

On Saturday 14 Jun, 2014

The decision has been made, and I switched to a different codebase.

I had one exam this week (Aparatura Au­tomatyza­cji, eng. Automation Systems) and five more in next 2-3 weeks, so it is quite chal­leng­ing for me to find time for peer in­struc­tion right now.

I did, however, spend most of this weekend trying to make Pitt broad­cast­ing mode for in­struc­tors.

It works! Proof below:

Me as instructor and two students.

Having dual monitor setup helps getting this kind of screen­shots.

As you can see, the layout and design in general is very rough. And so is the code.

This code is mostly based upon multiple events being propagated through sockets.

But I really don’t like the design of these events, and, frankly speaking, I much more prefer a “pub/sub” (pub­li­ca­tion - sub­scrip­tion) ar­chi­tec­ture.

At this moment, when the instructor triggers an event, the server has to re­prop­a­gate it to every student.

In “pub/sub” arch, however, there’s no re­prop­a­ga­tion in between.

Some people use redis for pub/sub, but I found some really cool protocol: WAMP (don’t confuse it with Windows, Apache, MySQL, PHP stack!).

WAMP authors clearly explain why it is good so please go there and read. Let me just point out a few cool features of WAMP:

  • WAMP is not a NodeJS module, it’s a protocol
  • it can be (and indeed is!) im­ple­ment­ed in various languages
  • therefore it’s a solid foundation for a quickly changing service.

What I dislike about WAMP is that at the moment there’s only one leading im­ple­men­ta­tion: Autobahn. And I’m not yet sure if I want to drop NodeJS backend in the future, but if so, then there’s already fast Au­to­bah­n|Python.

Peer instruction: update 2

On Saturday 07 Jun, 2014

In this week’s video­con­fer­ence between my mentors, Greg Wilson and Mike Hoye, Software Carpentry‘s instructor David Rio, and me, we decided to tem­porar­i­ly drop my current codebase and what I’ve done with Licode and Erizo.

Instead, my current efforts will be focused on developing and enhancing David’s excellent work that uses PeerJS.

This has some in­ter­est­ing con­se­quences.

Firstly, we can’t have broad­cast­ing using MCU in teacher’s mode. Instead, in this mode, we’ll have to open P2P con­nec­tions, what’s probably going to be quite chal­leng­ing for teacher’s internet connection.

Note

In teacher’s mode, the teacher broadcasts his stream to all of their students.

In student’s mode, students are split into smaller groups (6 people per group in real life, at most 4 people via Internet - more is less efficient) and talk with each other.

But for now we want to ship first version as soon as possible, so we’ll care about that later.

Secondly, we’ll have a lot clearer and “closer to the metal” code. Opening sockets and handling all data transfers will be much easier, and I like that fact a lot!

On my personal side of news, I’m currently preparing for exams (first one: next Thursday), which leaves me very little time for GSOC #sadface

Peer instruction: update 1

On Friday 30 May, 2014

I always avoided JavaScript. With my long exposure to Python, JS never appealed to me. And yet my whole Google Summer of Code project consists mainly of JS.

Let me quickly rein­tro­duce basic ideas and plans for Peer In­struc­tion project.

Peer in­struc­tion concepts

The most important feature of Peer In­struc­tion is the ability to, from the technical point of view, quickly switch between teacher and student modes.

Teacher’s mode

Teacher mode is basicly a broadcast sent to every student in a classroom. This might be quite chal­leng­ing: you can have many direct con­nec­tions and suffer from capped bandwidth and high CPU usage.

Teacher broadcasts their stream to multiple students

Teacher broadcasts their stream to multiple students.

The solution is to introduce additional server that helps to “spread” the stream to multiple students. It es­sen­tial­ly looks like this:

Teacher broadcasts their stream to multiple students through Multipoint Control Unit

Teacher broadcasts their stream to multiple students through Multipoint Control Unit.

What’s really good about this design? There’s an excellent open-source MCU available: Licode. I must admit Licode is a little too com­pli­cat­ed to set up, but authors’ support and continuous de­vel­op­ment make it a great option if someone wants, for example, to host their own al­ter­na­tive to Google Hangouts or Skype.

Me testing teacher's mode

Me testing teacher’s mode. (I was suprised it worked!)

As you can see above, the interface is pretty simple, but it works (at least for 1 student). I have yet to test it for more students, but I haven’t received a server account at Mozilla to do so.

Student’s mode

This is the second mode of broad­cast­ing. A very crucial from the point of science of peer in­struc­tion.

In this mode students are split into smaller groups so that they can talk with each other.

Right now I’m thinking how to implement this mode. One of the ideas is to create one Erizo Room for every group of students.

The way events are propagated within Erizo makes it really easy to subscribe to other students’ streams within one particular room. Using multiple rooms also helps manage all these smaller groups.

I should also mention that Erizo can create “full MCU” rooms - ie. rooms where streams are going through the server - and Peer-to-Peer rooms, where the server only handles sessions, signalling and events, but the streams are actually trans­ferred between the room par­tic­i­pants.

I think for small groups of 2-4 students it’s a good idea to use P2P rooms and save resources on the server.

Un­for­tu­nate­ly, this solution has some drawbacks, too. I found out that Erizo can only handle so much rooms at once (it’s specified in con­fig­u­ra­tion, but I don’t know the retionale behind it).

Current issues

My main focus for next week(s) is working PoC of students mode. Right now I’m working on a protocol used by Licode events.

It’s possible to send data through Erizo streams. I want to use this “channel” to com­mu­ni­cate with students’ browsers.

For now I’ll only send data like “join room ABC for small group discussion” and “leave room ABC”. In future Peer In­struc­tion might be more advanced - quite important feature is chat, and I will likely leverage the existing protocol for that.

Anyway, that’s the update status on my project. I highly welcome any con­tri­bu­tion or comments.

Here’s project GIT repository: https://github.com/pbanaszkiewicz/peer-in­struc­tion

Peer instruction - a summer project for Mozilla

On Thursday 24 Apr, 2014

I was accepted for Google Summer of Code 2014. My project is called “Peer in­struc­tion”, and I’m doing it under the wings of Mozilla foundation (or, more specif­i­cal­ly, Software Carpentry).

Peer in­struc­tion

Science tells us that students in groups learn more ef­fec­tive­ly [1]. This concept is widely used in peer in­struc­tion.

Peer in­struc­tion is a teaching method­ol­o­gy developed over 20 years ago. It’s different from typical learning classes in today’s colleges or uni­ver­si­ties. The basic workflow goes more or less like this:

  1. Teacher asks a question.
  2. Students in­di­vid­u­al­ly answer it.
  3. Students are split into small groups to discuss their answers.
  4. Teacher reveals the good answer.

The key feature of this method­ol­o­gy is splitting students into small groups.

[1]Peer tutoring is ranked as having 0.55 influence on student’s achieve­ment, while 0.0 is none.

Summer project

If you take an online classes by Udacity, Coursera, Khan Academy or whoever there is, you may notice they don’t deploy peer in­struc­tion.

But with web tech­nolo­gies of today, it is possible to create a virtual classroom that leverages this promising teaching method­ol­o­gy! And my task is to do it.

The minimum outcome

No, I don’t want to create a “full-stack” virtual classroom. The minimum viable product of my work will be a proof-of-concept working web service that lets you quickly switch from broad­cast­ing (or “teacher mode”) to many few-to-few mul­ti­plexed broadcasts (or “small-groups-talk mode”).

Of course, if I can, I’ll implement as many additional features as possible.

The obstacles

The only two dif­fi­cul­ties I foresee right now are:

  1. The lack of fast MCU technology.
  2. The lack of fast internet.

MCU stands for “Multipoint Control Unit”, a software or hardware used to bridge media trans­mis­sions.

The only one open source software MCU for WebRTC (technology used for media trans­mis­sion in modern browsers) I found so far is Erizo. I may have to implement an Erizo API module for Python if I decide to stick to Python.

So that’s the only issue I can somehow overcome. I cannot fix the internet speeds, though…

Possible features

If I have enough time and knowledge, I’ll implement:

  • whiteboard
  • voting system
  • quizes
  • trans­la­tions

It’s going to be exciting summer. I’m looking forward to it! :)

Con­tribut­ing

I welcome and highly appreciate any feedback, ideas, sug­ges­tions, or complaints. I released publicly my proposal, so you can comment it or even fork and make a better one.

I also want to share the link to the Git repository, where my work will reside. Feel free to send pull requests :)

Ganeti Web Manager installation

On Wednesday 28 Aug, 2013

Due to my efforts, Ganeti Web Manager is now a proper Python Package.

The main reasons for this change are:

  • minimizing necessary de­pen­den­cies (no more fabric!)
  • keeping GWM codebase clean
  • easing de­vel­op­ment

What does this change mean?

For end users

With GWM being Python package comes one huge advantage: easier in­stal­la­tion. It’s actually one line to install whole GWM with de­pen­den­cies!

Because my GSoC project is to make GWM in­stal­la­tion easier for end users, I’m writing a setup script, that will create virtual en­vi­ron­ment (helps with separation), install GWM’s de­pen­den­cies and then GWM itself.

To install Ganeti Web Manager, simply get setup.sh script, make it executable and run setup.sh -h to get familiar with it’s command line arguments.

$ wget -c https://github.com/pbanaszkiewicz/ganeti_webmgr-setup/blob/develop/setup.sh
$ chmod +x setup.sh
$ ./setup.sh -h
$ ./setup.sh -d /opt/gwm

Note

As of 29/08/2013, this setup script is Work In Progress (TM). Some parts of it may not be completed and simply won’t work. Be careful. Or wait for Ganeti Web Manager next release, which should be 0.11.

For developers

To start working on GWM, you have to:

  1. make virtual en­vi­ron­ment
  2. git clone GWM repository
  3. install GWM as a de­vel­op­ment package

(I suggest using vir­tualen­vwrap­per for #1, as it keeps your directory with code clean.)

In shell terms it looks like this:

$ mkvirtualenv gwm
(gwm)$ git clone git://git.osuosl.org/gitolite/ganeti/ganeti_webmgr
(gwm)$ cd ganeti_webmgr
(gwm)$ python setup.py develop

And that’s it, now you can work on GWM. (Al­ter­na­tive­ly you could install GWM de­vel­op­ment de­pen­den­cies instead of whole package:)

(gwm)$ pip install -r requirements/development.txt

Google Summer of Code update #1

On Monday 08 Jul, 2013

So far in the Google Summer of Code 2013 I’ve been working on Ganeti Web Manager.

My job was to refactor Ganeti Web Manager so that instead of one huge, bloated Django ap­pli­ca­tion (ganeti_web), the project would consist of many smaller apps.

I shared more details in this blog post.

Now I can say my work is mostly done. I’ve got smaller apps extracted and (this one’s big) I worked on database migrations.

Now (hopefully!) any user can checkout my branch and suc­cess­ful­ly run it against their codebase.

Why are you doing this, one can ask. There’s no visible benefit for end users. Actually even worse: they for example have to use settings file which is now stored completely elsewhere.

This work brings hope and sunlight to all the GWM developers. It helps new ones “see” and understand code, as the code is now simpler! And it helps old devs navigate through the code, while fixing or enhancing it.

I hope to get my work merged soon, although it’s quite big change so the proper code review is really necessary.

Next on the GSOC agenda: taking care of Ganeti Web Manager de­pen­den­cies. I.e. doc­u­ment­ing, testing, uploading to PyPI, maybe even setting up a CI.

Ganeti Web Manager Modularization

On Thursday 06 Jun, 2013

I’ve got accepted in for this year’s Google Summer of Code. My project requires me not only to program, but also to improve automation and work flow for GWM developers.

The least Django version Ganeti Web Manager is compatible with is 1.4.5. However, GWM doesn’t use the new project layout introduced with Django 1.4.

The result is GWM’s main directory being very cluttered. As for 0.10 release, there are 25 files and/or di­rec­to­ries. With just the switch to newer project layout, only 21 files/di­rec­to­ries exists now in top level dir. That number will soon decrease, as more files get moved to ap­pro­pri­ate places.

I’m sure setting files and files containing URLs will get tossed out into related Django ap­pli­ca­tion di­rec­to­ries, too.

Speaking of which: originally GWM was written as one single Django ap­pli­ca­tion. Since commit dde1fdf1cc (WIP) it’s now splitted into many smaller ap­pli­ca­tions: auth (I might change that name in future), clusters (containing code related to clusters; surprise!), ganeti_web (original app), jobs, nodes, utils (or doesn’t fit anything else category), and vir­tual­ma­chines. Two additional apps are moved from top-level directory and both relate to Muddle. I’m not sure about their fate; it’s possible that they’re gonna get sentenced.

The rationale for such splitting is mainly the con­struc­tion of Django models in ganeti_web ap­pli­ca­tion. That single file itself changed its size from 1,958 down to 295 lines!

Next steps in GWM mod­u­lar­iza­tion will involve moving forms, templates, tests, views, models, and URLs to ap­pro­pri­ate places. And testing, lots and lots of testing is required.

I also hope to document my work and general progress at least here. GWM recently started hosting its doc­u­men­ta­tion on the ReadThe­Do­cs, I’ll update it as well.

All in all, I’m very happy with my project and GSoC 2013. :) Its timeline has shifted so now GSoC covers more of my summer holiday. #win