Подрядчик не потому что кубы, подрядчик у нас появился ещё на втором варианте инфраструктуры. Подрядчик -- выгоднее. Нам нужен саппорт 24/7. Чтобы в таком режиме соответствовать ТК -- нужно 4 человека. Которые в нашем случае 90% времени будут ничего не делать (только дежурить). Подрядчик намного дешевле 4 ~~админов~~ девопсов. Кроме того, он снимает с нас весь головняк с поиском кадров, развитием кадров, снимает необходимость накапливать девопскую экспертизу -- но при этом помогает быстрее достичь минимально необходимого для разработки уровня девопской экспертизы. Короче, на наших масштабах работа с подрядчиком -- с запасом выгоднее.
Даже если бы кубер был ничем не лучше, а просто модный -- нужно не забывать, что квалифицированные кадры хотят работать с модными технологиями (как девопсы, так и разработчики). Иногда решение о переходе на ту или иную технологию больше связано с кадровой составляющей, а не с технической/финансово-экономической. Отчасти в нашем случае это в том числе было причиной -- подрядчик который обслуживал вторую версию, помимо плюсов перехода в кубы попросту сказал, что они вскоре планируют отказаться от поддержки старых технологий и готовы передать нас в надежные руки другого подрядчика. Нам не хотелось ходить по рукам -- перешли на кубы. Но профиты от них тоже есть (см. ниже).
Тем не менее, технический профит от кубов тоже есть -- по кубам раскатывать обновления проще и удобнее. Но думаю коллеги их разработки подключаться если вам будет интересно и подробнее распишут, в чем удобнее.
думаю, в сырых данных OSM адреса есть (мы их не копали), но Nominatim выдает сильно меньше, чем dadata.ru (по РФ). Dadata хорошо распарсили сырые данные по адресам и сделали удобный интерфейс для работы с ними.
Так уже написали :) habr.com/ru/company/okdesk/blog/473568
Точнее, не про технические вещи, а про выбор картографического сервиса с точки зрения продукта.
Кстати, там в комментах про OSM дискуссия по поводу ограничений использования веб-сервисов OSM, если у вас на этот счет есть больше информации, я дополню статью.
Нет, не смотрели. На самом деле разные решения есть, но многие из них «поверх» OSM-а и мы начали смотреть сразу первоисточник + основные известные на РФ-рынке (2гис, гугл, яндекс).
Here видимо сами карты рисуют? Но OSM на моем ЖК немного актуальнее — показывает новые корпуса, которые в стройке, на Here их нет (но такая избыточная точность для наших задач и не нужна).
1. Прямого запрета нет, но нет и прямого разрешения.
2. По «духу», он-лайн сервис OSM — это инфраструктура для тех, кто создает карту, а не для тех, кто её использует (для использования можно скачать себе и развернуть у себя). Весьма резонно.
3. Против какой-то несущественной нагрузки администраторы «не возражают», но оставляют за собой право модерировать нагрузку от тех, кто не использует сервис по прямому назначению (см. п2). Собственно, для этого есть «расплывчатая» формулировка «Heavy use...». Т.е. «на усмотрение администраторов» (это нормально).
Дополню статью. Спасибо что обратили внимание.
Т.е. для крупных сервисов, создающих «существенную» (вот тут без конкретики) нагрузку — использование он-лайн сервисов OSM не подходит.
нам бы, конечно, проще было бы платить за готовый сервис вменяемые деньги (до 100к/год вполне ок), в любом случае, порисёчим, какие границы у leaflet по «жесткости».
Спасибо за указание, мы изучим подробнее, что означает Heavy и в каких границах это Heavy требует согласования с администратором, и дополним по мере исследования данную статью.
Да.
Если вы хотите указать на какой-то пункт, который мы неправильно поняли или учли — буду вам благодарен.
Мы в любом случае сугубо за соблюдение лицензионных ограничений и уважительно относимся к труду людей и готовы за результат труда платить.
(вы отредактировали, дополню)
«Heavy use...» — «интенсивное» очень широкое понятие и мы, конечно будет следить за тем, как часто идут обращения к сервису. Возможно, под Heavy… имеется ввиду что-то другое.
Наверное, вы имели ввиду тайлы? :)
Мы работаем с картами через leaflet
URL для загрузки и отображения слоя карты https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png
x, y, z — параметры карты, с помощью которых понимаем какую область отображаем
Подробнее leafletjs.com/reference-1.5.0.html#tilelayer
Но это уже технические детали реализации, для более «глубоких» ответов мне нужно будет призвать коллег-разработчиков :)
Уважаемый SMM-менеджер HubEx-а «Дом климата», ну вы когда заказные статьи пишите, хотя бы конкурентов изучайте.
Вот вы пишите про Okdesk
> Но нет возможности сканирования штрих кодов с серийными номерами. Нет возможности маркировки оборудования.
Конечно же, вы не правы. В Окдеске можно заводить полноценный паспорт оборудования с печатными формами, штрих и QR-кодами. Замечу, паспорт оборудования не тарифицируется отдельно и поштучно (как у HuBex-а, например, по 100 рублей за штуку).
Далее, пишите про плановые заявки, что их нельзя создать «заранее», хотя их не только можно создать заранее, но и сделать это на карте, если рядом с «будущей» заявкой есть исполнитель и разумно назначить заявку сразу на него, не дожидаясь плановой даты: prntscr.com/pdfabi
А так получается, что составили список фич, которые _хоть как-то_ реализованы у HubEx-а, по верхам посмотрели как-что сделано у представителей рынка, не разобрались, и написали статью как у HubEx-а всё норм (забыв указать, собственно, что ничего другого там и нет). Ладно бы на какой контент-помойке опубликовали. Но на Хабру то статьи посерьёзнее писать надо.
Роман, и вам привет!
О метриках было рассказано в первой части статьи: взяли точность, так как распределение категорий заявок более-менее равномерное. На 14 категориях при обучающей выборке из 1200 заявок лучший алгоритм показал 73,5%.
Иван, скрипт можно запустить из консоли. Но какой смысл, например, размещать скриншот или текст выполнения скрипта (хотя, может быть, я вас не понял). В любом случае вот пруф, что все работает: prntscr.com/hd80m6 :)
На счет приведения к нижнему регистру, согласен. В первой части немного раскрывается подробнее, что я 10 лет занимался совсем не программированием (и сейчас не занимаюсь), поэтому культура кода вероятно не дотягивает до лучших образцов. Мог бы в своей оправдание сказать, что отдельная функция нужна была в 1 части, т.к. мы предварительно фильтровали слова по признакам «мусорных», но и там можно бы было избавиться.
В заголовке кстати нет ничего про Телеграм-бота, просто изначально статья планировалась про него (и на хакатоне мы его запилили с учетом ML), но подумали, что никому про бота читать не будет интересно. А вот как сделать применимый сервис классификации заявок (вне зависимости от того, приходят они из бота или по почте) — читать интереснее (мы так думаем :).
Да вроде в комментариях писали об этом. Но я решил пока не использовать методы, с работой которых руки не дошли разобраться. Разберусь — напишу как они работают и на сколько улучшилась модель :)
Заявки в свободном стиле, как сформулирует пользователь. Падежи, окончания и формы слов — это не проблема, это задача. Впрочем, об этом написано в последнем абзаце :)
Спасибо. Всему свое время :) Ещё 4 курса специализации впереди.
> И уж совсем для полноты картины пробуйте подбирать параметры классификаторов методом поиска по сетке параметров.
этому вопросу в публикации уделено достаточно много. Вы точно прочитали всё до конца? :)
Я взял минимальный вариант :)
Подрядчик не потому что кубы, подрядчик у нас появился ещё на втором варианте инфраструктуры. Подрядчик -- выгоднее. Нам нужен саппорт 24/7. Чтобы в таком режиме соответствовать ТК -- нужно 4 человека. Которые в нашем случае 90% времени будут ничего не делать (только дежурить). Подрядчик намного дешевле 4 ~~админов~~ девопсов. Кроме того, он снимает с нас весь головняк с поиском кадров, развитием кадров, снимает необходимость накапливать девопскую экспертизу -- но при этом помогает быстрее достичь минимально необходимого для разработки уровня девопской экспертизы. Короче, на наших масштабах работа с подрядчиком -- с запасом выгоднее.
Даже если бы кубер был ничем не лучше, а просто модный -- нужно не забывать, что квалифицированные кадры хотят работать с модными технологиями (как девопсы, так и разработчики). Иногда решение о переходе на ту или иную технологию больше связано с кадровой составляющей, а не с технической/финансово-экономической. Отчасти в нашем случае это в том числе было причиной -- подрядчик который обслуживал вторую версию, помимо плюсов перехода в кубы попросту сказал, что они вскоре планируют отказаться от поддержки старых технологий и готовы передать нас в надежные руки другого подрядчика. Нам не хотелось ходить по рукам -- перешли на кубы. Но профиты от них тоже есть (см. ниже).
Тем не менее, технический профит от кубов тоже есть -- по кубам раскатывать обновления проще и удобнее. Но думаю коллеги их разработки подключаться если вам будет интересно и подробнее распишут, в чем удобнее.
Точнее, не про технические вещи, а про выбор картографического сервиса с точки зрения продукта.
Кстати, там в комментах про OSM дискуссия по поводу ограничений использования веб-сервисов OSM, если у вас на этот счет есть больше информации, я дополню статью.
Here видимо сами карты рисуют? Но OSM на моем ЖК немного актуальнее — показывает новые корпуса, которые в стройке, на Here их нет (но такая избыточная точность для наших задач и не нужна).
1. Прямого запрета нет, но нет и прямого разрешения.
2. По «духу», он-лайн сервис OSM — это инфраструктура для тех, кто создает карту, а не для тех, кто её использует (для использования можно скачать себе и развернуть у себя). Весьма резонно.
3. Против какой-то несущественной нагрузки администраторы «не возражают», но оставляют за собой право модерировать нагрузку от тех, кто не использует сервис по прямому назначению (см. п2). Собственно, для этого есть «расплывчатая» формулировка «Heavy use...». Т.е. «на усмотрение администраторов» (это нормально).
Дополню статью. Спасибо что обратили внимание.
Т.е. для крупных сервисов, создающих «существенную» (вот тут без конкретики) нагрузку — использование он-лайн сервисов OSM не подходит.
Если вы хотите указать на какой-то пункт, который мы неправильно поняли или учли — буду вам благодарен.
Мы в любом случае сугубо за соблюдение лицензионных ограничений и уважительно относимся к труду людей и готовы за результат труда платить.
(вы отредактировали, дополню)
«Heavy use...» — «интенсивное» очень широкое понятие и мы, конечно будет следить за тем, как часто идут обращения к сервису. Возможно, под Heavy… имеется ввиду что-то другое.
Мы работаем с картами через leaflet
URL для загрузки и отображения слоя карты https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png
x, y, z — параметры карты, с помощью которых понимаем какую область отображаем
Подробнее
leafletjs.com/reference-1.5.0.html#tilelayer
Но это уже технические детали реализации, для более «глубоких» ответов мне нужно будет призвать коллег-разработчиков :)
SMM-менеджер HubEx-а«Дом климата», ну вы когда заказные статьи пишите, хотя бы конкурентов изучайте.Вот вы пишите про Okdesk
> Но нет возможности сканирования штрих кодов с серийными номерами. Нет возможности маркировки оборудования.
Конечно же, вы не правы. В Окдеске можно заводить полноценный паспорт оборудования с печатными формами, штрих и QR-кодами. Замечу, паспорт оборудования не тарифицируется отдельно и поштучно (как у HuBex-а, например, по 100 рублей за штуку).
Далее, пишите про плановые заявки, что их нельзя создать «заранее», хотя их не только можно создать заранее, но и сделать это на карте, если рядом с «будущей» заявкой есть исполнитель и разумно назначить заявку сразу на него, не дожидаясь плановой даты: prntscr.com/pdfabi
А так получается, что составили список фич, которые _хоть как-то_ реализованы у HubEx-а, по верхам посмотрели как-что сделано у представителей рынка, не разобрались, и написали статью как у HubEx-а всё норм (забыв указать, собственно, что ничего другого там и нет). Ладно бы на какой контент-помойке опубликовали. Но на Хабру то статьи посерьёзнее писать надо.
О метриках было рассказано в первой части статьи: взяли точность, так как распределение категорий заявок более-менее равномерное. На 14 категориях при обучающей выборке из 1200 заявок лучший алгоритм показал 73,5%.
На счет приведения к нижнему регистру, согласен. В первой части немного раскрывается подробнее, что я 10 лет занимался совсем не программированием (и сейчас не занимаюсь), поэтому культура кода вероятно не дотягивает до лучших образцов. Мог бы в своей оправдание сказать, что отдельная функция нужна была в 1 части, т.к. мы предварительно фильтровали слова по признакам «мусорных», но и там можно бы было избавиться.
В заголовке кстати нет ничего про Телеграм-бота, просто изначально статья планировалась про него (и на хакатоне мы его запилили с учетом ML), но подумали, что никому про бота читать не будет интересно. А вот как сделать применимый сервис классификации заявок (вне зависимости от того, приходят они из бота или по почте) — читать интереснее (мы так думаем :).
> И уж совсем для полноты картины пробуйте подбирать параметры классификаторов методом поиска по сетке параметров.
этому вопросу в публикации уделено достаточно много. Вы точно прочитали всё до конца? :)