My So Called Digital Life

In this post I have collected a few things which some people might find useful. They are essentially all of the  computer tools and resources I use at work.

  • Zotero is a great document/pdf/paper storage tool. It auto uploads from mathscinet and many journal web pages. It also scraps the info from modern PDF files. It syncs across all of my machines and works offline. Lastly, it outputs bibtex entries though I use this less.
  • owncloud is how I sync my basic files across my computers. It is hosted at Duke math so there are no privacy issues. It is like our own personal dropbox.
  • Git is a version control software. I use it for collaborating on papers and computer code. We host a simple web interface to maintain ones git repositories called Gitlab.
  • LibX is a plugin for searching the Duke libraries.
  • To maintain mailing lists I use the sympa server run by duke. This way people add/remove themselves.
  • Duke runs its own wordpress server. That is how this site is hosted as well as my collection of probability problems which I give as homework. It contains both undergraduate and graduate level problems. Anyone can ask for a site (with the name of your choosing – assuming it is available).
  • Here are the three LaTex letterhead style files I use at Duke.

 

That is basically it these days.

LaTex Letterheads for Duke Math

There are two different letterhead style files I use to write official letters in Latex.  The first is a black and while version written long ago. This version should be on most of the math department computers. The second is a color version written by Ezra Miller. I use the second one. I also now have a digital version of my signature which I keep in a file called “sig.pdf”. See the exampleEzra.tex file included in the version written by Ezra. The third is an old school gothic letterhead. My understanding is that Ezra uses this one.

 

  • Black and White historic Letterhead. Use “pdflatex example.tex” to generate the example file.
  • Color letterhead by Ezra Miller.   Use “pdflatex exampleEzra.tex” to generate the example file. Edit file to uncomment lines  around “sig.pdf” at the end to include a signature. Of course you have to make your own sig.pdf. (For obvious reasons you cant use ours.)
  • Gothic leaterhead by Ezra Miller.
  • Some Interesting logos used By Ingrid.

 

 

Zotero : a tool for managing and building your preprint library

Zotero is a cross platform (Linux and OS X in my case) too for building, storing and syncing a large library of preprints. It runs as a Firefox add on but can be run in a stand alone mode and has a plugin letting it work with Chrome and Safari.

It is open source. It  is funded by the Sloan and Mellon foundations and developed the Roy Rosenzweig Center for History and New Media at George Mason University. It is now in version 4 and is quite stable. I have been using it for years.

It interfaces seamlessly with mathscinet, the Arxiv and most journal pages. It can export bibliographic information in bibtex. It synchronizes  its library across all of my computers. One does not need internet access to use it. Each of my machines has a local copy of my 2000 plus paper library. It also has the ability to create shared folder which I have used off and one to share papers with students and collaborators.

Do learn every thing about Zotero you should visit the Quick Start guide.  Here, I will mainly emphasize the information you need to set things up locally to work in the Duke mathematics department. 

Here is a screen shot of my the main zotero screen in firefoxMain Zotero screen

Syncs its basic data by using the zotero servers. This is a free service and you will have to sign-on  and register. While this service is free and allows you to save the biographic information of an unlimited number of papers, the same is not true of the actually PDFs. Without paying  modest fee, there is a limit to the total size which can be synced with the zotero servers.

Fear not !

The mathematics department runs a webdev and zotero can be configured to use our local webdev. This will give you an unlimited amount of space for PDF files.

First create directory in you linux account on a department machine and create an directory to be used to store you library. You will never interact with this directory. It will just be a repository used to keep and sync files. Mine is called zotero in my main directory. To create such a directory type:

% mkdir ~/zotero

Then you need to configure zotero to use this directory.  Here is a picture of my sync settings which can be found under the zotero preferences from the drop down menu in the main zotero window.

sync settings

 

Notice that I have set the “sync attachments” to webdev and entered the info for the department server. This login info is my department username (“jonm”)and password. At the top of the page is where one enters my zotero username (“jonmjonm”).

 

It is also useful to add the bibtex style. This is done on the “style” section of the   “cite” window pane of the zotero preference window. Here is a picture of mine.

adding bibtex

you need to click on get additional styles.

It is also important to install the needed PDF indexing utilities. This is done from the “search” window pane in the zotero preference window. You want to make sure you have the up to date versions of pdftotext and pdfinfo installed in a place zotero can find them. This is done by pressing the button on this pane. See the image below.

Screen Shot 2014-07-31 at 8.37.08 AM

This covers the basics. I have done this on each of my machines. Whenever I open zotero up and have an internet connection it will synchronize my libraries. I can of course  use it perfectly well with no internet connection. I do this regularly when on a plane.

I also have added the plugin Zotfile to make zotero more flexable and use Zotpad on my iPad. However, these are topics for a later post.

Using Git to write papers

I have been using version control to write my papers for a long time now. I started off using CVS then moved to SVN and now have switched to Git. Though SVN was a little simpler at time, I am happy with my move to  Git.

The basic idea is that there is a server in mathematics holds copies of my papers and all of the changes I have made and committed to the repository. When I go to any of my computers, I just tell it to update to the latest version of the paper. I then can edit it local committing changes as I go. These commit points serve as milestone to which I can return too at any point. Say I think I have a cleaver proof which will simplify my main argument. I start changing the paper only to realize after an afternoon of editing that there is an unintended consequence and I which I had not made all of the changes I did. With a simple command line, I can return to the state the paper was in earlier in the morning. Gone are the endless number of “numbered” versions sitting in the directory. I no longer return 6 months latter trying to recall which was the version I submitted.

While his “versioning” is nice, the real advantage for me is that when I have co-authors everyone can edit the paper at the same time. In the beginning, we should each work on different parts of the paper. Git will merge the sections together effortlessly. Once the paper is mature and we are making smaller edits, we can both roam over the whole paper. On the odd chance that we edit the exact same section, Git will alert me to this and give me a chance to merge the two edits by hand.

As an added benefit, all of my papers are back up with extreme redundancy because of git and I never worry about loosing them. Since I update the directory before I start working, git is also a way to synchronize all of my computers.

I use git even with people who don’t. Some of my collaborators don’t like change or “complicated new ideas” as one put it. Git lets me maintain different branches. I create one for each co-author. I send them the version form there branch and tell them to edit the text. I continue editing my branch (without telling them). When they send me back a version, I switch to their branch and commit the version they sent. Then I merge their branch into mine, thus combining our edits.

How do I use it. The mathematics department runs Gitlab to manage Git repositories. It is a nice easy system for adding users to a project and changing who can edit/see a given paper. I have written a number of pages about how I use git in general, how to set up new repositories, and how git is used for the Math Everywhere class in particular.

I mainly use the command line to manipulate git. However I also sometimes use the free software package called Sourcetree. It is particularly nice to track changes. When I want to find an old version before I mad certain chances, this is how I do it.

Update (June 23, 2017): I now use GitKraken as my GUI instead of Sourcetree. I find it more powerful and intuitive. I can also run it on Linux and install it myself without root permission.

A List of Lists (& Articles) about Durham

Owncloud and Duke Math

For some time now, I have been using owncloud to sync my personal files. It is a lot like a personal dropbox.

Why do I use owncloud ? It is a great way to seamlessly synchronize file across machines. In this respect, it works a lot like dropbox. It has a client which works with linux, os X (mac) and windows. Initially is seems one can sync 50 GB, though I suspect this is a limit is by Andrew. All of the info stays on Duke servers so there are no privacy issues.

I have not explored the file sharing possibilities much. They exist, but seem not as advanced as dropbox. For two people in the department, they work a lot like Dropbox. There is a shared directory which both people can interact seamlessly. If one person is not in the department,  the sharing options are mainly web based. You can share files or directories secured by a password to anyone with a web accessible link. You can’t seem to seamlessly share a directory with someone else outside the department as one can do in dropbox.  For collaborations such as writing papers of code I personally use Git. It has much better version control than Dropbox or owncloud and it is  free (again hosted in the Duke Mathematics department).

There is a web interface at https://cloud.math.duke.edu/owncloud/ . From there one can create links to share a file with someone or retrieve a file when you only have web browser access.

There is also an ipad/iphone client which costs a few dollars. I use it regularly to save file from my phone to my work account. There is also a webdev address

https://cloud.math.duke.edu/owncloud/remote.php/webdav/

 which is useful for some other ipad/iphone clients.

To get started, type

% owncloud

at a linux command prompt on a department machine. It should step you through the needed steps. It will create a directory called “owncloud” in your home directory.  Any file in this part of your directory tree will be synchronized.

Gitlab at Duke Math

I am now using gitlab to manage my git accounts. I used to use gitolite. I liked it very much, but the department wanted others to use git and gitlab is better to allow the entire department  access.

To use gitlab you have to set up our account.  Follow the steps below to set up your account.

  1. you should have gotten an email  from gitlab. If you lost it, you can just follow this link and say that you forgot your password. It will put you through the steps to get a new one mailed to you.
  2. Once loged it go to this page to up load your ssh key. The ssh key is on the driectory ~/.ssh and is usually in a file called
     ~/.ssh/id_rsa.pub
  3.  You are now ready to use gitlab. See this page for a description of using it for math everywhere. And look at this page for a description of commands one typically uses.

Using Git – typical commands

Committing changes locally

After  you have made some changes  to your local copy you might want to commit them so that they are saved and you can “revert” back to the current state should you ever want to. Each “commit” amounts to a snap shot of the directories which  is saved for all time. You can always revert to the current state.

% git commit -a -m "some note saying what you did"

The “-a” tells to commit all changed files. This is my usual practice. The “-m” adds a memo describing what you changed. If you leave off the “-m” and the comment which follows the system will open an editor (if your system is set up correctly) and you can edit the comments in the editor.

Pushing your changes to the master repository

Once you have committed your changes locally, you have to “push” them to the main repository. This is done with

% git push

If there is an error it is most likely because changes have been made to the main repository since you last updated. You need to perform a “pull” to update your local copy of the repository. You will then often be required to commit again to add the effects of “merging” your local repository   with the main one. Hence a typical “workflow” for committing onese changes is :

% git pull
% git commit -a -m "merges"
% git push

Updating the local repository

This is done by pulling the changes.  Before you can pull you have to commit any changes you have made locally. So although to pull one only needs to say

% git pull

Operationally one usually runs:

% git commit -a -m "my changes"
% git pull

 

Adding a file to the repository

git only tracts the files you tell it to. To add a new file called “new-file.tex” to version control tracking you would type

% git add  new-file.tex
% git commit -a -m "added the file new-file"

Removing a file from the repository

To remove a file, one types

% git rm  new-file.tex
% git commit -a -m "removed the file new-file"

Of course the file will still be in previous versions and can be recovered at any moment. It will just no longer be in the current version.

Renaming or moving a file in the repository

Renaming is the same as moving.

% git mv  new-file.tex different-name.tex
% git commit -a -m "changed name of new-file"