Pastebins are incredibly useful. But most of the public pastebins are not suitable for sharing within a company (think code fragments, log messages etc.) and most private pastebins are either ugly (except hastebin!), hard to setup/maintain and usually forced to be behind the firewall (for security).
A good software project must have a good build system. Unless you have a small code base consisting entirely of dynamic, scripted languages, you probably need to “build” your code before you can use it. Until around an year ago, the only build tool that I used and was familiar with was GNU Make. Make and the autotools family of tools have served the developer community well the past few decades.
But the Make model is rife with problems. Here are a few of them:
- Make requires the use of its own domain specific language — this is, in general, not a good idea. Have you looked at any sizable project’s Makefile lately? Its hard to understand, and harder to modify.
- In the same vein, autoconf/automake are notoriously hard to use. Bear in mind that these tools are supposed to make your life easier.
- Makefile are so hard to write and extend that several popular build systems today are essentially Makefile generators. A good example is CMake.
- Make relies heavily on file timestamps to detect changes.
- Make is slow.
- Makefile are not modular. Recursive Make is especially evil.
I recently began work on a new pet project. As is usually the case, I spent a lot more time figuring out what tools and libraries I would use for my project, than in actually writing any code for the project :) Part of the investigation was to survey the state of the art in build systems. At work, we started using SCons for most of our build, which was already a huge improvement over Make. But SCons has its own set of issues.
One of the nicest features in SCons is that build files are regular Python files. This provides enormous flexibility and immediate familiarity. Unfortunately, the SCons documentation leaves much to be desired. I still don’t quite understand the execution model of SCons very well. For instance, I know how to extend SCons to support cross-compilation for multiple platforms. However, I don’t really understand why those modifications work — there’s quite a bit of black magic that goes on behind the scenes. As a concrete example, there are several magic variables such _LIBDIRFLAGS that have strange powers.
After some more looking around, I discovered Waf. And now that I’ve played around with it a little bit, I’m happy to say that it is the most pleasant build system I’ve ever used. Things I really like about Waf:
- The execution model just makes sense to me. You typically build a project in phases: there’s a configure phase, to sort out dependencies, tools etc; there’s the actual build phase; and then there’s the install phase. It is not uncommon to have a ‘dist’ step as well, to prepare the source for distribution. Waf understands these operations as first class entities. There is a very strong notion of workflow built into Waf.
- Comprehensive documentation. Check out the Waf book and the wiki.
- Waf has a very strong task model. There is a much stronger notion of dependencies (powered by content hashes, not timestamps). Waf also enforces that all generated code lands up in a separate “build” directory, so your source tree always remains clean.
- Using waf is a breeze — there are no big dependencies, no packages to install, no bloated software to include with your code. Just a single 80kb script.
- Progress indication and colored output is built in, not an after thought. Like SCons, Waf build files are regular Python files.
- Waf is fast. Faster than SCons.
Of course, Waf is not perfect. Coming from a Make/SCons world, I sorely miss the ability to build specific targets. Yes there are ways to achieve this in Waf, but they are all clumsy. The API documentation (and the source itself) are a bit hard to parse.
Readers of this blog will know that I’m a big fan of GNU screen. While screen is a great tool, it hasn’t seen any major development or feature addition in quite some time. The code base is pretty old, there are some ancient bugs that still linger, and support for modern terminals (such as 256 colors by default) is not quite up to speed. I recently discovered byobu and was extremely happy with it — it completely overhauled my screen user experience. You can read all about byobu here.
tmux is intended to be a modern, BSD-licensed alternative to programs such as GNU screen. Major features include:
- A powerful, consistent, well-documented and easily scriptable command interface.
- A window may be split horizontally and vertically into panes.
- Panes can be freely moved and resized, or arranged into one of four preset layouts.
- Support for UTF-8 and 256-colour terminals.
- Copy and paste with multiple buffers.
- Interactive menus to select windows, sessions or clients.
- Change the current window by searching for text in the target.
- Terminal locking, manually or after a timeout.
- A clean, easily extended, BSD-licensed codebase, under active development.
And how is tmux better than screen? Thats question #1 in the FAQ:
tmux offers several advantages over screen:- a clearly-defined client-server model: windows are independent entities which may be attached simultaneously to multiple sessions and viewed from multiple clients (terminals), as well as moved freely between sessions within the same tmux server;- a consistent, well-documented command interface, with the same syntax whether used interactively, as a key binding, or from the shell;- easily scriptable from the shell;- multiple paste buffers;- choice of vi or emacs key layouts;- an option to limit the window size;- a more usable status line syntax, with the ability to display the first line of output of a specific command;- a cleaner, modern, easily extended, BSD-licensed codebase.There are still a few features screen includes that tmux omits:- builtin serial and telnet support; this is bloat and is unlikely to be added to tmux;- wider platform support, for example IRIX and HP-UX, and for odd terminals.
- I found the screen way of scrolling in a buffer and copying text much easier to use than tmux’s. Unless I’m missing something, the only way to scroll a buffer in tmux and copy some text is by using vi-like keyboard commands. While this is doable, it is not always quick or convenient.
- byobu made it really easy to add various status indicators. Wish I had something similar for tmux.
Almost three years ago (yes, I was quite surprised myself), I wrote about my requirements from a web based password manager. That post generated a lot of discussion, and we have come a long long way since then. I figured it was a good time to step back and present what I feel are some of the best solutions out there.
First, let us recap some basic requirements:
- Security: this is a no-brainer. If I’m going to trust my passwords to a software, it better be secure. In particular, the developer/owners of the software should not be able to look at my passwords.
- Online and offline access: I want access to my password regardless of whether or not I have internet connectivity. I should also be able to get to my passwords from any of my devices from anywhere in the world. This usually translates to a web-based system where passwords are stored at some server(s) in the “cloud”.
- Export: My password data is mine and mine alone, and I want to be able to export it out of the system (for personal backups, for instance).
- Desktop, Tools, API: I would prefer an open system, one that provides rich access interfaces. I’d love to have a desktop app, plugins for Do or QuickSilver etc. You get the idea.
- Simple to use: The password manager should not get in my way. Adding new passwords should be a breeze. Using stored passwords should be equally simple. Ideally, I shouldn’t even notice that I’m using a web-based password manager and not the stored passwords from my browser.
Without further ado, here are the top three web-based password managers.
If you are really paranoid about security, clipperz might be a good option. clipperz is open-source, so you can audit the code yourself should you so desire. It is also a measure of confidence from clipperz — by revealing their source code, they are basically saying, “Hey, we are clean, you can check us out yourself”. It also signals that clippers does not believe in security by obscurity. Apart from being open source, clipperz has all the other expected goodies: you can export your data, it supports one-click logins, you can download an offline copy etc.
I personally did not end up using clipperz because a variety of small problems: I did not like the interface; when I started using clipperz, the one-click login was barely functional; and overall I found the user experience of PassPack much better (read below).
PassPack is the first web-based password manager that I used seriously, and so far it has worked out great! The team is very responsive and constantly rolling out new features. I think PassPack did a really good job of promoting and educating the public on “host-proof hosting“, meaning that even the service provider does not have access to your data. This is something that most web-based password managers now support, but at least in my mind, PassPack really led the way in terms of awareness.
Some features that really drew me to PassPack: password tagging; I can mark certain passwords as “favorites” so they are loaded first; the two-level security; the desktop app based on Adobe AIR; the ability to store arbitrary notes (such as routing numbers or PINs). PassPack is particularly well-suited for groups. You can share passwords in a secure manner with people in your group. Recently they even added a feature to allow sending passwords securely via email. Now you no longer need to copy/paste your passwords into chats and emails.
What I always missed in PassPack was browser integration and seamless one-click login. With the PassPack bookmarklet, one-click login is almost seamless, but it never worked very well for me. For some websites it just won’t work. For others I’d have to re-login into my PassPack account. Yet other times there the bookmarklet would work in one browser but not in another. At the end of the day, it was just becoming cumbersome to manage multiple copies of my passwords — one in each of the browsers I used on each of my devices, and one in PassPack.
I recently discovered LastPass, and right now it is my favorite tool. I found it via its Chrome extension, which is when I realized that they have plugins for Firefox and work with pretty much all the good browsers on all the major platforms. I have to admit though, LastPass is nowhere close to PassPack in terms of the maturity of the UI and the overall user experience. But the killer feature for me was browser integration. With LastPass, adding new websites is exactly like Firefox asking you to store password information for a website. In fact, the FireFox plugin for LastPass allows you to disable and bypass the Firefox password manager altogether. When you come to a website that has already been stored in LastPass, it will fill out your username and password just like your browser would do. No need to click on a bookmarklet or any thing else. Transparent, seamless integration.
Unlike PassPack, LastPass has no group features at this point, which is perfectly fine by me. In the words of Tara Kelly, a co-founder of PassPack:
Passpack is pwd mngr with sharing & workgroups. Lastpass is login tool for individuals. Different strokes 4 different folks.
If there is a better web-based password manager out there that you know of, I’d love to hear about it.
As a grad student, I was always looking out for tools to make my life simple (read: I’m quite lazy). Here are some of the tools I think every savvy grad student must know.
A good plotting library
Don’t even mention gnuplot. Not only is it old school (how many times have you looked at a graph in a paper and just known that it was produced using gnuplot?), but it is extremely limited in its feature set. My biggest gripe with gnuplot, however, is that it forced me to separate my data collection/analysis from the actual plotting of the data. I personally am a huge fan of matplotlib — it is an uber-plotting library written in Python. It can produce high-quality graphics in dozens of formats (including interactive plotting), it has an object-oriented API as well as a imperative API along the lines of Matlab (hence the name). You can create amazingly rich plots and best of all, you can combine your data collection and analysis (which I was doing in Python anyways) with your plotting.
There are two aspects of bibliography management. First is the context of a specific paper: you are working on a paper and you want to collect all the relevant bibliographic information for citing in the paper. BibTex is the tool that is most commonly used for this, in combination with LaTeX. However, BibTex is buggy, the syntax is inconsistent across implementations, it lacks simple features like variables and the ability to “import” other bibtex files etc. Enter CrossTeX — a drop-in replacement for BibTex. CrossTeX is written in Python. It has an object-oriented model for representing citations. So once you define an object for author “Foo Bar” aliased as foobar, you can simply use foobar wherever you would like to cite “Foo Bar”. CrossTeX also makes it trivial to define new formatting styles for your citations. For instance, if you want to change the capitalization of the titles or abbreviate “Proceedings” to “Proc.” everywhere. Finally, CrossTeX was built by some nice folks at Cornell, so they know exactly what the pain points of BibTeX were.
The second aspect of bibliography management is simply keeping a track of all the papers you read and review. These will come in handy when you are writing a paper, a dissertation, preparing for a talk or an interview, or simply trying to recall prior work in a given field. I highly recommend using CiteULike — it is an online bibliography management portal. Some features I really like: CiteULike has a really nice bookmarklet that you adding new items to your bibliography using a single click from various sites such as ACM, USENIX, IEEE, PubMed, arXiv and so on; it has some really nice social features as well such as tagging, groups, watch lists etc.; you can download selected citations in multiple formats; you can search easily by keyword, tag, author, area, year etc.
A Text Editor
I don’t mean an IDE (like Eclipse) or a Word processor (like MS Word). I mean a text editor and only a text editor. AFAIC, that means Vim or Emacs (if that works for you). The bottom line is, learn a text editor and become really really good at it. You will be amazed at how much time will save you and how much can it impact your productivity. Some features that are essential: syntax highlighting, regular expression support, spell check, support for snippets etc.
On that note, learn to write in LaTeX. I’m horrified by the fact that so many people are still using Word like tools to write papers. I don’t have anything against Word, but it is the wrong tool for writing papers. Just reference management, formatting, including figures etc are so incredibly easier in LaTeX. And if you are struggling to find the code for the right symbol in LaTeX, you’ll love detexify (hat tip: Nate)!
I can’t stress this more — you must get in the habit of versioning everything. Not just code, but your notes, write-ups and obviously papers. Having some version control has saved me from disasters many a times. And if you are collaborating on papers, I can’t imagine how people do it without some kind of version control system. Now there are a lot of choices out there. But if you are really savvy, you must use git :) Basically use any reasonable distributed VCS (Mercurial and Bazaar are also ok), but avoid Subversion and absolutely refuse to use CVS at all costs. CVS has lived a good life, but its time is now past and we must let it go.
And by that, I mean staying on top of the news and research in your research area and/or academic community. I’ve found it very useful to add all the relevant blogs to a ‘research’ tag in my Google Reader (yes, the blogging bug has bit academia). Likewise, you can find a lot of current information on Twitter. I’m sure people have already started live-blogging and twittering from academic conferences as well!
Of course, for more conventional searches, DBLP and Google Scholar are invaluable. CiteSeer used to be the go-to website a few years ago, but I personally find Google Scholar much nicer to use and with just as much information, if not more.