We were experimenting some rate limiting settings and the load balancer IP in front of the hn cluster wasn't excluded, both features haven't been mixed before (doesn't make much sense to rate limit a search cluster behind a load balancer).
That's a somewhat misleading wording for a classic rule of parallel algorithm: a thread is the owner of its computations.
So, each actor own a group of cells and is the only one able to modify them. This highly simplifies most algorithms, removes a lot of synchronization issues ...
This is also why in parallel algorithm you should split the outputs rather than the inputs.
Disclaimer: I'm a software engineer working on the core search engine at algolia, but the opinions of this post are my own and not an official statement.
Search is a hard job, and it's hard in many ways. The most obvious difficulties are related to relevance, and yes this part is specific to each business case. But that's not the only issues one has to solve when implementing search.
Even without speaking about the software you run, running it so that you have high availability, fast search results, fast enough to provide search as you type, reliable indexing, low latency in several regions ... This is the first service we provided, this is what SaaS is about. Being on inside of a SaaS compagnie, shows you the amount of works we save to our customers.
Then, about software solution itself. Providing search is not just about running generic piece of code. It's a whole eco system, continuously evolving. Working with a SaaS solution is hiring a team of more than hundred engineers dedicated to search. From the core software to frontend UI modules, the amount of engineering needed is way above what most companies can dedicate to search.
Back to relevance, some aspects are specific to business logic but some are also specific to search. We provide the search knowledge, so that you can focus on your own issues.
And for the software behind our services, we're not trying to build the one size fits all search tool, but a tool dedicated to the kind of search needed in today's web applications. I'm obviously biased, but I strongly believe that the kind of search we focus on, fast accurate top results rather than exhaustive search, fits terribly well our users' needs.
While I strongly support the idea that no one should write a generic allocator in production, writing it as an exercise is a very good idea.
The article looks at lot like the tutorial I wrote a long time ago ... (Every now and then, I see my old PDF in post about implementing allocators, which is disturbing since I wrote it in a hurry as a quick support for a lecture and I found it very poorly written ... )
I think it's interesting to note that using sbrk(2) is a bit deprecated, it's way easier to implement malloc(3) using mmap(2) ...
There's also better ways to handle pointers arithmetic and list management. Someday I'll put only cleaner version only ... Someday ...
Where I was teaching, we've started doing code review in classroom in basically the same spirit.
The amount of students prevents us from real selection, instead we take exercises which failed tests (and that are not empty) and explain what was wrong, identify common mistakes or bad style and try to make it correct.
We had a very good feedback on this. And we saw an evolution in students' code. It was way better than trying to do collection of bad practice ...
No, that's the price of typo tolerance and search-as-you-type, until the user validate the query you have no way to distinguish between prefix and full word.
Search-as-you-type is much more a guide during the search, it shows you a preview of possible results from what you've currently typed both as a whole query and as the beginning of a query.
All other variation are worth: no prefix during search as you type means that you'll have an empty result most of the time or things that are completely irrelevant; keeping prefix on the final search means that you'll see a lot of irrelevant results (especially with typo-tolerance).