HN user

lukatmyshu

12 karma
Posts1
Comments28
View on HN

We had a bunch of IPs for each of our servers to get around some of their auto-blocking stuff. Eventually we got approval from AIM but that was fairly late. You're right in that we had crazy-impressive web UI but the backend was also unique in that we had a process running for every logged in user (and eventually we had a process running for every user who was running the iOS app)

Del.icio.us 6 years ago

Are you me? I had the exact two same issues when I was at Yahoo (2005-2007) basically due to Jerry & Filo. Somehow happy to know that I wasn't the only one :)

Entropy Crushers 13 years ago

In 11 years I've only worked with two that I thought were great. But those two have convinced me that they can add a tremendous amount of value.

Think of them as oil in an engine. The best ones know how to communicate extremely well, are paragons of organization, and know how to facilitate decision making.

I've gone from first contact to first day in 5 (monday -> monday). I think it's imperative that you work quickly when it comes to candidates. Do your due diligence and when a candidate is in the office give them your time and attention. I have found that if you do that, it's easy to make an offer after one day interview.

Thiel on 60 minutes 14 years ago

Not necessarily true. I 'attended' college for 4.5 years, completed 140% of the required credits to graduate but I'm technically 3 classes shy of my degree. I left school in 2003.

Suffice it to say, I don't think has_degree can be implemented as a one-liner.

Have you read the who is hiring thread? More and more companies are okay with remote workers. Anecdotally I hired a guy recently who is remote. I don't want to comment on his salary ... but i wouldn't be typing this if it were less.

New Delhi, India -- Full time.

I'm the CTO of a startup being funded by Airtel (largest mobile telephone provider in India) and Softbank trying to attack the mobile application landscape in India. I was so excited about this I moved to New Delhi from San Francisco :).

In particular, we'll be building a free messaging solution for mobile phones. Expect to work on systems w/ millions of concurrent connections, iOS, Android and other mobile application environments. If you're looking for a startup in India in this space contact me @ vr@bsb.in

Orbitz/Expedia are travel-agents --- kayak/ITA Software are simply aggregators of flight results. There is a world of difference. For one thing, I am not sure how Kayak would be able to handle an itinerary that has multiple airlines in involved (take AA from SFO->Bangkok, then continue on Bangkok Airlines to somewhere else for instance).

Additionally, with a travel agent (like Orbitz/Expedia) you buy your ticket through them, and you can contact them if your travel plans change. I recently (last week) was unable to board my flight to Thailand because my passport expired in <6 months. Even though my ticket was not refundable, the terms that orbitz had with my airline allowed me to cancel (after I missed my flight) for 200 dollars. That experience alone has made me rethink booking any airline faires directly through the airline website.

Wouldn't that also lead to incentives for teachers to encourage students towards professions that would have greater future earnings? Thereby discouraging them from fields that may be useful to society but not that economically viable (I shudder at the thought of every teacher encouraging their students to work on wall street :) )

Well ... did you want leave your company? If that's the case then going back seems like the wrong idea. If you're good, you can find a new job in this market in no time.

So many questions (and so many places this could have been fixed). a) As soon your dive buddy saw your air gauge was that low he should have gone into the share air procedure. Parent's idea of letting him have your main reg while fumbling for the spare is also a good idea (although I don't believe most training includes that step). b) The divemaster should have been proactive about asking you how much air you had. It is really easy to suck down a lot of air quickly (especially your first few dives) and asking the group how much air they are using early on can indicate if someone is being aggressive with their air. c) i can't believe you guys were spread 60-70 (in total) away from each other. That's pretty far. d) If you were that low under where you ran out after 10 feet, the DM should have taken you up. Remember you also need to inflate your BCD on the surface, you don't know if the boat is going to be there, lots of things can still go wrong.

I've been in a really similar situation. 100 feet down, my dive buddy was someone who hadn't dove in 5 years. It was a drift dive and he was trying to take a lot of pictures. 20 minutes into the dive (the DM queried, he didn't volunteer) he revealed he had roughly 500 PSI left (some believe that's the level you should be at when you get out of the water). Our DM sent us up together, we shared air ... but it was still touch and go.

This is generically how long-polling usually works (you have one fast channel for sending messages, then a persistent HTTP connect (either using longpolling or http streaming) to send back responses/results.

However it doesn't seem like you would need that type of architecture unless you need to push data from the server to the client (like email updates or instant messages). There's no real harm in having the first connection open while the server is processing the request.

The company I work for is currently looking for people interested in machine learning & data analysis and I've interviewed a fair number of people that have a background/story similar to yours. The one piece of advice I have is to spend time learning how to take raw logs and munge/join/split them into a format that you can stick into R. Get good at a scripting language, understand what map-reduce is, play with PIG or Hive if you can. Are you considering leaving your PhD and going into industry (it sounds like you are).

We've got a few TB in couchdb-lounge (we also wrote couchdb-lounge) so we think it works. Big pluses ... it's got a RESTful API which means that we don't need a special library to access it in any language ... if you can speak http you can talk to couch. This is especially important for us because there are lots of places where we like to talk to our databases asynchronously. It's a lot easier to find an async HTTP API than it is to find a random db API.

(expanding on this) nginx uses a buffer-chain architecture internally. This means that if your data comes in chunks when you read it in (remember, nginx is event based) then it's stored internally in fragments that correspond to those reads. Almost all the operations on it work on those chains so often times the data never has to be copied until it's written (I believe using iovectors) back out. Memory is managed in request pools which minimize memory fragmentation, and are just faster/safer than calling malloc/free directly.

I went to cal and work in silicon valley filled with students from stanford. It hurts me. Especially because I am constantly impressed with the quality of the students that come out of stanford. The students I've interviewed coming out from Cal are intelligent and have learned CS but the Stanford students have so much real world experience. Because of their internships they learn about relevant technologies. Because they understand relevant technologies, they can build fun little web apps in their spare time. Fun little apps like "Zombies". Also, the grading system is significantly more lenient. As such, a student can afford to spend a little time learning javascript instead of determining if a problem reduces to a k-SAT problem. So that's my magic formula for encouraging startups (and the startup mentality). Bright Kids + Technology + free time to fool around. I don't think you need a class in that.

Plus w/ jsonp can't get the response from POST requests and you don't get notification that your page didn't load. So your web-stack needs to be able to handle sending any errors via jsonp as well.

In any case, they don't solve the same problem. Jsonp solves the problem of talking to another domain (PostMessage does the same thing). Channels solve the problem of the browser limiting the number of concurrent HTTP requests you can have open to one domain.