Thursday, July 24, 2008
Switched over to OpenDNS
DNS lookups from my home network have been getting really slow lately, thanks to my ISP (BSNL). Switched over to the OpenDNS servers this morning and experienced an immediate increase in browsing speeds. Firefox no longer just waits at "Looking up ....".
Sunday, July 13, 2008
Using GEdit as a Rails IDE
The thing I look for the most in an IDE is speed. Over the past few months, been trying out different options for Rails development. Eclipse + RadRails looked promising, but turned out to be quite slow. Then, shifted to using NetBeans 6.1, which turned out to be better than RadRails, but not as fast as I needed it to be. My search finally led me to customizing GEdit (yes, believe me) and so far been quite happy using it. It blazing fast (except the SnapOpen plugin), and the plugins are pretty cool too. The integration with Rails itself is nothing great, but who needs that when you can cook up a bunch of shell scripts.
Linux Tip: Give gedit the Power of TextMate
Pimp my Gedit (Was: Textmate for Linux) | Grigio
Thaumatocracy » Post Topic » Textmate for Linux
Gedit/ToolLauncherPlugin - GNOME Live!
Linux Tip: Give gedit the Power of TextMate
Pimp my Gedit (Was: Textmate for Linux) | Grigio
Thaumatocracy » Post Topic » Textmate for Linux
Gedit/ToolLauncherPlugin - GNOME Live!
Saturday, June 28, 2008
How do they make money?
Every time I see a new Web 2.0 site, one of the first things that comes to my mind is "how do these guys make money?". Take TinyURL, for example. Or Twitter. Looks like many of these services follow the principle of "get big first, worry about business models later", or rely mostly on advertising revenue. Some related links:
Wednesday, June 18, 2008
pypeek - peeking at a particular line in a log file
Announcing pypeek, a pretty straightforward Python script to print out a given line in a log file, with lines of context. While it works fine standalone, it's meant to be used in conjunction with grep. When I search for something interesting in a log file, I usually also want to see lines around the matching line, e.g. when I grep for NullPointerException, I also want to see the nearby lines to understand the problem better.
P.S.: Don't try it with very huge log files just yet. It's painfully slow. Planning to work on a memory mapped I/O version later.
Usage: peek filename line_number [no. of context lines]
grep MyException -n big-file.log | cut -d":" -f1 | xargs -n1 peek big-file.log
P.S.: Don't try it with very huge log files just yet. It's painfully slow. Planning to work on a memory mapped I/O version later.
Saturday, June 7, 2008
My top #3 interviewing tips
Over the course of my career, I've attended quite a few job interviews, and also conducted a huge number of interviews at my last job while we were building out the team for our unit at Hyderabad. Based on my experiences, here are the top three tips for interviewing candidates:
#1 : Respect the candidate
Just because you are taking an interview doesn't mean you have the "upper hand", and can take liberties with how you interact. An arrogant interviewer creates a very poor and lasting impression about the entire company. Remember that the candidates are going to carry that impression for the rest of their careers. Even if they qualify, the best candidates are unlikely to join if they perceive that the work culture at the company is not good.
#2: Test the candidate in his/her area of expertise, not yours
No matter how much kung-fu you know, chances are that the candidate knows more kung-fu in his or her own area of expertise. Good interviewers try to discover the strengths of the candidate and check if that matches with what the job needs. Insecure interviewers are more likely to keep the questions to their own area of expertise and get into technical arguments about who is right.
To illustrate, here is how the interaction went at one of the interviews I attended about 3 years back with one of the largest IT consulting companies in the world:
Interviewer: How good are you at JSP?
Me: Never worked on it, but I have worked on several other Java technologies
Interviewer: How do you rate yourselves on a scale of 1 to 10 in JSP?
Me: Huh, maybe 0 or 1. I _haven't_ worked on JSP at all, you know.
Interview: So I'm going to ask you a few questions on JSP now
Me: Hello? Why don't you ask me about some of the other technologies that I _have_ worked on?
Interviewer: Well, I don't have any knowledge about those technologies, so we'll stick to JSP
Stupid, isn't it? I was then interviewed by several other folks, and was selected. Needless to say, I didn't join.
#3: Keep the interview/selection process short
Any interview/selection process lasting more than a few hours is suspect. Sure, it can take much longer to actually compare different candidates and decide which ones to make an offer to, but all that can and should be done after the candidate has left. If you can't decide within a couple of technical interviews if the candidate is good enough, chances are that your selection process is faulty or that the interview panel is not good enough.
After telling a candidate your company believes in quick work and fast decision making, having him/her attend 5 technical and 3 HR rounds spread over 2 days is just not on.
#1 : Respect the candidate
Just because you are taking an interview doesn't mean you have the "upper hand", and can take liberties with how you interact. An arrogant interviewer creates a very poor and lasting impression about the entire company. Remember that the candidates are going to carry that impression for the rest of their careers. Even if they qualify, the best candidates are unlikely to join if they perceive that the work culture at the company is not good.
#2: Test the candidate in his/her area of expertise, not yours
No matter how much kung-fu you know, chances are that the candidate knows more kung-fu in his or her own area of expertise. Good interviewers try to discover the strengths of the candidate and check if that matches with what the job needs. Insecure interviewers are more likely to keep the questions to their own area of expertise and get into technical arguments about who is right.
To illustrate, here is how the interaction went at one of the interviews I attended about 3 years back with one of the largest IT consulting companies in the world:
Interviewer: How good are you at JSP?
Me: Never worked on it, but I have worked on several other Java technologies
Interviewer: How do you rate yourselves on a scale of 1 to 10 in JSP?
Me: Huh, maybe 0 or 1. I _haven't_ worked on JSP at all, you know.
Interview: So I'm going to ask you a few questions on JSP now
Me: Hello? Why don't you ask me about some of the other technologies that I _have_ worked on?
Interviewer: Well, I don't have any knowledge about those technologies, so we'll stick to JSP
Stupid, isn't it? I was then interviewed by several other folks, and was selected. Needless to say, I didn't join.
#3: Keep the interview/selection process short
Any interview/selection process lasting more than a few hours is suspect. Sure, it can take much longer to actually compare different candidates and decide which ones to make an offer to, but all that can and should be done after the candidate has left. If you can't decide within a couple of technical interviews if the candidate is good enough, chances are that your selection process is faulty or that the interview panel is not good enough.
After telling a candidate your company believes in quick work and fast decision making, having him/her attend 5 technical and 3 HR rounds spread over 2 days is just not on.
Thursday, June 5, 2008
Twitter status
After some very public scalability problems, Twitter finally decides that it's best to keep the customer informed. Wonder how they are serving the status feed/blog, but I bet they're not using the Twitter service itself. The last thing they need is for the status service to go down ;-)
Ah, it's there right on the page - they are using Tumblr.
Ah, it's there right on the page - they are using Tumblr.
Subscribe to:
Posts (Atom)
