Recently launched a site with some basic vision behind HAI.
But the tech stack is where the rubber meets the road. I’ve been coding about two months now. At the very beginning I went through a fair amount of thinking and ended up selecting a language for the backend based on a number of factors. From languages I knew, C++, Go, PHP, Python, Java/Scala, and Node.js were on the table. Python and Java were the two top contenders, but I ended up going with Python.
So far I’ve been really happy with Python for both flexibility of the language, the available libraries for both web and machine learning, and the developer community. Ruby / Rails has an amazing community and great web stack, but given my own lack of familiarity and less work being done in machine learning, it didn’t make my list.
Then I started evaluating open source projects that would be the platform. There are 132 on the list below (looked at least 4x that many). It’s been amazing getting up to speed on the projects that are open source. Although Google, IBM, Amazon and others are clearly going to lead in the machine learning space for the foreseeable future, the open source community is catching up.
Open source is a moving target, and there’s no one size fits all when you are piecing together something new. So, I’ve been using the awesome ZeroMQ library to connect services between libraries, languages.
Finally, thanks to everyone who has provided feedback so far. Can’t wait to get what I’m working on out into the world.
I’m seeking feedback on a language or platform for a highly reliable and low latency web service / application.
Bottlenecks in a web service are usually related to data retrieval and storage, and eventually bandwidth and latency.
Highly concurrent, lightweight threads provide options for reliability, load distribution, and perceived performance that would otherwise not be available.
- Easy to use (build, deploy, monitor)
- Plentiful external, stable, pre-integrated Libraries
- Use case: distributed, non-blocking web services
- Quite a bit of message and job queueing
- multiple databases , caching
Very incomplete list of pros and cons, but some of my thoughts, highlighted.
- assume it will take great advantage of Java 1.7 concurrency, multi-core
- fairly trivial import of external java libs (except for non-thread safe?)
- new language syntax, paradigm learning curve
- doubts about JVM memory efficiency and stability as resources are constrained
- redis integration for caching
- fast, lightweight, easy language.
- some custom js would be portable to browsers (coolness)
- very new
- not as many external libs?
- narrower use cases
Would love comments, but a more complete list is presented in a survey:
allows something akin to a “group by” in SOLR
, so that the number of results returned reflect a logical grouping rather than another total.??
Faceting can be used in conjunction. Facet counts reflect subsets within results, where-as collapse counts are group by counts.
This means that Field Collapsing could be used for certain analytics, as well as the common use-case of nesting and grouping results. To use effectively, I found it helpful to “pre-collapse” certain fields, so that a new, unique string was created that could be used to easily group, since I believe you can only field collapse on a single field. (If I’m wrong, please let me know!)
This assumes you are or will be running a development version of SOLR (trunk via SVN).
Field collapsing is not yet available in SOLR trunk and you must apply a patch file to SOLR and build again.
patch -p 1 -i SOLR-236-trunk.patch
And rebuild using supplied Apache Ant scripts.
SOLR has a been a great tool for BetterLesson.org
. Because our primary database is MySQL, we looked at around 8 full-text indexers – but the two finalists were Sphinx  and SOLR. Sphinx had very tight integration with MySQL, so the learning curve seemed less. ??SOLR required a JVM, an app server, and quite a lot of configuration.
When we were deciding, an excellent SOLR book
came out just when we were choosing. Further the SOLR IRC channel and mailing list for SOLR are friendly and quite active. We even had the option for commercial support through Massachusetts’ own Lucid Imagination. So I dove in.??While the configuration is non-trivial, but the configuration parameters have proven very powerful.??
I had written a half-dozen or so custom faceted search interfaces – almost entirely using MySQL, and even one used Sesame
(an RDF store – and it eventually worked pretty well). Skipping the stories of pain, confusion and suffering on the road to enlightenment – SOLR has been great.??Used extensively at Netflix.com
and others , ??supported by Apache, based on Lucene, SOLR provides a scalable, distributed search and has good data import from MySQL, including delta queries.