Totally agree. The message content should be private and not accessible by employees. Kind of scary when you think that so many 2FA codes are sent via Twilio.
Exactly. A malicious employee could login as any user to popular services like WhatsApp, Telegram and others that are SMS auth only, simply by knowing which endpoint to hit to kickoff an auth session initiation. I hope I am not understanding this exploit correctly. This would be a massive failure on Twilio part to allow employees access to the auth code.
I'll definitely look into what can be done about those previews. Right now, it's not that hard to just load the dummy data (from the Actions Tab) and cycle through the templates, but I'll look into making the process easier.
As for the export options, as defined in the Actions Tab, you can print the resume at any time and the browser has options to print as PDF. Also, you can export the data as JSON and import it back again, keeping it completely portable.
Haven't tried the others, but Product Hunt's search is also extremely poor. Just today I searched for "mac voice control" (unquoted) and besides being very sluggish because of all the refreshing it does while I type, it returned 0 results. What I was looking for was Lacona [1] which was just featured a couple days ago and has a description containing two of the words from my query (1/3 of the description!).
This is actually a great example that shows where Algolia doesn't shine.
Algolia is great a known-item searches. Searches that are like looking up a contact in your phone list. This is a common use case with search, but one of only many.
Your use case is closer to grasping at straws because you don't know the language to use. You can't quite remember the name for something. This is also very common, and not handled well with purely string matching. Another example is in this blog article[1] where I talk about searching for "manual lawn mower" not realizing the right terminology is a "reel mower." Mapping vernacular is a hard problem, and I feel like Solr/ES while harder are better equipped for the problem.
I have not used Algolia much but that's not a particularly compelling selling point, most search engines tend to get it right if you know exactly what to query. The problem is this is, like, 1% of the difficulty of making a good search engine.
Totally agree, but in my example above I'm actually not even requiring vernacular mapping or any sort of conceptual disambiguation. Basic TF-IDF should rank that result pretty well and it certainly should not return 0 results.
In addition to being good at known item searches, my pitch for Algolia would be
(1) it's Easier to perform relevance tuning. You'd be surprised how annoying the Solr/ES defaults are. And the API is more advanced.
(2) it has much better typo tolerance (again this gets at "known item" where you fat finger something)
Algolia contains a lot of customization parameters that can be used. For example the Product Hunt example could have been solve easily by using removeWordsIfNoResults=allOptional (query is trying as a AND and if there is no results, it is tried again as a OR)
This result is indeed not good but it could be solved easily with one Algolia setting (removeWordsIfNoResult=allOptional which perform the query with all terms as mandatory and reply it with optional terms if there is no result).
That said there is always some tuning to have perfect result for a specific use case. There is no engine that provide perfect results out of the box without any tuning.
True though this assumes these direct words are mentioned in the text (assuming know synonyms). Algolia has basic synonym functionality but ES gives you a lot more power here.
Further the more words you remove, the less constrained the results get possibly creating a lot of noise. Though I assume you remove based on document frequency, which helps.
This would be a problem with this strategy regardless of search engine (ES or Algolia)
Algolia has actually a very decent synonyms support:
* mono & multi-words synonyms,
* typo-tolerance is compliant with synonyms,
* matching synonyms are highlighted,
* prefix search works also on synonyms (even on multi words).
A v2 of the synonyms API will be released in the next few days including:
* dedicated API endpoints (leveraging existing synonyms but also Algolia's "alternative corrections" and "placeholders")
* new edition UI (with search & filtering capabilities)
* one/bi direction synonyms
nice I stand corrected. The first list is what I knew about!
This is actually an interesting dividing line. As you get more sophisticated modeling fuzzier concepts over just synonyms (synonyms are just one tool for this) then I think you get out of algolias sweet spot. When text pushed into a feature space (which happens quite a lot when you're mapping vernaculars) you begin to gain more from Solr and ESs depth of customizability.
