NP-Complete Breakfast

Behold: the QR card


I'm inordinately pleased with thisThat's me, in case you can't tell.

How it works

It turns out that getting an arbitrary image into a QR code is annoyingly difficult. Or at least it took me quite a while to do it—partially due to inertia, as it required the concentrated boredom of a trip home for the holidays to get me focused enough to crack it. In the end, the code is fairly simple.

In short, I had to reverse-engineer a QR code library, figure out where the data was stored, put in the data I wanted, and then calculate the corresponding error correction code so that the thing would scan properly.

In more detail

The whole thing fits in a GitHub Gist, if you don't include the required python-qrcode library. The workflow is fairly simple:

  1. Get the layout of the QR codeThis took the longest to figure out. The simplest way was to create a blank code.
  2. Load an image and extract the data from it, using the coordinates from 1.
  3. For each of the bit masks:
    • Decode the data from the image, insert the desired URL, and correct any disallowed or undesirable bits
    • Recode the data and calculate the correct EC bits
    • Insert data and EC into the image and display it
  4. Choose which of the masks is best

More Glasseye


Seems like I'm still pretty bad at updating this thing. Partially because I'm sure no one is reading it. Something of a Catch-22 there. So here's another website-customization post!


Tufte CSS suggests that you break articles up into sections, with a little bit of padding around them. That was a little tricky to do here because there's no section syntax in Markdown, but since I don't use horizontal rules, I can use that syntax to designate the beginning and ending of sections by replacing the resulting tag in my fork of Glasseye. It's a little hacky but it'll do. I'd prefer to use BeautifulSoup to do the processing, but I didn't see an easy way to wrap lots of tags into a section.

Because this post is pretty smalland also because I found a typo so I was editing it anyway, I broke up the Team Science post into sections as well.

I couldn't tell you why I made this


Once I thought of it, I had to do it, and this is the least-shameful place to post it. Plus I get to test out the \(\LaTeX\) formatting here.

\[James^TWebber = \begin{bmatrix} JW & Je & Jb & Jb & Je & Jr\\ aW & ae & ab & ab & ae & ar\\ mW & me & mb & mb & me & mr\\ eW & e^2 & eb & eb & e^2 & er\\ sW & se & sb & sb & se & sr \end{bmatrix}\]

Go Team Science! (Or not)


I don't seem to have a handle on this blogging thing, yet. I have a long and rambling draft for a post about publishing, which has been languishing for months now. Meanwhile the NIGMS just released a Request-For-Information on "Team Science". That seems as good an excuse as any to write something here. They even provided me with a nice outline, and an introduction:

The National Institute of General Medical Sciences (NIGMS) seeks input on team-based scientific research and the manner in which this activity could be supported by the Institute. This Request for Information (RFI) will assist NIGMS in considering needs and opportunities in team science at the multi-investigator, institutional, regional and national level. Comments are invited from any interested party.

Hey, I'm an interested party, so let's do it. The RFI is broken into six areas, and I'll structure my post likewise. But first, a general overview of where I'm coming from (since I haven't posted anything else on this blog and you might not know).On the off chance that the NIGMS doesn't read this blog, I'll also email this to them.

The Short Version

The idea of team scienceThat is, big interdisciplinary groups working on large projects sounds great, but when it gets implemented there are some challenges. Most of those challenges boil down to how we publish science, how we evaluate scientists, and how we train students and evaluate their work. All of these issues deserves their own essays, but in short:

  • A whole lot of science gets done by trainees—post-docs and graduate students
  • Early-career scientists are evaluated on the basis of their personal accomplishments. Around here that almost always means your own project and a publication with your name at the front (or at the end, for new PIs).
  • Team science requires teamwork. It's really hard to collaborate in such a way that everyone involved can have their own publication at the end.

Because of those points, I don't think team science is a good use of funding. The goals of such a grant are not aligned with the interests of the individual labs. Unless universities and funding agencies are going to seriously change how they evaluate scientists, big teams don't really work in academia.

So, after laying down that thesis statement, I'll go over the sections of the RFI.

Interest in team science

Comment on the appropriateness and usefulness of team-based research to address particular areas of biomedical science. This may include comments on the relative importance of team science in your field and your own experiences with team science.

Not just appropriate and useful, I think team-based research is essential! There are so many open questions in biology that involve the intersection of many fields. The big challenge is in integrating the collective knowledge of so many different specialties.

I don't think that big grants given to specific groups is the best way to achieve that goal. In any funding system it's hard to pick winners—with a smaller number of large grants, that problem is compounded. The big-grant approach heavily favors the large institutionsLike UCSF, for one. We have a lot of these grants that have faculty studying a wide range of related topics and can come together to apply for major grants.

The most important thing the NIGMS can do to support team science is to set up and administer common resources. Rather than try to fund large consortia, build scientific clearing-houses that facilitate teamwork. And revamp funding criteria to reward scientists that play supporting roles on many projects.

Management and advisory structures in team science

Comment on the types of management structures within a project that would enable an effective team science program. This may include the organizational structure, leadership models, and use of advisory boards or external review groups. Comments on challenges and solutions for issues such as the training needed for effective team science leadership, approaches for maintaining communication within and between teams, and strategies for maintaining team effectiveness are welcome.

Alluded to in the previous section: the best way to manage and advise teams of scientists is to let them form on an ad-hoc basis, without management. Fund individual PIs on the merits of their own workI think the MIRA is a great start, including their service to helping other labs. If the NIGMS provides support to make team-based science efficient and rewarding, PIs will figure out how to do it on their own.

Team composition

This may include comments on recruiting team members, the importance of training students or mentoring junior PIs involved in team science, the value of diversity in team science, and the challenges of recognizing individual efforts on team-based research within a university or research institute setting.

As I said at the top, I don't think trainees and junior PIs can thrive as cogs in a huge machine. But in a decentralized system they can be cogs in a smaller machine: their lab. If it is possible to reach out to collaborators easily, and they have incentives for providing assistance, it should be possible for small labs to engage in team science without being lost in the crowd.

Resources and infrastructure

Comment on the resources and infrastructure that are needed to support team science, including teams consisting of groups from multiple institutions. This may include comments on technical and administrative cores, both those currently available at your institution and those that would need to be established to support team science.

This is where NIGMS can make the biggest impact, but not necessarily at the institutional level. Institutions should be able to facilitate collaboration within their own walls. What the NIGMS can facilitate is collaboration between institutions, by helping groups share results and feedback. One way to do that is to build common resources for sharing results, methods, reagents, and data. The NCBI does this for lots of computational dataalthough it could be much improved and they're an indispensable part of biomedical research because of it. Whenever the NIGMS identifies a problem worth of targeted grants, they should consider what common resources they can provide to the community, rather than assembling a dream team.

Collaboration is hard for much the same reason that team science in general is hard: it is difficult to align the interests of two research groups so that they work together effectively. I think the major obstacles is that the minimum unit of research that is useful to a scientist is the publication, and a publication is a large investment of time and effort. This means that the activation energy for collaborating is very high.I had more to put here, but the short version is: the farther you get from first/corresponding author, the less likely it'll be worth the effort, and so it's a lower priority. Thus there's a limit to the size of collaborations

If the NIGMS really wants to encourage team science in a systematic way, it needs to develop a way to track, quantify, and reward collaboration at all levels. Providing a small part of ten projects must be as valuable as spearheading one. And this contribution can't just be recorded in author lists, which are subjective and inaccurate. We need a better way to record who helped with what on which piece of research, so that we can evaluate and reward the scientists who make an impact in many different areas: the team players.

Assessment of team science

This may include factors that should be considered in the peer review of team science-based grant applications, the value of interim reviews during the funding period, the importance of outreach activities, and the appropriate quantitative and qualitative measures of the success and impact of team science.

This bit goes out the window if you take my advice and stop providing grants to giant groups of PIs. Reward individual PIs for their work, based on its scientific merit. And don't do it based on specific project proposals, because they never work on what they say anyway.

Comments on past or current NIGMS team-based programs and funding mechanisms

Comments are welcome on the advantages or disadvantages of programs and grant mechanisms such as the National Centers for Systems Biology (P50), Centers for Injury and Peri-Operative Research (P50), Centers for HIV/AIDS-Related Structural Biology (P50), COBRE Centers (P20), Glue Grants (U54), the Protein Structure Initiative (U54), and Program Projects (P01).

UCSF has/had two P50 grants that I'm somehow associated with: one for a Systems Center and one for a HARC Center. My impression of those grants is that they certainly funded a bunch of projects, but they weren't the proximal cause of any team science. PIs have areas of research and trainees need their own publications. Collaborations happen when they further those goals and not otherwise.

Many projects at UCSF involve multiple labs working together, but that tends to be determined (and should be determined) by the scientific questions, not by the funding source. If the P50 grants were replaced with stable funding for many labs, I don't think the outcome would be less collaborative, and the scientific output would likely be higher.

How is any of this different from the status quo?

I'm not sure! In the end, I'm suggesting that the NIGMS step back from these team science grants and focus on labs. I think the biggest things I propose are somewhat tangential to this RFI: fund labs rather than projects, reward small units of collaboration/supporting work, and good things happen.

But that's why I used this RFI as inspiration for a blog post in the first place: the questions NIGMS is asking were about the topics I wanted to discuss anyway.

Coming Soon (maybe)


I made this blog because some stuff doesn't fit in a tweet, so I should probably write something, huh? Here are the main things I want to write, eventually:

  • Something about publishing
  • Something about graduate education
  • Something about the research enterprise in general
  • (Maybe) something about statistics

If I ever write these posts, I'll update this one to reflect that.

Glasseye Upgrades


I fixed the way that Glasseye handles sidenotes and margin notes, so that they auto-hide (with a pop-up link) when the screen is too narrow to accomodate them. Job well done.

At this point my "Glasseye" implementation is not really similar to the original code, so I've created a GitHub project for this site. In case you wanted to see how the magic happens.

I imagine that at some point I may even break that plugin out into yet another repository, because there are still some tweaks I want to make…we shall see.

Introducing Glasseye, sort of


I like how this looks but I wanted more functionality—particularly the sidenotes from Tufte CSS.Look! A sidenote!

And yes, this is still a blog about making a blog. I'll get to other topics eventually.

Looking around for options, I stumbled on Glasseye, by Simon Raper, which looks really nice. He's combining Markdown, Tufte CSS, and d3.js in one package! Those are three things I like! And it's in Python!

After digging into it, I ended up with a fairly stripped-down version of his code, to the extent that I just stuck it straight into a Lektor plugin rather than using the Glasseye package itselfThat reminds me, I really need to put the actual code for this site up on Github…. For now I have jettisoned all of his (very nice) d3 charts, because I'm instinctively against the idea of letting the Man design my plots for me. I can make my own d3 charts, thank you very much.But they do look pretty snazzy. I just noticed that the sidenotes don't turn into pop-ups when the screen gets small, which is how they're supposed to work. I should fix that.Update: I did!

On Monday I visited with Lenny TeytelmanI interact with him mostly through Twitter so I might as well link to that. of, and we talked about a variety of stuff including the intersection of open-access science publishing and startups. One of the reasons I made this blog was so I could stick those ideas somewhere…maybe that'll be the next post.

Or maybe I'll change the font sizes and write about that. And I know I'm going crazy with the sidenotes, they're fun.

That was easy



The default style was kind of ugly so I decided to spruce it up with Tufte CSS which is exactly what it sounds like.

A step-by-step account:

  1. First I downloaded the CSS file and fonts from their GitHub page and added them to this project.
  2. Then I changed the layout.html file to point to it.
  3. That was it! Looks pretty nice without any modifications whatsoever. I may tweak it a little bit later.

I just retroactively lied and changed the date on this post, solely so that it would show up in the right order on the blog page. Sue me.

I'm not super happy with how it looks right now anyway—I may decide to get rid of the entire page. Or I just need to write longer blog posts. Luckily no one will ever read this.

Okay I guess I have a blog now


I've finally caved in to my own egomania and decided that everyone needs to listen to me!

Initial thoughts on Lektor:

  • Pretty easy to set up something that works, and I like that it can deploy to GitHub pages automatically.
  • Not as flexible as I would hope—in fact not very flexible at all. Maybe I will discover more flexibility later.
  • It seems like I pretty much have to nuke my previous page to deploy this but that's what git is for, right? Let's see how it goes.