Да, в настольном файне так же есть аналогичные предобработки и сценарию распознавания фотографический изображений в нем так же уделено значительное внимание. Доля таких изображений очень велика, поэтому мы про них помним.
Однако тут есть еще один момент — совсем не факт, что улучшив изображение для глаз пользователя мы принесли пользу и распознавателю, вполне может оказаться что и наоборот… Поэтому тут задачи на самом деле две — улучшение видимого качества и предобработки связанные с повышением качества распознавания.
Обычный продуктовый цикл FineReader-а составляет порядка двух, двух с половиной лет, что нормально для технологических продуктов… Так что все под контролем, работаем ))
Не все так просто — чтобы взять даже несколько кусочков текста, нужно провести полноценный анализ документа, чтобы хотя бы определить где там текст… С другой стороны — языки в комбиках подставляются на основе данных из браузера и это закрывает процентов 80 сценариев, так как в большинстве случаев пользователи распознают документы на родном языке (и на английском)
Так что вряд ли такие сложности имеют смысл.
Хороший вопрос =) Строго говоря, автодетект языков в файне есть и очень давно. Проблема только в том, что эффективно он работает на довольно ограниченном наборе, примерно 6-8 языков… Если больше, то сильно страдает скорость и качество определения. На FineReaderOnline мы ограничили автовыбор до 3-х языков, чтобы не перегружать интерфейс и не сильно загружать сервер.
До недавнего времени, на практике этого было достаточно, чтобы мы не вкладывались в разработку полноценного автодетекта, всегда есть более интересные области, куда имеет смысл приложить усилия. Однако недавно стали приходить запросы на полноценное автоопределение, так что _возможно_ через некоторое время мы это поддержим.
Да, примерно так и везде. Например, зарплаты IT-шников в NY и Silicon Valley, раза в полтора больше чем в Сиэттле (не смотря на MS, Amazon и кучу компаний поменьше), и раза в два больше чем в какой-нибудь Айове.
Дмитрий, вы хотите сказать, что доход рядового инженера нефтянника сильно выше? Вынужден вас разочаровать. =) В top 12 самых доходных профессий входит только один oil engineer и аж три профессии связанные с разработкой. И не стоит делать далеко идущих выводов из рабочего места — тот же oil engineer зачастую обходится карандашом и бумагой.
Дмитрий, скажем так… ошибается. Поскольку делает не очень правильные выводы из недостаточных данных. Стоимость оборудования и софта для разработки, по сравнению с зарплатой — другой порядок малости, так что много тут не сэкономишь. «Маржа», как выражаются собеседники, в этой индустрии одна из самых высоких — выгоднее только наркотиками торговать и GPRS-траффиком в роуминге.
Таким образом, IT индустрия — одна из самых богатых. Однако это никак не коррелирует (и не должно) с наличием у разработчиков соответствующего софта и оборудования.
Вообще, рассуждения собеседников относительно бизнеса выглядят крайне наивно =)
Про KPI, например — отсутствие внятных целей, контроля, планирования и стратегии в компании типа JetBrains — это нормально. Это просто проблемы роста — ребята нашли удачную нишу, проделали отличную работу, заработали много денег и теперь их некоторый переизбыток. Как только деньги закончатся, тут же появятся и контроль, и планы, и KPI. Хорошо бы, конечно, чтобы это длилось как можно дольше, но тут уж как повезет…
Про Enterprise — тоже смешно ;)
К сожалению FoxIt-овский движок очень далек от совершенства и открывает хоть и быстро, но весьма криво и далеко не все… По качеству рендеринга он сильно уступает pdfl.
"… и договор заключать придется только с одной организацией"
Вот это неверно. Договора с конкретными платежными системами все равно придется заключать, так что тут агрегатор мало чем поможет.
С чего бы это им чаще происходить? В обычном MVCC-шном снэпшоте RW не конфликтуют, поэтому там потенциально число конфликтов меньше, однако в предложенной технике RW вполне себе конфликтующие операции. Что не удивительно, иначе транзакции нельзя было бы корректно сериализовать.
Таким образом, число конфликтов, при одинаковой схеме данных и запросах, при использовании обоих техник должно быть одинаковым, и это при условии что в SSI корректно реализовали все известные блокировочные оптимизации типа key-range lock-а.
А я имел ввиду сравнение с традиционными блокировочными планировщиками =)
В отсутствие конфликтов накладные расходы в среднем одинаковые, а вот если конфликт случился, то в большинстве случаев подождать на блокировке будет дешевле чем откатывать транзакцию и пытаться выполнить ее снова.
Молодцы! =)) Другое дело что «без существенного замедления работы» вопрос открытый. В случае конфликта откат транзакции скорее всего будет дороже блокировки, хотя тут все от конкретных сценариев зависит. Но в любом случае, хорошо, что появился уровень изоляции гарантирующий честный Serializability без дополнительных приседаний.
Как уже было сказано Serializable Postgree — не соответствует честному Serializable, который описан в стандарте. В частности он допускает аномалии типа write skew, чего честный Serializable делать не должен.
Вообще, класика подробностей про уровней изоляции — A Critique of ANSI SQL Isolation Levels research.microsoft.com/pubs/69541/tr-95-51.pdf
Не во всех, а только в версионных. Для реализации честного Serializable нужно уметь делать предикатные блокировки, чего MVCC не умеет. Блокировочные же планировщики отлично с этим справляются — см. MSSQL, DB2.
Не, не тянет, что с шаманством, что без шаманства. Пробовал играться и ION-ом, неделю мучался, кодеки всякие перебирал — все равно не справляется. В итоге сдал обратно, собрал на i3, за ту же примерно цену, и горя не знаю.
Однако тут есть еще один момент — совсем не факт, что улучшив изображение для глаз пользователя мы принесли пользу и распознавателю, вполне может оказаться что и наоборот… Поэтому тут задачи на самом деле две — улучшение видимого качества и предобработки связанные с повышением качества распознавания.
Так что вряд ли такие сложности имеют смысл.
До недавнего времени, на практике этого было достаточно, чтобы мы не вкладывались в разработку полноценного автодетекта, всегда есть более интересные области, куда имеет смысл приложить усилия. Однако недавно стали приходить запросы на полноценное автоопределение, так что _возможно_ через некоторое время мы это поддержим.
Таким образом, IT индустрия — одна из самых богатых. Однако это никак не коррелирует (и не должно) с наличием у разработчиков соответствующего софта и оборудования.
Вообще, рассуждения собеседников относительно бизнеса выглядят крайне наивно =)
Про KPI, например — отсутствие внятных целей, контроля, планирования и стратегии в компании типа JetBrains — это нормально. Это просто проблемы роста — ребята нашли удачную нишу, проделали отличную работу, заработали много денег и теперь их некоторый переизбыток. Как только деньги закончатся, тут же появятся и контроль, и планы, и KPI. Хорошо бы, конечно, чтобы это длилось как можно дольше, но тут уж как повезет…
Про Enterprise — тоже смешно ;)
Вот это неверно. Договора с конкретными платежными системами все равно придется заключать, так что тут агрегатор мало чем поможет.
И еще один нюанс с платежными системами — с юридической точки зрения в большинстве случаев договор с нашими систетмами типа яндекса, wm, etc… не гарантирует ничего. Например, по договору с YD вы имеете только «право потребовать свои деньги» ©. Никаких юридических гарантий того что вы получите свои деньги такой договор не дает. Переводя на бытовой — если YD просто не захочет вам платить или вообще прикроет свой бизнес, по любой причине, нет никаких законных оснований получить с них ваши деньги.
Реакция наших юристов на такой договор была: «в здравом уме — никогда».
Таким образом, число конфликтов, при одинаковой схеме данных и запросах, при использовании обоих техник должно быть одинаковым, и это при условии что в SSI корректно реализовали все известные блокировочные оптимизации типа key-range lock-а.
В отсутствие конфликтов накладные расходы в среднем одинаковые, а вот если конфликт случился, то в большинстве случаев подождать на блокировке будет дешевле чем откатывать транзакцию и пытаться выполнить ее снова.
Вообще, класика подробностей про уровней изоляции — A Critique of ANSI SQL Isolation Levels research.microsoft.com/pubs/69541/tr-95-51.pdf