Amen - I forget the interview, but there was a great interview with Steve Jobs where he said that to make great things happen, you need a broad range of life experience. That tends not to apply to engineers who stay in front of the computer all day.
Because a phishing page is basically just a mirror. No successful phishing can really occur unless you provide the page with information, though, so as long as you don't fill in any forms or download any weird applets you should be okay.
(The linked URL was, when I checked, a legitimate and non-malicious mirror of the original.)
EDIT: Obviously a phishing page is not a proper mirror - but they both share the attribute of being very similar to another page, and with "name.tld" as a sub-domain it makes sense that a browser might incorrectly label a mirror as a phishing page.
zsh is a little snappier than bash and offers some neat options which are not present in bash (at least not out of the box AFAIK - e.g. spellcheck).
From my experience, zsh targets power users (and people who really don't like to type). For most people sticking with bash is probably leaving well enough alone.
From my POV it's not a religious issue, though in just a short while of using zsh I find it more productive than bash.
I'm lucky in that I have a somewhat more open relationship with HN; HN allows me to view other sites, and in return I let HN have more users than just me
I scan the RSS feed, ignore the dupes from HN, reject the political stuff, and glance over the remaining tech headlines.
Of the three that might appeal to me, I read the abstracts, and occasionally follow the links to the original articles. I ignore the comments because I never log in anymore. The only ad I might see is in the upper right.
The new design seems to confirm that I'm not alone.
> It is likely Slashdot will still be here when HN is gone.
My gut feeling says no. I used to read Slashdot as much as I now read HN or Reddit. I hardly ever go there any more, and when I do it just doesn't seem interesting.
Well, the actual article says, "his favorite tools for debugging ruby and rails applications". It's less about debugging Ruby than about debugging servers gone awry, with an emphasis on those implemented in Ruby.
Very true. In my experience, many ruby and rails developers aren't familiar with these tools and these intro tools are the groundwork for using some of the more ruby specific ones.
