Позволю себе не согласиться с этим (цитата с офф сайта: «Apache Lucene(TM) is a high-performance, full-featured text search engine library»). Lucene предоставляет сам по себе вполне удобный апи. На одном из проектов, на котором я работал, мы использовали чисто его (Lucene.NET, точнее), без Solr или ElasticSearch, и весьма успешно.
В конце концов, Solr или ElasticSearch--это всего лишь обертки (Facade, Wrapper, Adapter--как хотите) для Lucene, вызовы функций которых выполняются через Remote Procedure Call. Ничто вам не мещает написать свою обертку на любимом языке программирования и вызывать ее методы локально.
Но, на мой взгляд, необходимости в этом часто нет--опять же, интерфейс Lucene очень хорош сам по себе.
А чем вам не угодил Lucene? Всем требованиям удовлетворяет, есть обертки под все популярные языки. А уж о качестве и говорить нечего: даже твиттер на него перешел.
А чем, например, ваша система лицензирования лучше аналогов (типа Sentinel HASP?
И есть ли у вас Managed сборки(чтоб использовать в .net)? (потому что у HASP, например, нету, и это создает огромные трудности при подключении к .Net проектам--ведь надо подключать нативные сборки).
Вот самый, на мой взгляд, распространенный случай использования: если вам нужно вернуть из private метода пару значений. Класс создавать--излишне (и я, к сожалению, не помню, есть ли nested classes, как в C#, в С++), а out параметры--это, по-моему, хуже, чем pair, потому что больше похоже на грязный хак (как говорит дядюшка МакКоннел, программируй на языке, а не с использованием языка). Ах, да, и out параметры нарушают принцип единственной точки выхода из функции.
Работал какое-то время на большом десятилетнем .Net проекте с несколькими сотнями таблиц и сложными запросами (в т.ч. отчеты всякие).
Там пользовались BlToolkit. В нем есть очень легковесный ORM, который делает только маппинг, никакого state management, lazy queries, никакой генерации запросов (хотя сейчас есть Linq-provider) и т.п. Весь sql был в хранимых процедурах, и для всех методов Data Access Layer (репозиториев) мы просто указывали имя процедуры и тип результирующего объекта.
И такой подход (после того, как я писал с NHibernate) мне очень понравился--все плюсы sql остаются (скорость запросов, полный контроль), все минусы полновесных ORM исчезают (фокусы с ленивыми запросами, производительность, необходимость изучения разных ORM + sql), и никакого ручного маппинга. Плюс нулевой порог вхождения.
Неплохая статья, но, мне кажется, что concurrent в переводе на русский--это не конкурентный, а параллельный/одновременный/синхронный. В русском переводе Фаулера используется обычно «параллельный».
Насчет reintegrate верно написали выше (хотя указывать ревизии при мерже в бранч, думаю, надо): вливать ветку в транк все-таки обязательно нужно с помощью опции --reintegrate, а не просто merge: причина, синтаксис.
Один вопрос: А почему бы вам сразу не производить поиск по хэш-таблице/бинарному дереву (то есть брать каждое слово в тексте, и искать в этой таблице/дереву)?
Попробую привести пример из личного опыта. Например, в данный момент работаю на проекте по моделированию бизнес-процессов. Это аутсорсинговый проект.
Есть такая штука--BPML. Идея системы в том, чтобы аналитики могли задавать разные параметры работы бизнес процессов (по сути, систем массового обслуживания), с разными распределениями появления заявок, распределения типов заявок, количества свободных сотрудников и тп. За этим стоит неплохая математика типа теории вероятности и теории массового обслуживания.
Заказчик не отдавал разработку математического ядра на аутсорсинг нам, а отдал только допиливание интерфейса, интеграцию с веб-сервисами и тп.
Насколько я могу судить, разработка ПО на просторах СНГ, в основном--это корпоративные приложения, сайты: то, что не включает математику, другие инженерные области (fluid engineering, mechanical engineering, chemical engineering, electrical engineering и тп). Потому что только корпоприложения и сайты решаются аутсорсить из штатов и западной европы.
Я считаю, что на постсоветском пространстве очень низкий потолок технической квалификации, необходимой в разработке ПО, потому что у нас почти не делают сложного ПО. Поэтому у инженеров нет выбора: если хочешь расти, то только в менеджеры. Только, наверное, в Лингво, Яндексе, Касперском и Контакте (и каких-нибудь НИИ, но это отдельная история) есть высокие лестницы карьер для инженеров.
SQL с некоторыми модификациями, между прочим, Тьюринг-полный. А значит, такой же язык программирования, как и php/java, etc. Хотя в базовой версии, согласен, не совсем.
С таким никогда не сталкивался (и лучше бы вам обратиться к текущему разработчику ), но, может, это результат оптимизации компилятора, когда он просто не вызывает создание массивов, если нет других операций впоследствии?
Есть стандартная структура статей: вступление, основная часть и заключение.
Вступление нужно для того, чтобы дать высокоуровненвый обзор; чтобы читатель знал, на что обращать внимание.
А заключение нужно для того, чтобы еще раз напомнить основную идею, чтобы у вас сложилась цельная картина.
Кроме того, повторение--мать учения. Кажется, чтобы информация запомнилась, ее надо повторять через 20 минут, через пару чаов и через пару дней. Заключение как раз и соответствует первому повторению.
В конце концов, Solr или ElasticSearch--это всего лишь обертки (Facade, Wrapper, Adapter--как хотите) для Lucene, вызовы функций которых выполняются через Remote Procedure Call. Ничто вам не мещает написать свою обертку на любимом языке программирования и вызывать ее методы локально.
Но, на мой взгляд, необходимости в этом часто нет--опять же, интерфейс Lucene очень хорош сам по себе.
И есть ли у вас Managed сборки(чтоб использовать в .net)? (потому что у HASP, например, нету, и это создает огромные трудности при подключении к .Net проектам--ведь надо подключать нативные сборки).
Работал какое-то время на большом десятилетнем .Net проекте с несколькими сотнями таблиц и сложными запросами (в т.ч. отчеты всякие).
Там пользовались BlToolkit. В нем есть очень легковесный ORM, который делает только маппинг, никакого state management, lazy queries, никакой генерации запросов (хотя сейчас есть Linq-provider) и т.п. Весь sql был в хранимых процедурах, и для всех методов Data Access Layer (репозиториев) мы просто указывали имя процедуры и тип результирующего объекта.
И такой подход (после того, как я писал с NHibernate) мне очень понравился--все плюсы sql остаются (скорость запросов, полный контроль), все минусы полновесных ORM исчезают (фокусы с ленивыми запросами, производительность, необходимость изучения разных ORM + sql), и никакого ручного маппинга. Плюс нулевой порог вхождения.
Из того же разряда ORM от StackOverflow--Dapper.
Мораль: 1. надо различать легковесные и тяжеловесные ORM 2. для Enterprise проектов, по-моему, легковесные ORM--лучший выбор.
Есть такая штука--BPML. Идея системы в том, чтобы аналитики могли задавать разные параметры работы бизнес процессов (по сути, систем массового обслуживания), с разными распределениями появления заявок, распределения типов заявок, количества свободных сотрудников и тп. За этим стоит неплохая математика типа теории вероятности и теории массового обслуживания.
Заказчик не отдавал разработку математического ядра на аутсорсинг нам, а отдал только допиливание интерфейса, интеграцию с веб-сервисами и тп.
Насколько я могу судить, разработка ПО на просторах СНГ, в основном--это корпоративные приложения, сайты: то, что не включает математику, другие инженерные области (fluid engineering, mechanical engineering, chemical engineering, electrical engineering и тп). Потому что только корпоприложения и сайты решаются аутсорсить из штатов и западной европы.
Есть стандартная структура статей: вступление, основная часть и заключение.
Вступление нужно для того, чтобы дать высокоуровненвый обзор; чтобы читатель знал, на что обращать внимание.
А заключение нужно для того, чтобы еще раз напомнить основную идею, чтобы у вас сложилась цельная картина.
Кроме того, повторение--мать учения. Кажется, чтобы информация запомнилась, ее надо повторять через 20 минут, через пару чаов и через пару дней. Заключение как раз и соответствует первому повторению.