legedemon

citext doesn't solve your problem of case-insensitive search?

Thanks for the great write-up with links to many more interesting articles and code! I have long stopped working on Linux kernel but deep dives like these are very exciting reading.

If possible, could you please explain what your slopware does?

Exactly my reaction. Every time I've used something from Google, it ends up dead in a few years. Life is too short to waste so many years learning something that is destined to die shortly

Great puzzle. Do you ship internationally?

I clicked on a random open problem and found https://www.erdosproblems.com/170. The text of the problem didn't make sense. The wikipedia article stated the problem much more nicely which was thankfully linked from the OP's website.

Wish the problem could be stated more simply on the main site as well. Will certainly try and help the owner of the website.

For someone whose interaction with spatial data is very limited, I found the article to be a treasure trove of information.

Also, thanks for sharing S2! It'll be nice to look at.

https://github.com/rubysherpas/paranoia is enough to solve problems at very large scales.

There is nothing about Rails or MVC preventing someone from doing this. This is a very common design principle for all kind of ERP and BPM systems: don't ever delete anything.

Does someone know which are the books lying on his bookshelf? Alternatively, is there an interview with Donald Knuth where he mentions the books he studies.

Could someone suggest a good book on Geometry beyond what is taught in high school? I find co-ordinate geometry to be more algebraic than geometric and miss knowing the interesting properties of curves and shapes and bodies.

When you stop consulting stackoverflow to find answers to your queries because you know that you know more than the most people browsing and willing to answer your question on stackoverflow. Or when you start answering questions on a topic rather than just reading answers posted by others.

Have to disagree a bit. If you aim to have this level and breadth of skill over a n-year period where n<5, yeah, your personal and social life would suck.

But if this is built over 5+ years by reading, doing and learning from others and teaching others while understanding what level of abstraction/detail meets the current and future business requirements reasonably well, it's not that difficult or rare.

Agree.

Pretty much agree with what r-s has written above.Have spent 11+ years working/consulting for mostly startups. Have used everything listed above except Salt (Nothing against it but the Salt team should look to so some PR and build their case) and a lot more.

For example, this job post mentions nothing about monitoring solutions like Zabbix or centralized logging solutions like Graylog or message queues like RabbitMQ or any of the myriad specialized data stores, etc.

No, it's not that hard. It's more about getting the priorities right.

The developer and production environments should be separated at a deep network level making it very very difficult for anything (rogue script, rogue admin, etc) to access production environment accidentally.

Nope, new sorting algorithms are still cropping up all over place. Already published sorting algorithms are still being implemented. And people are still accelerating the already existing implementations on GPU, SIMD-capable and FPGA devices.

This doesn't even cover security issues such as side-channel timing or entropy attacks (hard to believe?) or handling of denormal numbers (which will reduce your processing speed by upto 100x). Ever heard of using Fast Fourier Transform to achieve asymptotically faster sorting under certain conditions? All of the above have practical applications.

As you yourself said, there are interesting challenges in all communities. Let's not be dismissive of the algorithm design community.

While agreeing to the fact that performance does always matter, I think the idea that "someone else did it better" is not always a good one. One should always understand the limitations of standard implementations and see if hand-crafting something of their own would benefit their application.

For example, consider the case of sorting. Even though asymptotically efficient algorithms have been known for about 70 years now, Timsort - the currently standard implementation found in Python, Java and probably other languages - was invented as recently as in 2002.

This is not all. What if you have multiple cores available to run your code? What if your dataset is large and locality of reference matters? What if your dataset has certain special properties which the standard implementation doesn't exploit?

I agree that maybe 99% of the time, we can get away using the standard implementation but that 1% is what differentiates great from the merely good.

Nope. I happen to be a product manager for one of such internal applications with around 60 users. This can be considered as a handful of users when compared to the internet scale. Getting the product adopted even for such a small group was a big pain. The primary complaint - it is slow! After two rounds of performance optimizations, the adoption velocity for new features has increased 10x.

Yes! We are right now testing to see if there are any issues. Will move soon afterwards hopefully.

I just checked your resume linked to from your website. To be blunt, you have mentioned too many unrelated things on your resume and it sends out the message that you are a jack of many trades.

My sincere advise would be to organize it so that someone can know what you are looking for and whether you'll be the right fit for them now rather than when their E-commerce company has a computational biology division. Since you already have had a year of Rails experience, why not highlight it there? (The world rails doesn't even show up on my tablet above the fold.)

Or you can start your own company and write good old code at work for profit.

This comment from antirez: https://news.ycombinator.com/item?id=8433770

You made my day! I'm booking a slot right now.

Agreed.

I am going to discuss insurance with my employer. It looks like it is a pretty big deal in the US.

We've visited several countries in the past. So, cultural differences should not be a big problem but since so many people are emphasizing on this point, I think I'll come and stay for a few weeks as a worker rather than as a tourist and check it out again.

3 is definitely what is troubling for my family which is used to such comforts now.

Thanks for all your inputs!

Yeah, at times I like to think so but I've had so many humbling experiences that I'd wait a little longer before making that declaration.

I had once worked with a senior colleague who would run process traces on the live Oracle database and uncover bugs in Oracle's code. I am at the level where I can find bugs in open source code bases about which I've no idea but not where I can find bugs only with the binary.

Then again, I see so many comments on HN about which I've no idea and which still seem relevant to what I do.

So, you see where I am right now.

Thanks Karthik! These are exactly the kind of insights I was looking for on HN.

Thanks for your inputs! Disparity indicator is a nice phrase to know. I had not considered it from the opportunity perspective but will add it to the list of pros and cons. Some of the cool start-ups I'd love to work with are definitely in SF.

That's actually a little hard to describe exactly. In short, I do whatever needs to be done on the technical side of things - from front-end development to setting up the servers. There are two particular things that I think I'm good at - debugging and performance tuning.

I think I'll be able to call myself a full-stack developer in a few years time but for now I'm happy to be called just a RoR web developer.

Interesting. We haven't discussed anything about insurance. They are willing to reimburse the travel cost for me. I'll need to buy tickets for my wife though. I haven't really considered relocation costs but I think that'll be a one-time expense.