Category: Tool

About three weeks ago, Jodi and I hosted an old friend and colleague. While his primary purpose was to come to SMU to deliver a seminar on his recent work in neutrino physics, he accidentally got me thinking (again) about improving my electronic logbook experience. I’ve spoken before about different ways you can choose to implement your electronic logbook. Here, I focus entirely on TiddlyWiki (http://tiddlwiki.com) and an implementation of LATEX, the mathematical typesetting language.

Such an implementation exists, in general, for JavaScript – this makes it portable to any major modern browser platform. As a review, LATEX [1]  is a type-setting language; like a printing press, it correctly places and kerns fonts and allows you to quickly and beautifully format mathematical equations.LATEX is available for every major computing platform. jsMath [2] is a JavaScript implementation of the parsers in LATEX and renders mathematics in native fonts. This is dissimilar from other implementations of LATEX on the web, where instead of fonts, GIF images are created for the equation. For a big document, this means loading dozens, or hundreds, or images. jsMath avoids this completely.

The missing piece: a plugin for TiddlyWiki, so that you can use jsMath in your electronic logbook. That plugin is achieved via the Tiddler “Plugin: jsMath” by Bob McElrath [3]. Here is my own personal recipe for installing jsMath and the Tiddler plugin.

1. As of the writing of this entry, I am using TiddlyWiki 2.5.3 and jsMath 3.6c (the latest public release versions of each). I downloaded them from the sites linked in this post.
2. I began by installing jsMath in the same directory where my top-level logbook .html file is located. I unpacked the jsMath ZIP archive, which automatically creates a jsMath subdirectory. The top-level logbook .html will look for jsMath in this way when the plugin is installed.
3. I installed the TrueType Fonts recommended by the jsMath site (see http://www.math.union.edu/~dpvc/jsMath/download/jsMath-fonts.html). For me, they had to be unpacked into the .fonts/ subdirectory in my home directory. Your needs may vary. Basically, your browser has to have access to these fonts.
4. I then added a new Tiddler to my logbook. I titled it “Plugin: jsMath”, and into it I copied the code on Bob’s webpage. I added the tag “systemConfig” to the tiddler, so that it is executed and loaded as a plugin to the logbook.
5. Installation complete! I then added LATEX code into my journal tiddlers (e.g. $\gamma \to e^+ e^-$) and it rendered beautifully

A few words of caution, before you get ahead of yourself. Please read the jsMath website information on defining new symbols. It’s not as straight-forward as experienced LATEX users would like it to be, but once you learn the syntax it gets to be a cut-and-paste operation. Second, if you’re using a remote server to host your wiki you are on your own; I don’t know what expectations the code will have for the location of the jsMath code (on the server, on your local machine, or both?). I know that the current implementation of the plugin does some text parsing and looks in the current directory for jsMath – you may have to edit this to make it work when your wiki is on a remote server.

So far, this has been a positive experience. I can still use unicode/HTML short-cuts for things, as needed (e.g. γ → e^^+^^ e^^-^^, which gives you almost the same result as the example LATEX above). But, now for complex equations I have the power of LATEX at my fingertips. I’m even thinking of doing lecture notes for classes in this way, so that they can be instantly placed on the web.

[1] http://www.latex-project.org/

[2] http://www.math.union.edu/~dpvc/jsMath/

[3] http://bob.mcelrath.org/tiddlyjsmath-2.0.3.html

It’s been a number of years since I had to think – I mean really think – about electronic communication and HEP. On BaBar, I became accustomed to a specific model of communication. E-mail for personal correspondence, for which no record inside the collaboration is necessary (e.g. arranging a meeting time); Hypernews for conversations whose archival value is, at least, non-zero (e.g. the time of the meeting); phone for connecting people together in a meeting (via MeetingPlace); the web for locating presentations either in a central database or a site (PDF preferred, please!).

ATLAS has adopted EVO [1], which was developed jointly by Caltech and the DOE and leverages technology built by the VRVS collaboration. Years ago, a colleague of mine introduced me to VRVS. It barely worked on my linux machine, and I quickly abandoned it. That was sad, because it was built on JAVA and it really should have worked well. I wanted it to work.

VRVS has come a very long way, if EVO is any indication. That said, EVO seems to be the butt-end of many jokes inside ATLAS and certainly it seems to inadvertently induce delays in meetings, due to troubleshooting. The very first day I attended the LBL ATLAS jamboree, I decided to fire up EVO and see what the meeting looked like to people on the other end of the connection. I quickly realized that the tools in EVO allow a participant to exercise a great deal of flexibility in participating in a meeting.

EVO adds extra dimensions to my old collaboration model. Video and audio are totally integrated into the client (Koala), so I can choose to send video or not. Chat is also built into the client, distributed to all the participants in the meeting or directable at only a single participant. Today, for instance, during the Hadronic final states workshop at SLAC there were some problem moments in the meeting when firing off a short chat to the speaker, letting them know there were audio problems, was EXTREMELY valuable. That, and when audio would drop out a few chats fired around to participants in the meeting could help isolate the problem.

I’ve decided that EVO augments my old model in a very positive way, even though it brings inevitable technological challenges. The challenges I’ve experienced so far stem mainly from the marriage of the phone system (literally, a phone handset that someone uses to dial into the meeting) and the EVO internet-based system. The “phone bridge”, as it’s called, seems to introduce the most problems. Feedback, dropped connections, etc. seem to stem largely from the phone bridge.

Based on the last 5 days of ATLAS-related meetings, I’ve come up with a set of personal “best-practices” that I intend to implement when running, or even participating in, ATLAS meetings.

1. It’s important that the moderator (me, let’s say) focus on maintaining the connection at all times, and sending a “pause” signal out to people via chat when things go badly. It’s therefore also incumbent on the speaker to keep an eye on the chat window for emergency messages.
2. Having a “shadow” in the audience, someone who is physically at the meeting site but dialed into EVO via video and audio (in fact, even listening to the audio while in the same room as the meeting is a good idea). This person is like the audio engineer, listening to the performance and alerting the moderator of problems. I did this today as an experiment, and I found that if I brought the volume on my headset up to a high enough level (not too high) I could mentally ignore the audio in the room and focus on the audio coming across EVO, even though I was in the same room. It was then immediately clear when the speaker dropped out from the connection, important if they were physically in the room and thus oblivious to the fact that no one on EVO could hear them.
3. Try to avoid the phone bridge, but if you must use it watch it like a hawk. The Shadow will be of great value in monitoring such a thing.
4. Wireless internet seems to work fine, but I’m a big fan of hard-lines since the TCP/IP protocols are more standardized and well defined there (there is also no encryption overhead at the network device level). I’ve heard rumors that hard-line connections to EVO are more reliable than wifi connections, and a priori I can see why this might be, but my own experience says it’s fine. That said, I fundamentally trust hard-lines more than wifi.

I plan to keep these in mind while moving forward. I’m particularly keen on the moderator/shadow model. Communication in such a large body as ATLAS is hyper-critical to the mission of the experiment. Minimizing delays is also key to maximizing meeting time, and thus getting out of meetings and getting to work. My collaborators seems to succeed in spite of the frustration they seem to feel about EVO. Me? I like it, even if it does have idiosyncrasies. I like that chat, video, audio, and identity in the meeting are all tied into one service.

With that in mind, I intend to keep EVO up during the day as a means to facilitate cooperation between my colleagues and myself. If you’re on EVO, let me know and I’ll add you to my buddy list on chat. I like that I can keep G-chat and AIM for personal use, and keep EVO for the physics side of my life.

[1] http://evo.caltech.edu/

I’ve experimented over many years with electronic logbooks. I got tired of literally cutting and pasting print-outs of plots into paper logbooks, swollen  by glue and pictures, back in 2001. Since then, I’ve experimented with a number of different electronic logbook technologies. It’s important to me that they can be backed up, and that data is easily retrieved from them. I here report what I’ve used, what I’ve liked, and what I’ve not liked.

ELOG: (https://midas.psi.ch/elog/) This is the Swiss Army knife of open-source, free logbooks. It can run locally, or on a server at home or work. It can be used for personal logs, or for collaboration. I’ve used it both ways. When I was at MIT, I used it to organize analysis between collaborators at MIT and SLAC. It can send e-mails when there are new entries, or updates to old ones. It allows HTML or plain text entries, embedded graphics or attached graphics. One of the coolest features, I think, is that it will take an attached multi-page PDF file and render the pages as individual graphics in the logbook entry. This lets you read a PDF file without opening it. I recommend this to people who need to collaborate, and for personal use for people who like a beefy logbook.

Xournal: (http://xournal.sourceforge.net/) Also open-source and free, this is good for the tablet PC crowd. You can handwrite entries, load graphics as backgrounds and mark them up (great for editing PDF files!). It combined old-school hand-writing with new-school electronic record-keeping. I’ve even considered writing slides in this, getting back to the old overhead projector days of giving seminars or talks. What’s held me back from doing so is that you can’t place graphics arbitrarily on a page. That prevents me from using it for talks, and from using it as a serious logbook.  A big drawback is the access to data in text form in the document – hand-written logbooks can’t just be cut-and-pasted into e-mails, or the web. But it has lots of potential, and is definitely worth watching.

Tiddlywiki: (http://www.tiddlywiki.com/) For the wiki, stream-of-consciousness crowd, this is the way to go. I’ve actually switched from ELOG to Tiddlywiki for my logbook very recently, thanks to a rediscovery of this prompted by a student. It supports the creations of “tiddlers”, units of self-contained information that can be linked to, or can link to, other tiddlers. It also supports “journal entries”, which are tiddlers whose name (and thus hyperlink) are based on the current calendar date, with one entry per day. You can embed graphics, store the whole thing in CVS and sync it (or use rsync to back it up), and best of all you can edit it straight through the web browser. Since I use Zotero for storing papers, and a lot of physics information is stored on the web, it’s great to have an all-in-one place to do my note-taking. Tiddlywiki, and variants on it, have become my go-to way of rapidly developing documentation or a logbook.

Hope this opens some doors for you!