Alternatively, you can grab the Bolt Bus, or others like it (https://www.boltbus.com/default.aspx). Cheaper and slower than Amtrak but apparently has decently usable wifi.
Actually I would say that some/most interviewers believe that this is the purpose, and like to use the interview as a chance to show how smart they think they are
(at least the stereotypical "interview" at the stereotypical tech company. Then again, I think Wall Street/financial firms probably do the same. exact. thing.)
Am I the only one that read this and was left wondering what the heck was up with the interviewer, not the candidate?
Why drill a candidate for a technical writer position on hash functions and memory needs and speed and all that?
It seems to me like whichever company this was (I'm guessing Google) that the interviewer only knows how to ask one type of question, almost as if he/she was reading from a script.
I think if you find that refactoring is "barely essential" then you are really missing out. I must use it's features about 20 times a day - from simple ones like "Rename" (seriously how would you do that easily in emacs, when the class is used in 15 places?), Extract Local Variable, Extract Method, etc.
I don't do multi-file changes in emacs, but they are pretty trivial with "perl -pi -e ...". You have a lot more flexibility with this method. I often create a new branch, spend a few commits getting the rename right, and then squash the commits and apply it to my real branch. (Sometimes I apply the changes to the index instead of applying it as a commit -- this way I can change other things in the same commit.)
Anyway, the automated tools sort of fake this workflow, but sometimes the real thing is nicer.
I've always had this nagging suspicion that I could become more productive, if only I truly learned how to use emacs. But this post has just finally convinced me that the only people who cling to emacs for large scale development are true believers who will never be swayed.
The automated tools don't fake your workflow. A refactoring tool performs code modifications that it can prove make no change to the semantics of the code. You can sort of fake this, in a painful way using perl, but as you've just stated, your system is so unreliable that you create a branch to do something I may do a dozen times in an hour when I have some time to go back and clean up.
But this post has just finally convinced me that the only people who cling to emacs for large scale development are true believers who will never be swayed.
Yes, judge thousands of people by one person. That has served society very well over the years.
Anyway, in Eclipse, every non-trivial rename "requires preivew" and often requires cleanup. If you just want to change the name of a class, the GUI is fine. If you want to do something more involved, you end up doing it manually anyway.
For trivial renames in Emacs, I have a function called "rename-this" which is mode-sensitive and Does The Right Thing for languages I actually use (Perl, Haskell, and Lisp). (Most things are non-trivial, though, as dependencies on a class name are not always in the form of the class name in the source code. "${prefix}::Foo" is hard to detect, but occasionally appears. Refactoring works well in Java because there is no possibility for syntactic abstraction, and it must be a function of your text editor. That approach is why I avoid Java.)
Edit: BTW, if you get to make a snide comment, so do I:
"Your post has finally convinced me that the only people who cling to IDEs for large-scale development are true believers who are more comfortable clicking buttons than writing software." Tool building is an important skill that IDEs actively discourage.
Yes. Eclipse can be flexible with where the source folders are, where your libraries are coming from, etc. You'll (usually) only have two metadata files: a .classpath and a .project, and occasionally, a .settings folder (for any per-project settings you might change such as compiler warnings, etc.)
Otherwise, you can leave your structure intact and unchanged.
How do I export the project back out to its original form once I imported it into the workspace? Or is it safe to just copy the stuff out of my workspace folder?
First of all: you are using version control, right? Please tell me yes.
Eclipse isn't going to "change" your code at all. It'll put two or three files and dirs in the root of your project. That's it. Your code is the same as it was before.
If you move a class to another package in Eclipse (using drag&drop), it will automatically issue the necessary svn move command, and synch up the import statements everywhere. That's a 20 minute job done in 2 seconds.
Eclipse won't change your file/folder structure (unless you tell it to).
In fact, you can have source code somewhere outside of your "workspace" and just point Eclipse to it, there is no requirement for the code to be inside the "workspace".
Never, to judge from the introductory copy on the TextMate web site. Which I think is a pity, since the editor has some real strengths (although nothing that isn't more or less already available in Vim or Emacs, near as I can tell, if slightly less flashy).
I've played with TextMate a bit, but simply can't commit to learning an editor confined to a single operating system. That way lies Madness, or slower editing everywhere at the very least ;-)
