Ed's Big Plans

Brief: I will be indisposed until May 17.

A Revisitation

In the beginnings of the Winter semester, I had an idea to start up a undergraduate/graduate student group that would provide a scaffold for faster, computer assisted research.

The semester was simply too full for me to try and get it running at that time. I’m tempted to do some work on it later this semester, after I’ve gotten more of my thesis done.

The basic idea is as follows. Faculty and graduate students in the biology and chemistry departments often have the need to analyze data with some elegant computing. Whether this be as commonplace as hacking together an excel sheet to do work or learning some existing toolbox, or something slightly more in depth such as analysis in R, Python or PERL. Unfortunately, these research problems often fall by the wayside as the time commitment to learn a new software package or programming language is not trivial without a stronger computing background. Undergraduate students who are raised in the computer science environment, particularly with a bioinformatics interest have some knowledge of the research problem semantics as well as some knowledge of how to do the above analysis by using and coding software.

The “SOLVER” group would fill the gap by performing a matchmaking and coaching service. In my vision, SOLVER creates working teams of three to four– (1) one or two graduate students or faculty with a research problem, (2) one or two undergraduate students with some knowledge in bio / chem and some talent in computing, (3) an experienced coach that can recommend best practices so that the team has a good shot of solve the problem in a reasonable amount of time. In the end, the researcher gets help and a good chance at a working solution– they might even learn some programming; educational / professional / social connections are made; and the student gets an item to add to their resume. In reality, a particular research step would be executed as week-long blocks– whether this means one block or four blocks (one month) depends on the complexity of the task.

To do…

One stretch of work that I have to do is to determine the needs of the department. I wanted to do this in the middle of Winter semester but didn’t find it a priority. For this group to work, there must be research problems. Similarly, I need to determine the capabilities of potential undergraduate students. I’m learning quickly that the key here is to start small and think big (i.e. start with one group, then two, then learn about the administrative logistics, then deploy some progress tracking mechanism, then four groups and onward).

Retuning the image

The almost idealized description above suffers from a few logistical issues. First, I will now address the issue of publication credits. Because researchers must attribute tangible work (including written code and analyses), some graduate students may be hesitant to participate in the program. I don’t know if this will actually become a barrier however as a “tangible contributor” would never be the first nor the last name on a paper (this is true in all CS, Bio and Chem). Furthermore, a paper with more than one author demonstrates the ability to collaborate in a team, and fostering the experience of another student is part of our culture (e.g. co-op students etc.). That brings me to a second major issue. One of the frames that this group could find itself in is a means to circumvent or short-circuit the co-op student appointment process– a frame that I readily reject. In fact, I should hope that this group becomes a means to introduce new putative co-op students to their future advisers which may otherwise be overlooked for their differing background. Finally, there is the problem of attrition, whereby a group dwindles in size as members drop out. The only contract-based perks or penalties I can think of is really ties to the group itself (e.g. unsatisfactory work naturally results in a time out or withdrawal from the program). It is really the only tangible leverage we can offer at the outset– unsteady leverage at best (difficult to assume a reputation when none has yet been built).

Going forward

More research has to be done in terms of polling and documenting the needs of the department. Furthermore, a deeper understanding about the kinds of students we’d attract and want to appoint is needed– this allows us to understand what time commitment is reasonable (both the lower and upper limits need definition). Finally, the group must from the outset be understood as something beneficial to all parties involved. The solutions named above must be deployed at launch time to ensure minimal friction, and maximum return. First steps were made last year by introducing this idea at the BIC-iGEM meeting– BIC students are excited with this idea, wherein an entire room of a dozen students raised their hands. Furthermore, there are no other groups on campus that attempt this activity, so that SOLVER would provide a unique non-conflicted service.

Of course– this all depends on the amount of work I get done on my own thesis in the first half of the semester.

Making friends

As an aside Isabelle Lam, a student I TA’d last semester in Biol-241 (microbio) has been planning on starting a job / volunteer / coop mine for science students. I should go and bother her and see how far she’s gotten. Her project is called “SPORE”. Last I checked, her team was registering a subdomain with the university.

EDIT: I previously confused Isabelle with Lisa– this has been corrected.

Python Crash Course

Having completed teaching that Python Crash Course before reading week, I can say that I’m probably not going to teach it again any time soon for its time commitment! It was a good experience for me since I’ve figured out how to balance content for time and also how to talk to a crowd of heterogeneous experience levels in programming.

There’s going to be a PERL one-off course offered by BIC on this week that I think I’ll attend to figure out what the general style is for one-session courses– it was previously offered by Edgar and is offered this time by Anna and James.

I definitely need to clean up the course materials, but Andre thinks we should have my course packaged along with the Biology for Engineers course he offered. These two packages will eventually be shipped off to oGEM & iGEM HQ as per their recent interest in local workshops.

Link: Python Crash Course Materials

CS [64]83 Structural Bioinformatics

I threw up a hints page some time two weeks ago to coordinate help for assignment three for the structural bioinformatics course I’ve been auditing. I’ll probably take it down from the main menu when it becomes completely irrelevant. For the mean time, I’ll leave it up or replace it with assignment four hints when that gets underway.

I think I’ll eventually consolidate all of my one-off pages as a single page linked in the menu to reduce clutter. I’ll probably put all of my slide shows in there too.

Link: Structural Bioinformatics A3 Hints

About two weeks ago (Feb. 11th), we had an iGEM*BIC meeting where five iGEM members showed up and roughly a dozen BIC members showed up. I expected a few more from iGEM but they ended up with illnesses or midterm exams that week.

We started the meeting with a nice description of BIC from Anna, followed by a nice description of iGEM at large then iGEM at home from Andre. I then finished with a collaborative projects presentation.

I’ve attached the slides I presented (actually, I’ve updated them since then)– just like the very last set of slides for the Python Crash Course, I ended up using iWork Pages this time around instead of NeoOffice.

Download: Updated slides [pdf].

The meeting was designed to go for half an hour because of its proximity to midterms. We ended up discussing for about two hours about all of the projects we wanted to try this term– everything from the now defunct Bunny Buddy to BactoBones to BactoHouse^MD.

Anna had remarked earlier that iGEM isn’t well marketed to CS students or BIC– so this will certainly be a recurring thing at the beginning of each semester. This is particularly important summer because the next stream of BIC students are returning from co-op.

The general consensus is that everyone was interested in doing *something* in iGEM which is a real bonus. This Wednesday, we’re going to have a modeling meeting that’s punctuated with John’s mini-project talk. I’m hoping that many BIC members will show up to carry over their interest.

My original assessment that most BIC students would want to do in silico modeling and software development was far off. As it turns out, BIC students showed interest in every facet of iGEM from wet lab to software development to outreach and public relations.

A direct consequence of the iGEM*BIC meeting is that we had a much larger design meeting the next day (Feb. 12th)– thirteen showed up.

Finally, the feeling of the group is that the next crossover meeting should be more social. I think that’s something we can shoot for, for early summer.

This started as a comment to Andre’s post here:

http://www.masella.name/blog/2010/02/05T110243-0500.html

We need motivation for characterizing our respective chunks of hackable molecular biology components.

This is in the vein of the whiteboard list we attempted on Thursday of last week.

I propose a brainstorm race (see example)– short descriptions and headers only– Form: Google spreadsheet. In two columns, we fill in our “mathematical assets” and “biomolecular assets”. The first one to two-hundred and fifty items wins some gag prize of < CAD$5.00 and gets a special title to be determined by the winner that the loser must call for a week.

Contest ends with no winners if after three days, 250 items aren’t finished by either

Let me know if you accept and I’ll put together the spread sheet

(Anyone else we should add? John, Danielle, Brandon etc?)

Example brainstorm race (to 20) on the topic of novel icecream flavours:
http://spreadsheets.google.com/pub?key=tsyR72D6UQRXLG0Nv6kKoiA&single=true&gid=0&output=html

Andre wanted to write down all of our assets so that we could figure out if there were any concepts that matched nicely between items in mathematical problems and items in biomolecular assets. I’m not going to give examples of either until the race finishes of course

Oh okay fine– these are fair game by the way– two example math problems are network clustering inspired by the Hamiltonian path finder; knot maths in topology characterization. Two example biomolecular assets are ribozymes; heterodimeric proteins.

This week is going to be crowded enough for me that I’m going to cancel this week’s class. On the bright side, the classes have gone better than I thought it would. We will continue on February 9th.

The very first class ended up being too short, with the advanced students feeling that it moved too slowly. The second and third classes ended up being just the right speed– with the exception that the example fill-in-the-blank script from the third class was too difficult.

The difficulty rose when I too quickly introduced dictionaries whose values are lists.

The fourth class held last week was excellent– I completely ditched slides that week and produced five fill-in-the-blank scripts that were just the right tempo for everyone. I had a good mix of BIC (Bioinformatics Club), iGEM and chemistry graduate students– all who attended got something out of the hour which was my objective.

We only had time for four out of the five scripts with the remaining script as a bonus that everyone could take home and try.

Now, it’s back to Structural Bioinformatics homework… It’s quite a daunting assignment to be true (having just formally shaken hands with Singular Value Decomposition), but the parts that are Python (particularly the bonus question) are familiar enough for comfort.

Update: The Gleave Library, B1-273 has been booked for this occasion!

Brief: The two software projects that will precede the main body of Waterloo iGEM 2010 will be discussed on Wednesday January 21 from 6pm to 8pm. I will update this post once a room booking has been confirmed.

Related topic here on the Waterloo iGEM Discussion Board.

The first lecture of my Python Crash Course went really well! I ran it two evenings ago in the Dean’s Conference Room.

In gearing the very first lecture for absolute beginners, I had very little to cater to BIC (Bioinformatics Club) members. I however took the opportunity to discuss with them about the SOLVER group (more on that later); many of which seemed interested.

Overall there were roughly a dozen people that turned out, including Ariana, my TA partner from last term. There were about four iGEM members and six BIC members.

I also took the opportunity to poll for the kinds of things that students wanted to learn. Here are my findings.

• Object Orientation is something everyone wants to know– especially the people coming in with a Javascript, PERL, C, C++ and Scheme background; I was surprised that the C++ people didn’t get exposure to thinking in objects earlier.
• The beginners came in two groups. First, there are the ones who are happy to learn anything as long as it can be applied later.
• The second group of beginners want to data crunch PDBs, SDFs, FASTAs, Nucleotides etc.

In week two, we’ll take care of object orientation and in week three, we’ll take care of everything anyone ever needs to know about input output in order to do data crunching. I have added a link in the navigation of this blog for the Python Crash Courseware which will eventually include all the PDFs, code modules and examples used in class.

Oh right, I don’t know if I’ll get around to it– but I am missing instructions for setting environment variables in Windows. Perhaps I will add it later when I have time.

(iGEM attendees were John Heil, Danielle Nash, Tiffany and Lina; BIC members included Fiona, James and about four others whose names I have forgotten.)

Edit: Direct link to Python Crash Courseware; Direct link to Week 1: A Mad Mad Introduction, PDF.

Update: if you’re from Waterloo iGEM and want to work on this with me, see here.

I’ve contemplated this for so long, I think it’s time to put the plans into writing– at least as a draft so I have something to build upon.

There are three pieces of software I’ve been wanting to write. The rules are simple. I’ve become so addicted to cloud computing, I wouldn’t even contemplate desktop applications– so this stuff will be browser powered and hosted on Zinc. Each piece of software must intuitively communicate with each other piece — this can only be done where logical as is discussed below. Each application must offer familiar interfaces, seemingly simple operation and few tunable parameters. Finally, this stuff should be released with a cheap as free (as in beer, birds and guilt) license.

Tarocchi – Task Rhythms

The first application is for time and task management, I call it tarocchi as in ‘tarot’ as in the cards– ironically to mean that we are masters of our own future (immediate or distant). As much as I contested the idea of working-sphere based task management, I came to realize that’s what I’d benefit from the most the more I analyzed what I was already doing. Of course, this is not quite as invasive/pervasive as a technology that would stop irrelevant phone calls or e-mails from reaching me– but it is designed to break a workday apart into manageable hour-long units.

Each hour, tarocchi’s heartless silicon clutches will deal the end user with a card that is inscribed with the task for the next hour. For individuals with many projects, this provides a visual cue to switch gears so as to not burn out from the given task. The user must accept the task for the time spent on it to be logged. Note that at any time within the hour-long time period, the user may accept the task however– just as with pausing a task in progress, tarocchi will only log the amount of time that the user has claimed to work but will not track work committed after the hour unit is complete.

At the time of card dealing, the user may comment on the previous card and indicate whether or not it has been completed so that it will be placed into a deck of finished tasks.

Although tarocchi has no soul, it is not meant to force the user to work but is designed to make it psychologically easier to let go of a current task, and to beat the early morning, mid-day and end-of-day mental blahs.

A user may opt to reject a dealt card, whereupon tarocchi will ask if a break is needed, or if another card should be drawn. If the user manages to exhaust the entire remaining deck by rejecting them all, tarocchi will shuffle the cards and present the deck again. Tarocchi doesn’t operate completely at random, a few heuristics and user defined parameters tune how often, how long and in what order tasks may occur. There is also a facility to specifically tune when a particular deck should be played (date, time)– this functionality will make more sense after seeing mastermind and jigsaw.

Tarocchi has a guest mode which allows a logged-off user to browse the deck, each tasks’ progress and time into the current task of a named user, should that user have made the given card, deck or their own profile available for prying eyes. This guest interface doubles as the weekly report generated by tarocchi that allows the user to self-analyze how much time they spent on each task– which tasks were more often rejected, accepted, had breaks put in etc..

Mastermind – Team Brains

The second application fills a niche for iGEM, I call it mastermind. Mastermind is software designed to delegate tasks for a given team of individuals and to keep track of milestones. I will first describe mastermind as a stand alone. The guest-level interface shows the progress of particular projects, and its logical milestones. There is no enforcement on how large these milestones can be, as mastermind does not attempt to comprehend real-world implications, only to represent supervisors’ comprehension of tasks. Milestones should never be deleted, and have a five-valence progress descriptor: preproduction, churning, done, aborted, and paused. Tagged with each task or milestone are descriptions, notes, messages, links to materials they represent and other references. The guest may browse essentially the deliverable history of the team.

The user-level interface allows a user to own a particular task, edit its contents and to change its progress– additionally, users may break a long task into smaller logical tasks while supervisor-level interface additionally allows the creation and delegation of tasks and the administration of users.

Mastermind does not inherently keep track of time spent on milestones, only the materials used and how complete each milestone and task is. Mastermind does optionally keep track of when a particular project should be worked on by a specific user… this functionality will make more sense after you’ve read about jigsaw.

Tarocchi and Mastermind work together as follows. Mastermind would pass a deck of cards to Tarocchi corresponding to each of the teams and tasks that user has committed to. Tarocchi would then ask the user a few questions about priorities and shuffle these cards into its emotionless cultches to be dealt to the user. These cards also inherit the project descriptions provided by mastermind, and similarly these properties can be updated by every user with a copy of this card within tarocchi. Tarocchi would then tell mastermind whether or not the task depicted on the card has been completed, and also pass back the amount of time that was worked by this user. For tasks that mastermind has defined a specific time frame to be spent (date and time), the corresponding cards are not dealt unless the user has entered that frame. Mastermind tasks thus display the time spent on tasks per user through tarocchi.

Jigsaw – Scheduler

Jigsaw plays well with calendaring software such as google calendar. This is basically a revival of the scheduling software I was interested in being involved with. Basically, when shifts are to be assigned, wherein a specific number of people must show up in a given shift– where one must piecewise fit each person’s reported availability– jigsaw would magically puzzle the pieces into place. A supervisor defines the week, month or other time range they want filled, and what shifts exist. Users fill in their availability and guests may see the result. Users get an e-mail about which shifts they’ll take, may subscribe with RSS or export to an offline or online calendar. Little hitches like insufficient availability, users forgetting to report their availability, incorrect reports etc., can be resolved through automated messages to supervisors and users involved.

Jigsaw would likely communicate with Mastermind and Tarocchi as follows (if at all, as this gets complicated). Because there isn’t a clear logical entry point, I’ll have to make both jigsaw and mastermind applications that can begin the crosstalk. I generally avoid this kind of design because it is implicitly redundant– so in lieu of a better method, here we go. If a supervisor uses both jigsaw and mastermind and creates a task, they can specify on either that this task requires the other application. In mastermind, one would check off a box and indicate that this project must be scheduled in particular shifts. In jigsaw, one would indicate where these jigsawed shifts fit into the team’s projects. The functionality is far clearer from here. After all of the piecewise fitting is complete, jigsaw then tells mastermind who has been assigned to the task, and when. Mastermind does not communicate with jigsaw after this. Mastermind however does indicate to tarocchi when a particular project must and can only occur so that cards related to this project are dealt when a user enters a specific shift.

Overall

The interface that a user should see most often is tarocchi– it keeps often times overwhelming details of time management hidden while actual work is being done. Taking the worry away from choosing what to work on amongst self-defined, team-based and team-scheduled projects is a plus for people that have well defined tasks, but ill defined working schedules. No additional bloat such as chatting or person-to-person messaging should be added aside from the notes interface within mastermind– the focus is on simple, effective and time saving means to manage projects.

First Steps

I think I’ll develop a draft and specs for tarocchi while recruiting developers for tarocchi and mastermind.

Draft Syllabus Here (public Google doc).

I’m currently putting together the course materials for my Python Crash Course for Biologists… all that’s left is to fasten the lesson ideas into slide shows, example code and exercise materials and I’ll be ready to indicate a launch date.

I’ve heard some interest from iGem members, lab mates here at the Meiering lab and also the Waterloo Bioinformatics Club… I want to run this soon.

Andre may be doing something similar on a different topic– so it’s been very nice to have another set of eyes evaluate the syllabus.