Archives For writing

A couple of days ago, Peter Krautzberger sent me an email asking if I was interested in becoming an editor for Mathblogging.org. According to Mathblogging.org’s about page:

From research to recreational, from teaching to technology, from visual to virtual, hundreds of blogs and sites regularly write about mathematics in all its facets. For the longest time, there was no good way for readers to find the authors they enjoy and for authors to be found. We want to change that. We have collected over 700 blogs and other news sources in one place, and invite you to submit even more! Our goal is to be the best place to discover mathematical writing on the web.

Mathblogging.org is run by Samuel Coskey, Frederik von Heymann, and Peter. Felix Breuer also had a hand in the site’s creation. The current editors are Peter Honner, Fawn Nguyen, and Shecky Riemann.

Lately, I’ve been feeling stretched a bit thin, so I told Peter that I needed to think about it before deciding. I’ve been trying to be careful about the new projects I take on so that I don’t get in over my head. But…then I remembered the talk that Joe Gallian gave at the conclusion of my first Project NExT workshop in 2008. The theme of Joe’s talk (which he gives every year for Project NExT) is “just say yes.” His thesis is that by saying “yes” we open doors to new opportunities and by saying “no” we close ourselves off to what might have been. Okay, I’m sure Joe would admit that we shouldn’t say “yes” to everything, but I believe he would say that most of us say “no” too often.

I took Joe’s talk pretty seriously my first few years post PhD and I think it has worked out pretty darn well for me. There have been numerous times I thought that I should say “no” but followed Joe’s advice instead. Most of the time it has worked out for the best. A good example is when Ivars Peterson asked Angie Hodge and I to start blogging for the MAA. Actually, let me back up a notch. First, Nathan Carter suggested that I apply for the editor position at Math Horizons. I implemented Joe’s philosophy and talked Angie into applying with me as co-editors. Alas, we were not chosen and instead the committee selected the most awesome Dave Richeson. However, as a result of our application, Ivars approached Angie and I about starting up Math Ed Matters. Around this time, I was beginning a new position at Northern Arizona University and I was concerned that my tenure committee wouldn’t value this sort of work. I dragged my feet for a couple months, but eventually Joe’s voice in my head won out. Angie and I have only been blogging for a few months, but we certainly made the right decision. Lots of new opportunities have presented themselves as a result of the blog. I could go on and on about similar choices.

Okay, by now you’ve already guessed that I agreed to Peter’s offer. So, what does being an editor entail? I already keep up with quite a few math-related blogs, but now I just need to “star” the ones on mathblogging.org that I find the most interesting/enjoyable/useful/compelling and leave a brief comment about them. Doesn’t sound too bad. Of course, to be fair I should start reading a few more of the blogs that pass through.

Yesterday was my first day on the job and I already selected two recent blog posts for Editors’ Picks:

  1. Name 5 top journals you read… by Peter Krautzberger
  2. A Problem with Assessment by TJ Hitchman

I’m looking forward to reading more excellent blog posts and seeing if Joe is right again.

Inspired by a recent discussion on Facebook about accepting friend requests (on Facebook) from students, Matthew Leingang (Courant Institute), Ron Taylor (Berry College), and I decided to write a short article about the issue with the intention of submitting the article to MAA FOCUS. Also, I must give credit where credit is due. The idea for writing the article actually came from Karl-Dieter Crisman (Gordon College).

For some time now, I’ve been wanting to experiment with coauthoring a paper using GitHub. Since our paper about potential Facebook policies for teachers is going to be relatively short and simple, I figured that this would be a good project to experiment with on GitHub. In case you are wondering what the heck GitHub is, according to Wikipedia:

GitHub is a web-based hosting service for software development projects that use the Git revision control system. GitHub offers both paid plans for private repositories, and free accounts for open source projects.

Most people use GitHub for collaborating on software projects, but the service is becoming increasingly popular for hosting teaching materials, including open-source textbooks. I currently use GitHub to host a few of my inquiry-based learning (IBL) task sequences. For example, you can check out the LaTeX source for my IBL introduction to proof notes by going here.

In my view, there are lots of advantages of using GitHub to host such things. First, it makes the source public. Not only can someone always find the most up-to-date version of something, but they can also contribute to its improvement. GitHub makes it easy to do this sort of thing and it isn’t as scary as it sounds. Basically, you fork a repository, make changes, and then submit a pull request. The biggest advantage to using something like GitHub (and git) is that you can have multiple people contributing to a project and the tools make it easy to merge all of these changes together. In addition, there is an extensive history of these changes. Another advantage is that each repository has a built-in wiki, which can be used to further collaborate on a project. Moreover, each repository comes with an issue tracker. This is one feature that I think is extremely useful for collaborating on articles. The issue tracker can be used to assign various tasks and provides a way to keep track of who has done what and when it was done. Each issue (i.e., task) also has the ability to add comments, so collaborators may have a targeted discussion about that specific task.

If you’ve ever coauthored a paper with multiple authors, then you’ve probably lost track of all the emails and files flying around. I think using GitHub goes a long way to address many of the complications. Of course, the price to pay for this is that the process may seem “technologically advanced” for most users.

It is worth mentioning that SciGit has the potential to replace GitHub for coauthoring papers. According to their webpage:

SciGit is a collaboration system for researchers to work on the same paper with version control easily.

The only problem is that SciGit is not yet available. I’m looking forward to SciGit’s release and I’ll definitely be giving it a try once it is released into the wild.

Update: SciGit is now available for beta! To sign up, you can go here. At this time, there is only a Windows version of the desktop client available. However, the developer has told me that a Mac version is in the works. I’m looking forward to checking this out. I’d also like to here from others about there experience.

Note: This post overlaps significantly with Mendeley’s blog post found here.

My current reference manager of choice is Mendeley, which is a free desktop and web solution designed for storing, annotating, and sharing research papers, discovering research data and collaborating online. It combines Mendeley Desktop, a PDF and reference management application (available for Mac, Linux, and Windows) with Mendeley Web, an online research paper management tool and social network for researchers. You can find a short YouTube video that describes what Mendeley is here.

For nearly all of my academic writing, I use LaTeX together with BibTeX. One of the many benefits of Mendeley is that it will automatically generate BibTeX files. However, at the time of writing this post (version 1.1.2 and earlier), integration with BibTeX is lacking in a few ways. In order for things to go smoothly, I suggest the following set up in Mendeley Desktop.

You want to uncheck the “Escape LaTeX special characters” box so that braces, backslashes, dollar signs, etc. don’t get clobbered by Mendeley when it generates the corresponding .bib files. You should choose “Create one BibTeX file per collection”. This generates one .bib file for each subcollection (folder or group) you create in Mendeley Desktop. If you don’t do this, Mendeley will create a duplicate entry in your synced .bib file for each entry appearing in a subcollection, which will in turn prevent LaTeX/BibTeX from compiling properly if you happen to cite one of the duplicate entries. I create a new subcollection for every document that I am writing that might require a bibliography.

Once you have got everything set up, it is really easy to incorporate Mendeley into your LaTeX writing workflow. If you want to cite a particular item, just click on it in Mendeley Desktop, hit “command/control-K” to copy the BibTeX citation key, then paste it into the appropriate location in your .tex file.

I’m currently writing a grant proposal and the narrative is supposed to be double-spaced. As with most of my writing, I’m using LaTeX. I’ve double-spaced a .tex document before, but I do it so infrequently that I needed to remind myself how do it. It seems the most common technique is to make use of the setspace package, which you can find here if you don’t already have it. Here are the steps necessary to double-space.

In the preamble of your document add the line usepackage{setspace}. In order to double-space your document, add the line doublespacing before begin{document}.

The setspace package also supports singlespacing, onehalfspacing, and even setstretch{1.5}, where you can change 1.5 to whatever you desire. In addition, you can make a block of text single-spaced in the middle of a double-spaced document by using begin{singlespace}stuff you want single-spacedend{singlespace}.