Posted on by & filed under code editors, javascript, process, programming, python.

As part of the PubFactory squad coming over to Safari Books Online, I had some idea of the code that SBO engineers wrote but I really wanted to see “how they were living.”  What was it going to be like working in a Python/Django environment?  I set off to figure it out.  I cloned a pre-existing Safari Books Online repository and tried to run a project.  Concepts were very familiar, which was good, but I was surprised by something: there was not a trace of IDE configuration in the repo at all.  No hidden folders with project configuration, not even a mention of *.sublime-workspace in .gitignore.  The PubFactory team primarily uses Java so the IDE (mostly Eclipse and a little IntelliJ) is a big deal.

Slightly confused, I asked Liza what IDE her engineers use and she literally laughed at me: “IDE?? You mean editor?”  I didn’t mean editor, I meant IDE!  I had heard of a resurgence of engineers using lightweight editors from the 70’s (emacs, vi/vim) and apparently I now worked with a bunch of those people.  (Admittedly the word “hipster” did come to mind.)

I held this worldly bias until I had a Node app to build (more details in the upcoming days).  When I sat down to write some code I said to myself, “You don’t really want to write Node in Eclipse do you, who does that?”  I had Sublime Text 2 installed already so I gave it a go.  Turns out writing server-side code in something that is actually fast was really nice.  The soul-sucking 30 second Eclipse startup window just wasn’t there.

Soul-sucking screen

Soul-sucking screen

As a well-conditioned Java engineer I also started out relying heavily on Sublime’s code completion.  I was initially cross when it wasn’t great but there are Sublime plugins to make it better and it doesn’t take long to realize you don’t really need it either.  It was actually really nice to actually write the code as opposed to typing three letters, hitting ctrl+space and choosing your nugget of code from a list of options.

I went to a meetup a week after starting my Node app and heard about WebStorm — another hipster-friendly editor.  It was publicized at the meetup as having a “really nice debugger.”  In Java a working debugger is an absolute necessity, so I went to give WebStorm a shot.  My first impressions were that the editor was interesting (Live Edit feature is neat) and as publicized the debugger is nice. But then I thought, “Do you actually want to pick an editor based on its debugger?  You haven’t cared or needed it in the last ten hours.”  Another IDE feature melting away.

The natural conclusion to this story is I have now realized the error of my ways and dumped everything for the 70’s technology (MacVim).  I don’t think so.  MacVim is missing some things, or I haven’t figured them out yet. I still miss the ability to search through all code in your project without using grep.  I also haven’t quite gotten used to knowing where my code is yet (Eclipse makes that irrelevant with find a resource: cmd+shift+r).

I am currently in a halfway-house with Aptana Studio.  It’s an Eclipse variant — I know — that feels much faster than the full Eclipse install, especially Juno.  Aptana Studio has a built-in terminal so you don’t have to switch windows to see output, has useful git support, and lets me do all the Eclipse-y things I still care about.  Apparently this process will take a little bit longer with me.

 

[Ed. To be fair, some of our developers do use Eclipse, even for Python, but not the majority. — Liza]

Tags:

5 Responses to “Back to the Future”

  1. meirish

    If you’re looking to get started with MacVim, https://github.com/carlhuda/janus can be super helpful for those coming from a more mac editor (I came from TextMate) or an IDE. There’s a search plugin and a file-browsing plugin included in Janus. There’s also some handy videos for those new to 70’s tech :).

    • Scott Cipriano

      I just installed Janus. All kinds of stuff just appeared. The NERDTree and ack are exactly what I was just complaining about. Thanks for the recommendation @meirish.

  2. Keith Fahlgren

    Interesting to see what parts of a professional toolbox are easy to abandon and which are critical. Most of the vim users on the team started in cultures where IDEs were not even an option, so there’s much less steampunk hipsterism and more old world manual plane.

  3. Liza Daly

    For emacs (talk about 1970s…) I use the default bundled python-mode, and flymake (http://flymake.sourceforge.net/) bound to one of the epylint (http://emacswiki.org/emacs/PythonProgrammingInEmacs) instances attached to a particular project. I haven’t found a good way to switch between epylint instances based on the current project, since I use a different virtualenv for each project and usually have multiple ones going at once. I generally just point to an epylint associated with the largest possible project (with the most imports) and that’s usually good enough.

    Unfortunately pylint and Django don’t play that well together so there are a fair number of false positive errors, but I’ve gotten used to ignoring the errors around models and just attending to ones that come up for other code. It’s not ideal, but still better than no pylint at all.

  4. Brian Glass

    I am a die hard vim/vi user (20+ years). I like my development environment to be light and fast without a lot of bells and whistles. That said, I found a few vim add ons to be very useful. The PyFlakes vim plugin highlights errors in your python as you type. SnipMate provides some convenient keyboard shortcuts for often used bits of code in a way similar to Textmate’s snippets (or so they say). I occasionally use Ropevim for code completion, but generally prefer to draw it directly from my brain.

    I came really close to liking PyCharm once. It’s really excellent as far as IDEs go, but I’m an old dog.