Добавляйте везде статистику и описание алгоритмов (теоретически как производится работа) или их применения. Это интересно и самое главное вряд ли кто то воспользуется вашей идеей. Если голова есть, то сторонний разработчик до подобного сам дойдёт, а если головы нет то кривые руки всегда всё испортят.
Я зашёл с другой стороны: необходимо понять текст, понимая текст можно отвечать на вопросы, отвечая на вопросы можно получить информационную суть текста, а имея её можно не просто отвечать на вопросы или делать рерайт текста, но и делать выжимку из текста например сокращая новости или получить «войну и мир» вкратце. Интерфейс голосовых команд можно использовать и сторонний. Не спеша за 7 лет свободного времени я получил такую статистику:
До анализа на основе «войны и мира» пока не добрался, тестирую на небольших текстах — новостные заметки и рецепты блюд.
Ждём от Вас продолжений статей с более техническими подробностями.
1. >> К сожалению, для доступа к этим данным очень часто требуется договор с туроператором. Так что просто так выполнить экспорт не получится. Для этого пришлось зарегистрироваться как юридическое лицо и помучаться с подписанием множества документов.
2. >> Сбор данных осуществляется более чем со 100 туроператоров.
3. >> Своими руками.
Из этого следует вопрос — всё таки ко всем 100 операторами подключались руками и потратили на это человеко-год? Или всё же подключались к нескольким более глобальным шлюзам а нескольких пришлось подключить руками? Интересен данный момент — буду благодарен если расскажите.
Так вроде давно через спец. контроллер можно подключить Литий-полимерный аккумулятор, у «аналогов» малинки есть даже уже разъёмы для прямого подключения Li-Po и с хорошим аккумулятором работает всё гораздо дольше чем PiJuice (так как и 4000 mAh можно подключить).
Задам тогда вопрос впрямую, как мне обменять умерший на 3 месяц Vector из-за не работающей прошивки на аналогичный новый, где например это можно без гемороя сделать в Москве? А то лежит мёртвым грузом второй год.
Ага и будет так же работать 3 месяца как Vector умирать унося информацию с собой, а для перепрошивки нужно будет отсылать диски в Европу (месяц туда, месяц обратно с Российской почтой) если додолбитесь в службу поддержки. Ищите легковерных…
Лучше для начала реабилитируйтесь — обменяйте мне Ваш умерший Vector из-за не работающей прошивки на аналогичный новый, где например это можно без гемороя сделать в Москве? А то лежит мёртвым грузом второй год.
У меня просто умер Vector. И в отличие от топика выше я даже не получил ответ от службы поддержки OCZ. Плюнул и купил SSD от Intel, чуть позже установил Toshiba во второй ноутбук, оба отработали по времени больше чем Vector. Так что рекомендую купить вместо OCZ — Samsung, Toshiba или Intel и бутылку виски, что бы отметить то от какого нервного напряжения Вы избавились не связывая свою жизнь с OCZ.
Т.е. вопрос именно по полноценному сервису, а не не совсем как партнёрка с ограничением в 100 запросов в час и ограничениями на конверсию и показ (который приводит forgotten выше)? Чтобы поверх вашего API можно было сделать сервис и интегрировать его к своему сервису по поиску ресторанов (понимаю, что ограничения направлены против паразитного парсинга данных, понимаю что большая часть данных будет браться в нашем сервисе из нашего сервиса, но даже в таком случае 9% кликов из запросов и 5% в покупатели для меня будет довольно много)? Если это можно сделать, то скажите куда можно написать чтоб продолжить диалог?
>>> P.S. Кстати, нам очень нужны опытные программисты и сисадмины для работы над крупным проектом на основе AWS/Elasticsearch/Symfony2 в Берлине. Если вдруг вам интересно — пишите!
Ну и получат второй иск от Бориса Моисеева, так как ещё несколько лет назад видел прототип проекта о поиске по мнениям в которых как раз выдача строилась на основании важности фактов на сайте, а для подтверждения всегда можно было посмотреть на основании чего она построена, например экспертного мнения определённого эксперта и его веса и значимости.
Пруф о первом иске: Б.Моисеев директор российской компании «Эра водолея», является автором идеи и обладателем патента на технологию, реализующую принципы размещения контекстной рекламы. Этот патент был получен изобретателем в 1999 г, то есть за 2 года до того как эту технологию впервые применил поисковой гигант Google и затем повторили остальные компании.
В 2010 году работал в одно большой компании предоставляющей интернет в 37 городах России (в данный момент куплен МТС). Мы общались с подобными ребятами, но в тот момент не стали с ними сотрудничать. Ставится сервер — стойка серверов, на который зеркалируется весь трафик пользователей. Им не нужно было заходить на страницу после, они и так всё знали о пользователе из зеркала его трафика. Имея так же улицы присутствия провайдера реклама могла быть адресна вплоть до дома абонемента. Эту самую рекламу они могли вставлять вместо рекламы Googlе и Яндекс незаметным для пользователя образом (т.е. пользователь не знал что за ним следят так ещё и часть его контента на странице меняют). В общем тогда мы не стали с ними сотрудничать.
В 2011 у меня бы опыт общения с другими товарищами которые по подобной схеме для больших корпораций делают сканеры безопасности. Когда например кто-то решает послать корпоративные данные на «лево» не по корпоративной почте — из письма вырезалась служебная информация (на основании отпечатка из других корпоративных документов из базы корпоративных документов компании), а на пользователя приходил весь лог его страниц службе безопасности — куда ходил и что смотрел.
Суть в чём — название фирм я слышал в первый и последний раз (так же как никто не знает изготовителя кожи для Rolls-Royce), но технологии реальны и так как они построены на зеркалировании трафика — вычислить о слежении в половине случаев не возможно. Правда это всё для HTTP, но много ли сайтов работающих по HTTPS с шифрованием трафика?
Доклад номер №16 Benchmarking Firebird with TPC-C (Paul Reeves, IBPhoenix) — наглядно показал как скорость работы связана с прямостью рук и наличию хорошего железа, а так же количества индексов в таблице при вставке.
Отвечу какие вижу изъяны в Varnish, хотя ESI в нём замечательная штука, но предпочитаю с помощью JS грузить части страниц кэшируя их в Nginx + Memcached (получается почти то же самое, но руками делать нужно больше). Итак по изъянам:
1. Varnish будет медленнее из за I/O чем Memcached. Виртуальный диск это уже не для среднего уровня.
2. Memcached можно развернуть в кластер с помощью mcrouter (https://code.facebook.com/posts/296442737213493/introducing-mcrouter-a-memcached-protocol-router-for-scaling-memcached-deployments/).
3. Varnish менее производительный чем Squid (https://ru.wikipedia.org/wiki/Squid).
4. Когда серверов много, то на основе куки можно определить с какого сервера только, что запрашивал страницу пользователь и направить на получение страниц именно туда его, делает это nginx. Т.е. под разные языки сайта стоят разные сервера и на входи балансим пользователя на нужный сервак а там из Memcached отдаём статику. Для очень большого проекта это очень удобно.
В остальном для средних по размеру сайтов он Великолепен. Ставится минимум настроек и сразу получается ускорение которого достаточна для большинства сайтов. Так же например можно для Drupal поставить модуль SDN в котором настроить роутинг картинок на поддомен и на поддомене раздавать картинки через Varnish кэшируя их в памяти. В таком случае так же получаете хорошую скорость загрузки всей страницы.
До анализа на основе «войны и мира» пока не добрался, тестирую на небольших текстах — новостные заметки и рецепты блюд.
Ждём от Вас продолжений статей с более техническими подробностями.
2. >> Сбор данных осуществляется более чем со 100 туроператоров.
3. >> Своими руками.
Из этого следует вопрос — всё таки ко всем 100 операторами подключались руками и потратили на это человеко-год? Или всё же подключались к нескольким более глобальным шлюзам а нескольких пришлось подключить руками? Интересен данный момент — буду благодарен если расскажите.
Лучше для начала реабилитируйтесь — обменяйте мне Ваш умерший Vector из-за не работающей прошивки на аналогичный новый, где например это можно без гемороя сделать в Москве? А то лежит мёртвым грузом второй год.
Написал Вам в личных сообщениях.
Пруф о первом иске: Б.Моисеев директор российской компании «Эра водолея», является автором идеи и обладателем патента на технологию, реализующую принципы размещения контекстной рекламы. Этот патент был получен изобретателем в 1999 г, то есть за 2 года до того как эту технологию впервые применил поисковой гигант Google и затем повторили остальные компании.
В 2011 у меня бы опыт общения с другими товарищами которые по подобной схеме для больших корпораций делают сканеры безопасности. Когда например кто-то решает послать корпоративные данные на «лево» не по корпоративной почте — из письма вырезалась служебная информация (на основании отпечатка из других корпоративных документов из базы корпоративных документов компании), а на пользователя приходил весь лог его страниц службе безопасности — куда ходил и что смотрел.
Суть в чём — название фирм я слышал в первый и последний раз (так же как никто не знает изготовителя кожи для Rolls-Royce), но технологии реальны и так как они построены на зеркалировании трафика — вычислить о слежении в половине случаев не возможно. Правда это всё для HTTP, но много ли сайтов работающих по HTTPS с шифрованием трафика?
Так же архитектору базы данных и админу желательно иметь под рукой статьи по оптимизации на подобии: www.josh-hartmann.com/firebird-performance-tweaking/ и www.firebirdsql.org/file/community/conference-2014/pdf/16_tpcc_presentation.pdf
1. Varnish будет медленнее из за I/O чем Memcached. Виртуальный диск это уже не для среднего уровня.
2. Memcached можно развернуть в кластер с помощью mcrouter (https://code.facebook.com/posts/296442737213493/introducing-mcrouter-a-memcached-protocol-router-for-scaling-memcached-deployments/).
3. Varnish менее производительный чем Squid (https://ru.wikipedia.org/wiki/Squid).
4. Когда серверов много, то на основе куки можно определить с какого сервера только, что запрашивал страницу пользователь и направить на получение страниц именно туда его, делает это nginx. Т.е. под разные языки сайта стоят разные сервера и на входи балансим пользователя на нужный сервак а там из Memcached отдаём статику. Для очень большого проекта это очень удобно.
В остальном для средних по размеру сайтов он Великолепен. Ставится минимум настроек и сразу получается ускорение которого достаточна для большинства сайтов. Так же например можно для Drupal поставить модуль SDN в котором настроить роутинг картинок на поддомен и на поддомене раздавать картинки через Varnish кэшируя их в памяти. В таком случае так же получаете хорошую скорость загрузки всей страницы.