the smaller things

2024: State and Transition

2024-12-01T22:00:00-07:00

I feel I am entering my life’s second act.

My first act was about finding identity, self-esteem, my power. It took me 35 years to do it, but it was a necessary path to arrive at where I am in time and space, among the confluence of forces that now accelerate me forward on the path ahead.

The pains and pleasures of existence are necessary to shape us into the people we are meant to be. What is up to us is how we respond to what we are presented with, giving intention to the choices and actions we take. The most painful moments in my life are also the moments that drove the most growth, and I’m thankful for the lessons they taught me.

But there are also moments that are epochal, marking an inflection point in what would otherwise be inertial drifting. I’ve gathered the will, knowledge, and strength over the last several years to become what I need to be to have the impact I want on the world. There will always be more to learn, but what comes next is execution.

I’m standing at the top of one mountain; I’ve learned all I can from it. Higher ones extend before me. I’ll never be more ready than I am right now, and time will not wait.

Deep breaths.

— david

2020: State and Transition

2020-01-01T20:00:00-07:00

It’s been some time since I’ve shared what I’ve been up to on this blog. Time for an update. Strap yourself in.

TLDR: I’ve developed a more stable motivational approach for myself, and this is the first iteration. We’re boldly going in a select few directions this year. Skip to the numbered lists for details without all the context.

Where we’ve been

2019 was a good year. In roughly chronological order, here is a list of some highlights:

I snowboarded for the first time in over ten years…twice. The first time was on New Year’s Eve (technically 2018) in Flagstaff, AZ. The second time was in the French Alps; I made it down my first black piste without any crazy wipeouts.
I made my first trip to Asia by way of Thailand. Although it’s a pretty heavy tourist destination these days, I challenged myself by going it alone, with only a backpack as my companion. I had friends in Bangkok to show me around and spend time with, but I did quite a bit of the trip on my own. Also experienced my first food poisoning in a foreign country—in the airport right before my flight home.
While on Kho Phi Phi, in the spirit of Arthur Less, I took some time to reflect and write. My goal was to develop a 20-year plan for myself, starting at age 50 and working back to where I sit now, at age 30. I came away from that trip with a sense of direction and purpose I hadn’t felt in a long time. More on that later in this post.
I turned 30. :D
I celebrated my fifth SciPy in Austin, and came away with some new means to execute on my 20-year plan in the near term. More on this below.
I traveled to Seattle to attend the International Space Elevator Consortium annual meeting. More on this below.
I took my Dad on his first trip outside of North America. We spent time in Paris, ate amazing food, and enjoyed so much of the culture the city has to offer. We made a pilgrimage to the American cemetery in Normandy as well; my Dad never thought he’d be standing in it himself.
Last but certainly not least: I developed a closer connection with my partner, whose presence I’m incredibly grateful for. He challenges me out of my comfort zone, and I do the same for him. He makes me a better version of myself with each passing day. It’s the kind of relationship I’ve always wanted, but thought I’d never find.

There’s certainly more to this list, but some things I cannot share…yet. Perhaps in a future post.

Where we are

2019 is over. 2020 is about to begin.

In 2019, I drafted a 20-year plan, starting at age 50 and working back to where I sit now, at age 30. Although it has some specific milestones I’m interested in hitting, emerging from this plan are three threads for my professional interests and efforts. These are:

Health and Medicine
Molecules and Materials
Space

I spent 2019 laying out this plan and performing some of the groundwork for execution. In 2020, I will begin execution in earnest, while continuing to clear the path forward for subsequent phases. Although they appear unrelated, these threads possess some useful cross-synergies, which I plan to take advantage of to speed them all along.

Health and Medicine

My efforts in thread (1), health and medicine, are tied together with my current employment. I will be able to share more of this at a later time. However, in vague terms, at this time I am focused on problems in operations and systems efficiencies. More soon.

Molecules and Materials

My central thread (2) is a continuation of the path I started on in my Ph.D work, but focused on pushing forward the state of the field using my atypical positioning. As an independent researcher not seeking a faculty position in academia, I do not operate under the same incentive structures as many of my peers working in the field. I can therefore do work that is of high-value but under-incentivized, such as software engineering, and I can do so without being as dependent on funding cycles and publication demands.

In 2020, my energy is going into the following projects:

The Open Force Field Initiative - an effort that is poised to reshape the landscape of forcefield development, providing a needed refresh of the approaches we take developing this foundational layer of biomolecular simulation and enabling the rapid advancement of this layer into the future.
The MolSSI Quantum Chemistry Archive - a key enabler of the Open Force Field Initiative, this effort is building a massive archive of quantum chemistry data, working to cover large swaths of chemical space with chemical property calculations.
alchemlyb - a library for performing (alchemical) free energy calculations using data from a variety of simulation (and experimental) sources, with an API similar to that of scikit-learn.

These projects operate at the core of drug design and materials development, likely revealing opportunities in threads (1) and (3).

Space

My last thread (3) is the most pie-in-the sky, literally and otherwise. When I was a teenager, I developed an obsession with the concept of a space elevator. It was the mid-2000s, and this idea was experiencing a surge of popular science interest from Brad Edwards’ 2003 book The Space Elevator: A Revolutionary Earth-to-Space Transportation System.

Like most things from childhood, when I went on to college, and subsequently grad school, other priorities demanded my attention. I forgot about orbital elevators for about a decade. But this year, an unlikely conversation with a friend brought these thoughts rushing back into the foreground. Mental pathways I hadn’t traversed in years were once more the center of my attention.

This thread, a ribbon to the stars, forms the pillar on which the other two derive meaning for me. By the time I am 50 years old, I intend to be working full-time on an orbital elevator, assuming it is not realized already by then (in which case I may still be involved, or doing other things).

There are two components needed for this effort that I intend to push on:

A manufacturing process for a tether with the required material properties has yet to be fully realized. There is excitement around graphene and boron nitride as candidate materials, as well as some manufacturing processes with real potential. Adrian Nixon’s work and thoughts on this topic are particularly enticing. I want to assist with computational approaches where feasible.
Simulation software for architectural design and failure analysis. This software may also evolve into key components to control systems for a real orbital elevator. The ISEC 2017 Study lays out many of the high-value requirements of a simulation engine. I want to lead or contribute software engineering effort.

Where we’re going

Passion and consistency are required. I have not had either in the past several years as I wandered the desert, looking for meaningful things to direct my limited time and energy into. This year made clear to me why I struggled for so long: I was too concerned with identifying things to do (“what”), but had no clear supporting reason for doing those things (“why”). Without a visceral, motivating foundation, a list of things to do quickly becomes a list of chores, and without any other incentives (income, career progression, joy, etc.), they are deprioritized easily in the presence of other options.

My 20-year plan is a living document, and functions as a catalyst for progression and continued evolution. It’s less of a document and more of an ongoing process, which happens to have shape and content at each slice of time. It’s a wind for my sail, and it can change with time and circumstance, but its timescale of change is years, not days or weeks. It is insensitive to swings in mood and short-term whims. Its direction and consistency arise from deeper yearnings for meaning. It doesn’t matter so much where my boat ends up from this wind; what matters is that my boat is moving, and not in complete circles.

The threads that emerge from this process speak to areas I have excitement about, are core to my personality. I will be doing less travel this year, instead applying focused and sustained effort on them. These threads map downward into specific goals and action. Here is a list of concrete goals for this year, stated here for the record:

Re-take the reigns of alchemlyb, which has been a project in hibernation for some time. We will establish a regular release schedule, and I will make responding quickly and consistently on the issue tracker a personal priority.
Publish a JOSS article for alchemlyb, promoting its purpose and use. This will provide a citeable reference for academics putting the library to work.
Collaborate on and contribute to this year’s ISEC study.
Draft a computational material development pathway for an orbital elevator tether. This will require some correspondence with those working in this area, and at least one literature review.
Draft a design document for an orbital elevator simulation engine. This will map from the requirements listed in the ISEC 2017 Study. We will use this document to guide implementation and recruit interested open source developers. This document will be developed in the open.
Draft the manuscript for the final project from my Ph.D. work. It’s taken some time for that work to gestate, and there is now additional context to meaningfully place it in. This will be my first exercise in scientific publishing in many years, so it will be…interesting.

I will be pushing forward issues on the Open Force Field and QCArchive fronts as well, but those efforts are driven by others full time, with me operating in an at-will supporting role. I also have goals aligning with thread (1), but these are tied to my employment and cannot be shared at this time.

Some fun distractions

Although I intend to focus my energies as much as possible into my threads this year, I also intend on the following distractions:

I plan to buy my first motorcycle this year, after some proper training to avoid injury or death.
While it’s still winter, I plan to snowboard at least once. It’s too fun not to take the opportunity.
My partner and I are planning a trip to Portugal, probably in the fall. It will be our first international trip together.
Once the Democratic presidential nominee is selected, I will participate as a volunteer in the campaign for Arizona with my roommate.
I’ve been working to build muscle mass since 2017, and have made significant progress since then. I will continue on this path with my partner’s help. This is a key component to our lifestyle and our plans for the future.

I intend to be pretty ruthless about the distractions I allow into my headspace this year, so this list probably won’t grow (much), barring major unexpected life events.

Sound fun?

I’m always interested in meeting others whose interests align with mine. If you’re committed to action on threads similar to my own, please reach out. I’ve been fortunate to have many fruitful collaborations over the years, and they usually come unexpectedly.

— david

Leaving Academia: building a runway to a career outside of the ivory tower

2017-12-19T18:00:00-07:00

About a month ago, I gave a talk to a group of graduate students in the Center for Biological Physics at Arizona State University on the reasons one might have for leaving academia for industry, and strategies for making the jump. The talk was well-received, with lots of questions throughout and at the end. It featured my own perspective on the process, including a lot of personal experience and hard-earned lessons.

The slides can be viewed in their final form here. Use the spacebar to move forward, hold the shift key and press the spacebar to move backward.

It should be noted that this talk was not constructed as a criticism of academia. There’s a lot to love about academic life, but it’s important for young researchers to recognize 1) the hard realities to this career path and 2) that there are other options available. The core message of this talk is to not limit oneself to an “academia or bust” mindset, as this is probably a bad idea, but instead to lay the groundwork for pursuing multiple possibilities post-graduation.

I’m always happy to expand on the content of this talk. Feel free to ask in the comments below if anything seems unclear or incomplete (likely!).

— david

Stumbling about in 2017

2017-12-19T13:23:00-07:00

I severely underestimated the degree of befuddled I would experience following the end of my PhD. After spending over half a decade in the academic world, with half of that fully intending to leave it for a career in industry, I found myself saddled with a new crisis of identity I did not anticipate. Despite all my preparation over the years, mentally and otherwise, I felt adrift.

It’s been a year since then, and only now do I feel like I’m starting to find a footing, something resembling solid earth. The post-defense hangover is morphing into clarity of purpose, but I had to stumble around the living room through an afternoon that lasted months for it to happen. I can’t help but wonder if this is a common experience for others? I would love to hear your thoughts if you (yes, you!) have gone through a similar period.

I’ve read in many places that people in academia exhibit a disproportionate incidence of mental health disorders over the general population. Whether this is due to the nature of the work, or due to the self-selection of (often eccentric by nature) personalities it attracts, or both, is still an open question. But coming out of it, I learned there were many aspects of my personality that were ill-suited to the world outside. I also learned how dependent I was on the environment for holding together whatever it was that was there, and without that glue, I felt like my sense of self was falling into pieces around me.

2017 was a weird year. This is an understatement for many reasons, and I’m certain for many people besides myself. I sought to find identity in new relationships, new activities, new things. In all these areas, in different ways, I failed. And now, at the end of 2017, I stand at the precipice of a new year with much of the old already cleared away. I would have expected to be in a deep depression from this, but instead I feel an internal peace and joy that I can’t quite put words to.

I’ve started the process of becoming my own friend. I believe for a long time I’ve avoided a friendship with myself, a real respect and care for the person I’m stuck with for life. I did my damnedest to distract myself from his inadequacies, his failures, his stupidity, often attempting to do so with more stupidity. This of course didn’t work. But out of this mess I believe I’ve found a new love, and his name is David.

Perhaps this was not the usual retrospective one might post on a personal blog. It’s also not something I’d normally share, but frankly, I think it worth sharing. We all try to project an image of being “put-together” at all times, to keep up appearances, to show maturity. But we’re not always put-together, and many of us may regularly be high-functioning dysfunctionals in life.

I’m feeling well for 2018. I look forward to spending it with all of you, another year around the star on this lovely rock we call home. Cheers to new adventures.

— david

development log, 2017.01.27

2017-01-27T13:50:00-07:00

2016 was a hell of a year, for many reasons (good, not so good, and everywhere in between). I’m hoping to share more about last year in a retrospective in the next week, but as part of the new year we are now living in, I wanted to start doing a weekly-ish series on what I’ve been up to on development fronts.

I’m now employed by the Beckstein Lab as a research software engineer, and with this role comes a shift in my focus to software development. Over the course of my PhD I built a few software libraries and contributed to at least a couple others. My efforts over the next few months (it’s a short contract) are geared almost exclusively toward finishing up loose ends on many of these projects, plus at least one brand new one. These projects form the core of our software stack, so getting them on a solid footing before I leave is high-priority.

As the first entry in this series, I think it’s worthwhile to share the current status of these projects (from my perspective), and where I’m hoping/expecting them to go. The opportunity to have a focus on software in an academic setting is not common, so I really hope we can come out on the other end with some real interesting developments. :)

datreant

Of all my software projects, datreant is the library I poured the most effort into during my PhD, and it forms the core of my software environment. Since I work with simulation data that can’t easily be shoehorned into a database solution, this library gives a database-ish abstract interface to the filesystem, making it possible to work with my data at a high level while still being able to drill down to any level of detail. This interface is also used heavily for my workflow automation, since it makes writing code that refers to filesystem components (files, directories) in an object-oriented way totally cake.

This library is pretty stable in terms of its overall behavior, though the issue tracker has a lot of things that are wide open and need to be resolved. Some of these are relatively easy, but others will take some more thought. My hope is to get at least one, if not two, releases out before I’m finished here. I’ll probably continue to work on datreant after my time in the lab is up, however. It’s a bit unique, and I think has a lot of potential use for a lot of people. More on that soon.

MDSynthesis

datreant started life as MDSynthesis, a library I developed to maintain my sanity in the face of increasing volume and variety of simulation data I was collecting. Eventually the molecular dynamics-agnostic pieces of MDSynthesis were stripped out and became datreant, leaving MDSynthesis itself as a pretty light library by comparison. This library is how I use datreant in practice, since it gives a lot of convenient functionality for working with MD data.

MDSynthesis isn’t a large codebase, and I’d like to keep it that way. Over the past few months I’ve been leaning more toward making datreant, in particular datreant.core, the recommended library for doing all things datreant-like, and leaving MDSynthesis in maintenance mode. The trouble with the library is that by its nature it can tend to accumulate a lot of ad hoc components, and it also has to track the development of both datreant and MDAnalysis, which makes it a bit a of a pain to maintain. In a world of limited time and energy, I’m more prone to say that users use datreant and roll their own conveniences for working with their data, even if they’re doing MD, but on the other hand MDSynthesis remains a nice little library with incredible utility.

Future uncertain, but for now it persists. If anyone is interested in taking on more of a maintenance role for this library, get in touch.

MDAnalysis

MDAnalysis has a strong developer base, and my contributions over the last year have been mostly in design discussions and as co-developer of the shiny, new topology system. There’s a lot of cool stuff coming through the pipe in the next release, and I’m not concerned about the library’s future.

Over the next few months I’m hoping we can get pickling finally working for all objects so that parallelization can work more generally and as users expect, not just in a shared-memory environment as it does currently. Since the new topology system encapsulates things much more cleanly in the Universe object, this should be very doable, but we just have yet to settle on a specific choice of solution. I’m hoping to scrape together a chunk of time to put forth a working proposal; I already have a prototype of a piece of this from a long time ago, but it needs to be picked up again.

MDAnalysis is a great library with a great existing team, and so I’m likely to put my larger efforts elsewhere over the next few months. I’m still going to be involved in discussions, though, since I think I’m recognized among the group as someone who thinks a lot about the implications of design choices, duplication of effort and interfaces, etc.

mdworks

mdworks is a prototype Python module with building blocks for building workflow graphs using Fireworks, an automated workflow engine we’ve started using in the lab. It’s very early development, and mostly functions as a code dump of things I currently use, but the things currently present are fairly general-purpose.

The trouble with using automated workflows is that they require not only code to generate the graphs, but also the infrastructure to serve and execute them, so it’s nontrivial to get up and running. One of my tasks over the next few months is to get mdworks into a state that’s fairly usable by other members in the lab (which means clear documentation, understandable design choices, functional pieces) and also provide what’s needed to get up and running infrastructure-wise (the hard part).

I strongly believe using automated workflows is the way forward in this field, and if we can achieve our goals here it can pay dividends well into the future. We can ask more complicated questions much more easily when the logistics of computing are largely fire-and-forget, and it makes expensive human time available for doing other things.

alchemlyb

The final software project of note that I’m putting effort into is alchemlyb. This library aims to make doing so-called alchemical free energy calculations easier for the average computationalist, providing machinery for parsing data, preprocessing it, estimating free energies, and checking convergence and robustness. It comes as a response to the rather wild-west nature of doing these calculations once you have data to do them with, as most every lab has their own in-house code to do these calculations. This is a lot of duplication of effort, and it’s prone to error. Existing solutions that are publicly available, such as alchemical-analysis.py, although perhaps correct and useful, are often monolithic and inflexible. These also generally don’t scale beyond single-machine use, so growing datasets become a problem.

The development of this library is an informal collaboration between several folks in the field, with me loosely heading up the project (since I’m paid to do software, not strictly science). Because it is pretty well-defined from the start (these kind of calculations have the benefit of years of experience behind them), I think we can stand this library up within the next few months and push out at least a couple releases. Because of the community interest I’m not worried that we won’t have maintenance long-term, but there’s a lot of work to be done yet. This next week we’re laying out issues for all the major components so discussion and development can begin in earnest.

This is an exciting effort, the results of which should be a firm software foundation going forward for the field. I’m a strong believer in the idea that in order for us to focus our efforts on new, harder things, we have to make established techniques routine and easy. This is a specific effort to make that so for alchemical free energy calculations.

Check out this gist if you’re interested in the design ideas behind this library.

Let’s get to work

Obviously from this list there is no shortage of things to do, and I’m realistic enough to know that we probably can’t achieve everything. We will, try, though, with the aim of inching forward to stability. There are relatively few people in the lab who’ve taken an interest in software engineering as I have, so the stack needs to persist long enough to survive without another software-focused person around to keep things going. Whether that works out, only time will tell.

— david

datreant at SciPy

2016-09-22T13:30:00-07:00

It’s been a whirlwind of a summer, and now that it’s officially fall I think I should take a moment to mention one event I failed to document for posterity here on my blog. This summer I had the opportunity to present a core project of mine at SciPy 2016: datreant.

This project forms the core of my data analysis workflow these days, both automated and human components (also known as me). The talk functions as a nice 20-minute overview of datreant, what problem it addresses, and how it works. Give it a gander if you find yourself drowning in data but can’t really escape using the filesystem itself as your data store of choice.

Also, there’s now a citable paper for datreant. Check out the SciPy 2016 proceedings, and consider citing datreant if it proves useful to you in your work:

D. L. Dotson, S. L. Seyler, M. Linke, R. J. Gowers, O. Beckstein. datreant: persistent, Pythonic trees for heterogeneous data. In S. Benthall and S. Rostrup, editors, Proceedings of the 15th Python in Science Conference, pages 51-56, Austin, TX, 2016. SciPy.

This conference was particularly interesting because I managed to convince not only my partner-in-crime and labmate Sean Seyler to attend, but also my mentor and PI Oliver Beckstein to check it out for the first time. I’m happy to say they came away very satisfied with the experience!

I should mention that Oliver also gave a very nice talk on MDAnalysis, giving special emphasis on our vibrant community of active developers and users. We also produced a proceedings publication that functions as an update to the original MDAnalysis paper, giving details on both new and upcoming functionality and design changes in the library since.

With that, it’s back to thesis writing. My projects are all nicely wrapped up at the moment and I’m currently in the throes of compiling it all into an exhausting…er, exhaustive document. I’ll be fun again after November 4th. :D

— david

or/and

2016-09-04T14:00:00-07:00

often we think in ‘or’
a choice between two or more
when we could call it ‘and’
and give ourselves the freedom to be all
to enjoy all
to have all

we dichotomize, split,
we say “him or her”
we say “me or him”
we say there’s a choice that must be made

but ‘and’ is an open set of arms
it invites, and accepts
it understands
‘or’ seeks to partition the world
our lives, our bonds
‘and’ says, let’s connect
let’s be whole

Blogging at BPS 2016!

2016-02-25T11:00:00-07:00

The 2016 Biophysical Society Annual Meeting in Los Angeles begins this Saturday, and I’m happy to announce that I’ll be blogging for the conference blog during the course of the week. My focus will be on new developments in software, particularly open source projects.

If you have a project you’d like some exposure for, or just want to talk shop, feel free to ping me on twitter (@dotsdl). See you in LA!

— david

2015: A retrospective

2016-01-17T17:00:00-07:00

It’s been some time since I last posted, but that’s not because I’ve been twiddling my thumbs. The year 2015 saw some big changes, and I wanted to take some time to reflect and share on where we’ve been (and where we’re going).

It was about a year ago when I landed in Davis, CA, to attend Titus Brown’s three-day Train-the-Trainers Software Carpentry instructor training. I met a lot of folks that work in bioinformatics (not my field, but not far off), as well as others involved in open science and open software. It was a transformative experience, with the practical benefit that I was offically able to teach Software Carpentry workshops after finishing up some final requirements. I went on to teach four in 2015, and a fifth just a week ago.

February saw my first trip to the Biophysical Society Annual Meeting with research to present, having first gone in 2012 when I was just starting out. I met many of Oliver’s (my PI) colleagues from Oxford and elsewhere, but spent a good deal of the meeting finishing up some exciting results that had just come in. The trouble with giving a talk is that you can work on it up until you get to the stage…so you will.

The meeting was great, though shaping new results into a talk with short turnaround was made possible by a software package I’d been building called MDSynthesis, which that winter was finally in a state to be (exceptionally) useful. It sped up my ability to slice, dice, and aggregate datasets from myriad simulations I had performed, taking advantage of pandas DataFrames and HDF5 persistence to make fast exploration possible. I was on fire, and the Baltimore cold couldn’t put me out.

I attended my first SciPy conference in July, where I presented MDSynthesis as a poster. The conversations I had there influenced big changes in the package that are still shaking out, one of which being the splitting out of the core persistence functionality into a package called datreant. A few other devs from MDAnalysis and I are now engaged with figuring out the future form of this package, and the results are looking to be really quite awesome.

Speaking of MDAnalysis, Google Code finally gasped its last breath, and this forced the project to move elsewhere. Its new home became GitHub, and, perhaps unexpectedly, this became perhaps the best thing to happen to the project in a long time. The great development tooling that GitHub provides has catalyzed a flurry of new work, and has attracted new contributors, including some that are now coredevs (yours truly included).

The value GitHub added to MDAnalysis development spurred us to (finally) make a Becksteinlab org, at which the open source projects incubated in our lab are now hosted. I’m proud to be in one of those “with it” labs, though a challenge remains in getting busy lab members to actively work on projects that have a public face and getting them in a useful state. I think this is a culture our lab intends to encourage, but it’s no secret that academia doesn’t directly value this kind of work today. But we’re building for the world of tomorrow.

In October I traveled to Germany (my first time in Europe) for the CECAM biomolecular simulation workshop-of-workshops in Jülich. Despite wifi issues in both the venue and the hotel, Philip Fowler and I managed to start things off with a Software Carpentry workshop that covered the Unix shell, Python, and Git. Oliver and I followed this with a (too short) MDAnalysis tutorial, doing things SWC-style and live coding in the Jupyter notebook (using pre-made notebooks as cheat-sheets rendered with nbviewer on my phone, of course; we’re not magicians). Both workshops were very well-received, with people appreciating most the interactivity and the ability to play directly with the library during the breakout components of the live sessions.

In November, Richard Gowers visited our lab here in Arizona for a few weeks. After treating him to some authentic New Mexican food (red or green?), he and I got to work gutting the existing topology system of MDAnalysis. The result is more performant and more flexible (a rarity!), and should finally get merged ahead of the long-sought 1.0 release. We’re still not finished adapting everything in the old topology scheme into the new one, but we’re in the last 10% (where 90% of the time is spent).

So where does that leave us in 2016? Well, this is my last year as a graduate student, and I intend to defend my dissertation in the fall. I am in production mode at the moment preparing new simulation systems to run over the coming months. Once these are baking I’ll be working on MDAnalysis and datreant/MDSynthesis core components, while also preparing my analysis codebases for the data that will be coming down the pipes. Writing (papers, dissertation) is also set to begin in the next month or so. In February I’ll be presenting work that should be published soon at the upcoming 2016 Biophysical Society Annual Meeting. There’s no shortage of things to do. :)

I also hope to attend SciPy again this summer, and will be applying to job opportunities throughout the year in preparation for 2017. If you’re an employer, or know of anything I might be interested in, by all means, shoot me an email.

Cheers to a new year!

— david

Answering biological questions using HDF5 and physics-based simulation data

2015-09-17T15:00:00-07:00

I recently had the privilege to share a bit of my work on the HDF Group blog by way of a guest post. In our lab we generate increasingly large and diverse simulation datasets, and maintaining sanity and productivity in spite of these scale ups have been a challenge. This post details one approach to the problem, and it makes heady use of HDF5 for efficient data storage and retrieval.

If you have an interest in Big Data challenges and aren’t already subscribed to the HDF Group blog, one of those two things should change. :D

— david

SciPy 2015: come for the conference, stay for the people

2015-08-11T13:00:00-07:00

It’s now been several weeks since I returned from my first SciPy, and I realized I had yet to actually write about it on my own blog. Well, late is better than never. If nothing else, the time delay has allowed the dust to settle for a more coherent post. :)

Short version: SciPy was perhaps the most fun I’ve had at a conference.

Why? Several reasons. First, the audience is very diverse: most are working in science but many others are working in tech and software development. This is in contrast to many of the conferences I’ve attended which are primarily scientists working in my field, very few of which spend much of their time developing and maintaining software.

Second, the conference itself is different than most in terms of its basic structure, composed of:

2 days of tutorials
3 days of main conference
2 days of sprints

Since this was my first time attending, I decided to get the full SciPy experience and attend the whole week. I’m glad I did.

The two tutorials I most enjoyed were those on machine learning with scikit-learn and using bokeh to create interactive plots. Although I had played briefly with both packages before, these sessions offered a more thorough view to what can be done with them, and most importantly, how. In particular, for scikit-learn I was struck at how well thought-out its built-in parameter sweeps and cross-validation machinery was, and it’s given me ideas for how to build similar robustness machinery for other packages, e.g. mesa. I’m not entirely sure yet where I might make use of bokeh, since ultimately plots I produce need to be exported to a printable form. However, for publishing data visualizations to the web it’s a great option.

The conference itself sported three simultaneous tracks of talks, a poster session, and daily lightning talks. A few of my favorites:

Dask: Out-of-Core Numpy and Pandas through Task Scheduling: a talk on dask, which provides data structures that can do complex out-of-core operations with an API similar to numpy and pandas.
HDF5 is Eating the World: a talk by Andrew Collette (author of h5py) on ways to wield HDF5 effectively, as well as exciting new developments in HDF5 itself.
Deep Learning: Tips from the Road: a talk by Kyle Kastner on deep learning, its uses, and its limitations. This is a great, short intro to neural networks.
Agent Based Modeling in Python with Mesa: introduction of mesa, a new package that fills a hole in the python ecosystem: a package for building agent-based simulations.
VisPy: Harnessing the GPU for Fast, High Level Visualization: a great talk by Luke Campagnola on the capabilities of VisPy to generate complex visualizations in real time using the GPU and OpenGL.

There are many more where that came from, including:

Each day of the main conference featured a keynote, all three of which are worth watching.

Since it’s impossible to attend everything, I’m extremely thankful all of these talks can be viewed directly on YouTube. Check out the full playlist for plenty more.

The last two days featured sprints. For the uninitiated: these are long blocks of time during which you can work on issues in a codebase collaboratively and in-person with others. At SciPy, however, mostly these are just a great way to get involved in new projects and work alongside some of the core developers. I’m particularly interested in machine learning applications to simulation work, so I split my time between working on scikit-learn and mesa. Although I only ended up submitting a couple PRs to scikit-learn over the course of the weekend, I got a good sense of the structure of the packages and had memorable discussions with the developers. The only problem now is figuring out where I’m going to devote my (rather limited) time outside of graduate school to open source projects that aren’t mdanalysis related. The upside is there are really no bad choices.

Besides all the new tools and technical developments SciPy made me aware of, what I value most from the conference are the people that I met and the connections I made with them. The scientific Python community includes some of the most intelligent and passionate people I’ve ever met. It was a pleasure to spend a week with a few of them.

— david

SciPy 2015: Introducing MDSynthesis

2015-06-29T23:00:00-07:00

Although I’ve announced as much on Twitter, I’m excited to present a poster talk this year at SciPy. It’ll be my first time attending, and I’m looking forward to meeting others that are passionate in advancing science through software, and in particular with Python.

I’ll be presenting a software package I’ve been working on called MDSynthesis, which has vastly improved the way I do science with molecular dynamics (MD) simulations. MDSynthesis addresses an important bottleneck in MD research: going from raw simulation data (perhaps many terabytes, spread over tens to hundreds of simulations) to information that allows us to answer biophysical questions. I’ll explain…

One of the obstacles to using modern data science tools like pandas to analyze MD data is the multitude of formats the MD ecosystem trades in. CHARMM and NAMD use DCD files, AMBER uses a NetCDF-derived format, and GROMACS uses an XDR format; all told, there are at least 13 different formats used for storage of MD trajectory data, each with unique strengths and limitations. MDAnalysis is a python package that provides a common interface to many of these formats, turning trajectory data into numpy arrays that can be handled with the full power of the python universe.

But the diversity in trajectory formats isn’t the only obstacle to distilling information from MD data; what’s also a problem is the variety of inputs available for building any particular simulation system. For example, when simulating a single protein, I have a lot of choices in: forcefields, starting conformation, protonation states, solvent, ions, temperature and pressure algorithm…the list goes on. The picture becomes more complicated when one wants to run different types of MD, as there are also a wide variety of enhanced-sampling methods available for use.

And that’s still not all: trajectory data can take a while to churn through to extract measures we are interested in, depending on the measure and depending on the number/length of trajectories. It’s therefore useful to store intermediate data so we can interactively explore it.

Managing this complexity is burdensome, and frankly, boring. I’d rather spend my limited time and energy doing science than managing my ever-growing collection of data. Furthermore, I want quick, specific, and easy access to the data I have so that I can begin answering questions.

MDSynthesis has done this for me. The basic idea behind the package is to provide persistent objects that serve as data storage units, called containers. One such container is the Sim object. This can store any number of MDAnalysis Universe definitions (topologies + trajectories), along with atom selections for later use. Sims store their state directly to disk in a thin HDF5 database (using PyTables), allowing recall of the same Sim instance later, or at the same time in another python session. Most importantly, Sims give an interface for easily storing pandas and numpy data structures in HDF5 format with no fuss, with just as easy recall. Almost any other python data structure can also be stored just as easily; the container will pickle what it can’t serialize to HDF5.

Beyond Sims, there are also Groups, which can store Sims and other Groups as members for easy recall of whole ensembles of containers and easy aggregation of their stored data.

Those are the basic elements; more details can be found in the docs. We just made an alpha release of the package last week which is already usable for daily work, but the project is still very young. What’s particularly exciting for me is that development of the package has already fed back into development of MDAnalysis, with even more performance and persistence functionality on the way.

If you find this software useful, let me know! If it’s missing something that it sorely needs, feel free to submit an issue and we’ll get cracking on it. Pull requests are also welcome!

— david

Software Carpentry workshop at Oklahoma State University post-mortem

2015-05-30T18:00:00-07:00

This week I taught my first Software Carpentry workshop at Oklahoma State University. The workshop had been in such demand that we had a total of four instructors, including Jonah Duckles, Kate Hertweck, Thomas Guignard, and myself. I arrived at the hotel close to 2am the first day of the workshop, and was running on nespresso during most of the morning session.

Though originally Thomas and I were set to teach one room together, due to flight troubles Jonah took over the session on the Unix shell that kicked things off. I spent most of the time fixing issues with GitBash (usually fixed by reinstalling it) and helping people connect to the network (curse those certificates!), but these issues didn’t affect most of our learners. I was able to spend at least a little time watching Jonah teach, too, and I can say I learned a few things myself (e.g. that tr is a thing!).

I taught the session on Python, which was split into two parts over the two days. This decision was made at the cost of omitting SQL for Day 2. It worked out well because even though I went too fast the first day (this was the dominant complaint from feedback), we still only barely touched on functions by the end of it. The second day’s session was entirely filled by the second half of material, which built on that of the first.

This was my first time teaching the SWC Python lesson, and since it’s become an indispensable tool for doing my own research, I made use of the iPython Notebook. To help combat the problem of learners getting behind and needing to see content that I’ve since scrolled past, I did all my work out of a Dropbox folder and shared a link to my notebook file on the etherpad. Although a good idea, the biggest problem was that most learners couldn’t figure out how to view the file, since downloading and clicking on it usually results in it being opened in a text editor (they’re JSON files), leading to more confusion than answers. What’s more, it’s hard for many learners to find their working directory (where they’re working in a GitBash / terminal shell session) in the graphical file manager, so telling them to download the file and move it to the directory their notebook session is running from results mostly in blank stares.

Fortunately one of our helpers added the notebook link to NBViewer, which renders the notebook directly in the browser so the students didn’t need to bother with the file at all. This required some fiddling to ensure that NBViewer actually picked up the updates whenever I saved my working notebook, but otherwise it worked extremely well. The students very much appreciated being able to click the nbviewer link in the etherpad and view my entire running notebook, hitting refresh to see it as it updates. I should note, however, that the time between me saving and the updated notebook showing up on refresh was at least a couple minutes; Thomas did some troubleshooting on this front to try and fix this, but I don’t think we managed much better than this. But I’ll take that over nothing! :D

I’ve since removed the Dropbox share, but the final notebook can be viewed here.

After the session on Day 1, I cleaned up the working notebook. I didn’t add anything that wasn’t discussed in the session, but instead recorded more of my commentary in the notebook itself since there wasn’t time to record it live. The learners appreciated this the next morning, especially with the NBViewer updates, since they could refer back to what we had done in case their notebooks were missing things we would need that day.

I made a conscious effort on Day 2 to slooooow doooowwn, and I think I succeeded. We ended up making it to the goal, which is how to write Python scripts that behave like shell commands (showing that shell commands are not magic, and you, YES YOU!, can write your own!). The feedback was generally more positive on this day, and the discussions that followed indicate that people were happy with what they had spent the time learning.

Thomas closed out the day with a lesson on Git. Despite it being his first time teaching that particular lesson (it didn’t show!), he went at a good pace and we were able to get through pair-wise collaboration on a publicly hosted git repository (using GitHub). Among the teaching tools I plan to steal from him is his analogy of commits as group photos. That is, putting things in the staging area can be thought of as bringing people into the frame of the photo (and perhaps excluding others), while the commit is taking the photo itself and then clearing the frame.

It was great to meet and learn from the learners, helpers, and my fellow instructors. I got the full Oklahoma experience, too little sleep, and plenty of ideas for next time. Looking forward to many more!

Thanks especially to our host Dana Brunson for putting this together!

— david

Upcoming Software Carpentry workshop at Oklahoma State University

2015-05-13T18:00:00-07:00

In two weeks from today I’ll be in Stillwater, Oklahoma, teaching at my first Software Carpentry workshop. The topics will include learning the basics of a Unix shell, programming in python, version control and collaboration with git, and data management with SQL. Of these, perhaps SQL is my weakest area since I hardly ever have need of it, but it’s a good excuse to brush up! Don’t worry folks: I doubt that will be one of the topics I’ll be the lead instructor on. I’m very excited to teach any of the others. :D

Sharing the skillsets and tools with the researchers whose work can benefit the most from them is why I got involved with Software Carpentry, and I’m excited to finally start contributing to this effort. I plan to share my preparation and post-mortem (is debriefing a better word?), so watch this space in the coming weeks!

— david

I’m now a Software Carpentry Instructor!

2015-03-25T10:00:00-07:00

Back in January I had the privilege to attend an in-person Software Carpentry instructor training in Davis, CA, hosted by Titus Brown. Software Carpentry is a non-profit volunteer organization that puts on “bootcamps” at institutions all over the world teaching best practices for building software to do science efficiently. The three-day training helped to improve my own awareness of how people learn the technical skills we teach, and I learned plenty about my own teaching habits (good and bad). I also met many great people doing awesome work in the open science community. It was well-worth the couch crashing and braving the cold (Arizona weather makes you a wuss).

On Monday, I gave a five-minute lightning lesson as an introduction to Python to Greg Wilson, completing the final requirement for becoming an instructor. I’m looking forward to teaching bootcamps here at ASU this year and next, and hopefully getting out a bit to teach some elsewhere in the country. I also hope to contribute to the efforts of Data Carpentry with material specific to working with molecular dynamics data. I’d be keen to discuss this topic with anyone else who’s interested. There’s a lot that could be done on this front.

— david

Bumming around Baltimore; or, the Biophysical Society Annual Meeting 2015

2015-02-11T22:45:00-07:00

It’s been a while since I last wrote a blog post, and this is for a couple (very good) reasons. First, I’ve been hard at work on a software package for making molecular dynamics data exploration more manageable. More on that in another post to come soon. Second, I had a major conference to prepare for, this being the Biophysical Society Annual Meeting in Baltimore.

I gave a talk at this meeting about our recent work on sodium proton antiporters. The talk was well-received and the questions allowed me to clarify details that I probably flew through during the 12 minutes I had to speak. I’m very happy to have had the opportunity to share my work to a full room.

Though the talk was a success, for me this last week was more a personal test in how quickly I can produce new data and distill useful information from it. I spent a significant amount of time over winter break and the first bit of January restructuring my workflow, and I am now significantly faster at this. It isn’t just pipeline, either; the new approach allows me to effectively explore my data to generate new inferences and quickly test them.

As an example: I discovered what would become a key element of my talk on Saturday night, and I gave that talk on Monday. It was a bit too much like playing with fire than I’d like to risk in future meetings, but it was well-worth it this time. The fast turn-around itself is encouraging, since it’s looking to be an indication of a very productive year.

The meeting also brought me in contact with a host of great peers (and giants) in the community. I’m glad I got to meet the faces to so many names in such a short period of time. I had great discussions and made new friends.

I’ll be spending the next few days relaxing in D.C., but I’m looking forward to getting back to the lab. Plenty of fresh ideas to work with in the coming year. Despite being physically exhausted, I am very pleased with my time in Baltimore.

— david

From Wordpress to Pelican

2014-12-26T22:15:00-07:00

Back in September I decided to begin sharing some of my thoughts on science, software, and education by blogging regularly on my exploits. I’d previously built a website on top of Wordpress for Sundial, so I decided to go with that CMS. I purchased a domain name through GoDaddy, and out of convenience purchased Wordpress hosting through them as well.

Wordpress is a fine CMS, but I despised writing in the built-in editor. I’m a vim nerd, and really wanted to write in plaintext in my editor of choice. Also, I wanted to start sharing code snippets and iPython notebooks, and Wordpress was appearing an awkward choice at best for this.

Enter pelican, a static site generator written in Python that uses ReStructuredText as the markup of choice for articles. It took a little time to set up, but most of this was spent trying to approximate my old blog’s look by way of a custom theme.

If you’re interested in blogging with a statically-generated site through pelican, start by installing the python module locally with pip:

pip install --user pelican

Then build a skeleton that includes everything you need to get started with:

pelican-quickstart

The pelican docs have up-to-date information on how to proceed.

Since pelican generates static html files, they can be cheaply hosted. In fact, GitHub provides free page hosting via GitHub Pages. I created a repository for my site and edited the Makefile included in my pelican project directory to point to it. This allows me to regenerate and publish my static site with:

make github

It doesn’t get much easier. I’m very pleased.

EDIT: I have added my blog source to GitHub. Perhaps if you’re having trouble getting something working it will be of help.

Attempting to be open in a (mostly) closed field

2014-12-26T16:23:00-07:00

I’ve been following Titus Brown’s blog for a little while now, and this blog is part of an effort to emulate his (relatively conservative) brand of open science. However, if it wasn’t obvious from my lack of new content over the past few months, I’ve been in a bit of a rut. What gives?

Well, for one thing I don’t “own” the research I produce. Or, at the very least, I don’t completely own it. There are my collaborators to think about, not to mention my PI, whose ultimate permission I must obtain to openly discuss the things we are hammering on. And in a competitive field, there is the real fear (valid? I’m not sure) of being scooped.

So, what to do? I think the landscape science operates in is changing, and the way science is done must change in order to cope. Funding is becoming harder to get. Reproducing scientific work, even those dependent on software alone, is difficult. And these days obtaining data is becoming less of a problem; instead, in many fields the emerging problem is how to cope with data glut, which itself requires a new skill set.

The open science movement seeks in part to take the lessons from the open source software movement and apply them to science. This is particularly salient for someone in my field, since in simulation-based work raw and distilled data is both generated by software. Open science finds little contradiction here.

But the more competitive a field is, the more perceived incentive there is to keep work bottled up until the big reveal in the form of a journal publication. Rarely this publication includes the full data set (in my field, this would mean raw simulation trajectories and the input parameters) and all code (mainly analysis code, though not all molecular dynamics codes are open source). What’s more, the main input to our simulations are experimental structures, and the crystallography community is known to be very competitive. We are thus constrained by our experimentalist collaborators’ needs.

If anything, I’ll be using this space to share what I can about my work, especially ideas with regard to software and scalable analysis (with a bent toward applications to molecular dynamics problems). Change in science is slow, but I’ll try to do my part here.

— david

Paywalls and lost knowledge

2014-10-16T05:21:00-07:00

It’s taken me a while, but I now have a system for keeping up with (however poorly) the exponentially growing scientific literature. I’ll expound more on my method of choice in another post, but no matter how fast I try to get at processing papers, new and old, one thing disrupts my flow more than any other: paywalls.

Every scientist knows them well. You’re reading papers, and you see a detail that piques your curiosity enough to check the reference. You then type as much of the title as you care to into Google and click on the first link that looks like it might have a manuscript behind it. Oh no, it’s just Pubmed. But it has links to the full text! Click.

Quickly you scan for a PDF download link. But there’s a number next to it. For the low, low price of $28.00, this article could be yours! Or you could “rent” it for $4.00, whatever that means.

I have roughly 400 articles in my Zotero library, and it’s growing fast. Luckily I’m privileged to have access to ASU‘s library subscriptions for most (though certainly not all) journals, but this requires me to engage in further gymnastics to use the proxy server to get access.

By the time I’ve pulled an article (or more likely several) into my library, I’ve forgotten the context of why I cared to find it in the first place. I may have jotted down a note or two, but the full moment is lost, possibly forever. What’s worse, though I may be able to scrap most of my thoughts back together and carry on with chasing the rabbit down the idea hole, imagine being a student at a smaller university with a less-endowed library. That idea that led to the chase may never find what it needs to bother pursuing.

Every paywall represents an opportunity lost, if not several. They are plaque in the arteries of science, slowing down everyone. Luckily the scene is changing with the efforts of the open access movement. It’s certainly time.

— david

Software Carpentry @ ASU

2014-09-29T04:54:00-07:00

As I mentioned in a previous post, this weekend I participated in my first Software Carpentrybootcamp. I had the pleasure of meeting the instructors and all the other helpers involved on Friday over pizza and beer, and in particular spent considerable time nerding out with Naupaka over all things vim and tidy data.

On Day 1, the topic of the morning was R. From what I understand, it was only recently that Software Carpentry decided to add R to their curriculum. Though I certainly learned plenty myself as I rushed about helping participants through small problems, there is a lot of good stuff (and plenty of potential) here.

R is an analysis tool first and a programming language second. This makes it a pragmatic choice for researchers but still a difficult one to teach. We used RStudio as the environment for introducing things, and this may have taken the edge off for the command-line averse. I didn’t get a chance to follow along with the exercises too much myself, but I’m particularly interested in learning more about the use of factors. If anyone has any resources for understanding what factors are, why they are useful, etc., I’d love to hear about them.

That afternoon we switched topics to the shell, or more specifically bash. The session started well enough, but given a distribution of participants that ranged from zero experience to intermediate, it proved difficult to please everyone. Also, as a note to anyone that does a bootcamp on the shell (or even any topic): give a motivation behind everything you demonstrate, both in broad and immediate scope. Although it can be obvious why a given trick is useful to an experienced user, the novice can often be left wondering what benefit this has compared to what they already do to get work done. This is especially true for the shell, since 90% of work done in the shell is moving around a file system, which most scientists already accomplish by clicking around a file browser. People have to see a clear advantage to adopt new practices.

Day 2 (today) started off with git. The instructors did well to put extensive focus on giving motivation for git’s use, given the feedback from the previous day’s session on the shell. This was especially important for git, since for many scientists it is considered to be non-essential in the toolbox of software things. Software Carpentry hopes to change this.

The gist: git is great for more than just code. Though originally produced to address the needs of the software community, as a version control system git works particularly well for paper writing, alone or with collaborators. And even though git is optimal when working with text-only files, it is perfectly happy to store away anything you like and version control it. Further, pushing the materials used to build a manuscript to a public repository host like GitHub is a great way to address the well-acknowledged problem of reproducibility in science.

During the afternoon we turned our focus to SQL, using an SQLite database as our toy case for running queries against. I was running out of steam by about this point, and I mainly focused on helping the folks on Windows to get sqlite3 working under Git Bash (not hard, but for beginners running around the filesystem is an expensive operation).

Overall, I’m happy I got to help put this on and I hope to be involved in a growing SC community here at ASU in the very near future. Assuming space is still available, I’m also hoping to attend Titus Brown’s instructor training in Davis this coming January.

Thanks to everyone involved! Looking forward to more!

— david

Creationism’s beef with scientific theory

2014-09-25T20:48:00-07:00

This post was originally posted to Facebook. It was a response to a creationist friend who posted a video of another creationist attempting to discredit the usual set of scientific theories. I felt I should share it for others because I’m terminally optimistic, and I needed the outlet.

One recurring mistake made by creationists when trying to discredit science is this: it is assumed that science must observe every phenomenon a theory posits to take place in order for that theory to be considered valid. When a creationist says repeatedly that “there is no evidence for THEORY X”, he is oftentimes operating on his standard that every prediction of that theory must be tested. This is unreasonable for science to progress; worse, it’s shown itself to be unnecessary. The value of theory is that it is better than a library of observations; it gives greater insight into what’s actually happening.

To use an analogy: many of my students in an introductory physics course spent the beginning of the semester doing physics problems with arithmetic. They were literally throwing numbers around in ways that “made sense” to them until they arrived at an (often wrong) answer. To break them of this, I began asking questions that required some higher level thought. Instead of “how high on the wall does the projectile strike” given some set of initial conditions, I asked “what is the minimum speed with which the projectile must be fired in order to go over the wall.” Those that tried arithmetic quickly realized they’d have to trial-and-error it to get the answer, which would be silly.

The ones that solved the problem instead used the theory they had learned in class (2D kinematics, a purely descriptive part of classical mechanics), algebraically finding the speed I asked for. I then asked them how this speed changes with firing distance, and they could answer this question by looking at the symbolic answer. I even asked them how quickly this speed changes with a change in firing angle, effectively requiring a derivative.

When creationists demand evidence for every single facet or prediction of a theory, they are demanding that science do the arithmetic…for every variation of the problem the theory is addressing. This is unreasonable. Worse, it doesn’t really tell us much more information about the set of phenomena we are addressing, just like solving the same problem over and over again with different numbers doesn’t really give insight into what’s actually happening.

With a finite number of scientists working on a much larger set of problems (and growing, as we are able to probe more and more of nature), our limited resources are better spent proving the principles and then moving on, using those principles to discover ever more. Quantum mechanics has probably less direct evidence for it than biological evolution, but we didn’t waste time endlessly testing every boring case the theory presents. Instead, we took advantage of it to build materials that now allow the computer you are using to post emoticons on Facebook.

So, thank a theory…or something. And have a nice evening.

Upcoming Software Carpentry bootcamp @ ASU

2014-09-23T23:00:00-07:00

This weekend (September 26 & 27), I will be partaking in my first Software Carpentry bootcamp, held right here at ASU. I will be helping with some of the sessions myself, but otherwise I look forward to learning some R and SQL skills with some like-minded peers.

For the uninitiated, Software Carpentry is an organization that actively works to improve the computational, programming, and data analysis skills of scientists. This is more than necessary, because though science often pushes the boundaries of what computing can accomplish, good software practices are relatively rare among scientists. Version control, code readability, and software design is becoming increasingly important as the complexity of computational science increases.

I’ll post about my experiences after having attended the two-day bootcamp. If you are interested in attending yourself, register here. It should be a good time!

— david

Ahoy there!

2014-09-22T00:02:00-07:00

The last time I tried keeping a blog was when I was around 20 years old, and the topics of the day were mainly of interest to only 20-year-old me. I was just coming out as gay, learning to deal with feelings I didn’t understand. I spent a lot of time thinking about religion, and plenty of time arguing about it with others. I didn’t know much about the world, but I was trying learn.

I’m now 25, and in my fourth year of graduate school. I am invested in my research (plenty to write about on that soon), and I am in a stable and fulfilling relationship. Grad school started out (very) rough, but I’ve found my niche. I’m generally pleased.

I decided it was appropriate to start sharing my thoughts and experiences with others. It’s not something I’m used to, so it may take a post or two before I’ve found my groove. Some posts will be about science (both content and sociology thereof) and software development; others will chronicle my teaching and thoughts on the state of education. Yet others will be personal updates. I think there is space for all of this here.

Plenty to come.

— david