Можно было делать valid свертки и кропать в конце dst меньше (или совсем не кропать), но тогда нужно больше думать про размеры — так что с целью упрощения кода и спокойствия я делал same свертки и кроп в конце, и у ребят как я понял такой же подход.
О, классный график!
Я пробовал reflective padding чтобы предсказывать на краях картинки, на всех классах с мелкими деталями это только ухудшало финальный скор, и визуально было много false positives.
Все данные мы храним в базе данных (используем Postgres), данные которые вводятся ничем не отличаются от тех данных, которые загружаются из других систем. Для быстрого анализа данных используем свой in-memory движок вычислений и запросов, т.е. Postgres используется только как хранилище данных.
Спасибо!
Коннектор к Mango Office планируем, как раз недавно отправили запрос на доступ к закрытой бете, надеюсь ответят в ближайшее время.
Про Power BI: сам с ним не работал, только читал статьи и смотрел видео, выглядит красиво. Насколько я понимаю, у них как раз тоже недавно появилась возможность из коробки получать дашборды и отчеты по гугл-аналитике и некоторым другим сервисам. Кроме коннекторов к российским сервисам, основное наше отличие — это возможность ввода и редактирования данных с полной историей изменений — это интересно в той ситуации, когда после анализа данных хочется сделать выводы и зафиксировать их, например ведя плана продаж, или дополняя данные из других систем (всегда чего-то не хватает), или при бюджетировании. Почти все наши клиенты эту возможность используют.
Конкурентов много конечно :) Но все разные.
Есть например Roistat: насколько я понимаю, у них готовое решение как раз в области веб-аналитики + есть интеграции с телефонией и CRM. Мы в отличии от них гораздо меньше понимаем в веб-аналитике и не дадим готовых советов «из коробки», но зато если нужно более универсальное решение, с вводом данных, загрузкой из различных источников (баз данных, 1С, Excel и т.п.) и построением произвольной структуры данных, то в этой ситуации мы лучше подходим.
Есть QlikView/QlikSense — это уже универсальные решения для BI. У них все очень красиво и «волшебно», но дорого и нет (или почти нет) облачной версии, а также ввода данных и коннекторов/модулей к российским сервисам, т.е. для российского SMB на мой взгляд мы лучше подходим.
И наконец есть Excel и Google Spreadsheets — которые проще в начале работы, но не справляются когда становится много данных и людей — сложно поддерживать актуальность отчетов и источников данных, сводить все вместе. Некоторые наши клиенты как раз используют нас просто как замену Google Spreadsheets.
Кто-нибудь уже сравнивал 2.7.11 для своих приложений?
Интересно что CPython 2.7.10 по сравнению с 2.7.2 по многим бенчмаркам работает медленнее (https://mail.python.org/pipermail/python-dev/2015-June/140418.html), интересно исправят ли что-то для 2.7.11? И опять же, интересно насколько это заметно на реальных задачах.
Понял вас, спасибо! То что описано в статье действительно не такое решение, и скорее ориентировано на внедренца, который как раз может сделать начальную настройку.
По привязке — понял, действительно бывает, в исходных данных просто не хватает информации. Еще хорошо когда в исходных данных просто все слишком детально, и дальше можно просто указать какие статьи куда ложатся. Хуже когда наоборот.
Скажите, а почему «не для маленьких»? Мы как раз хотим и для маленьких тоже, поэтому интересно почему такое впечатление. Из-за необходимости настройки? Для стандартных конфигураций можно сделать модули, которые будут работать «из коробки», сразу строя готовую отчетность — но мы пока не знаем, насколько такие модули могут быть универсальны.
Про привязку к заказам/проектам и т.п. — как правило исходные данные уже привязаны к заказам/проектам и т.п. Возможно я не понял что вы имеете ввиду. Но в целом финанализа «автоматом» не получится конечно.
Да, это отличная штука, был у них на семинаре недавно, и сам потом поработал. У нас идея в том, что модуль анализа построен на том же принципе и позволяет быстро и удобно смотреть на данные под разными углами, но в отличие от QlikSense/QlikView есть возможность ввода и редактирования данных непосредственно в системе. Т.е. у нас in-memory вычисления на лету синхронизируются с базой, в которую через тот же интерфейс возможен ввод данных, а у QlikView write-back идет только в память — они специализируются на задаче анализа.
Да, про PowerPivot в этом контексте мы не думали, спасибо за наводку!
SQL Server + импорт файлов + PowerPivot означает, что пользователи вводят данные в excel, дальше они автоматом попадают в SQL Server, и по ним можно строить отчеты при помощи PowerPivot, правильно? Если так, то основное отличие у нас в том, что это один продукт, который проще настраивать/менять модель данных, плюс всякие менее существенные тут отличия вроде наличия истории изменений.
В целом эта связка (sqlserver + excel + powerpivot) выглядит интересно, если позволяет прямо из Excel в базу писать данные.
Да, на «серебряную пулю» мы и не претендуем. Сейчас мы проверяем гипотезу, что
1) есть небольшие компании или отделы, работа которых сейчас строится прежде всего через Excel
2) они недовольны этой ситуацией по описанным в статье причинам
3) стандартные ERP (или более специализированные) решения или слишком сложны/дороги во внедрении, или требуют слишком существенных доработок
Если задача прежде всего в формализации/автоматизации бизнес-процессов (упор на слово процессы), то это уже 100% задача ERP, согласен. Нам интересны ситуации когда сам процесс не сложный или не формализованный, а упор больше на порядок в данных и на анализ.
Для клиентов/пользователей/звонков/продаж используют CRM.
В excel только выгрузка сводной информации.
Да, если можно все вводить в CRM, это уже хорошо, сильно упорядочивает процесс. Пример был про то, почему google docs не решают всю проблему, возможно не совсем в тему.
Для построения отчетов часто нужна детальная информация (или выгрузки в разных разрезах), но в целом со схемой когда данные вводятся в CRM, дальше автоматом через API перегружаются в гугл-доки и в них всегда актуальные отчеты, наверное тоже можно жить, пока хватает возможностей гугл-докс для анализа и не появляется других источников информации.
Да, про это немного есть в статье (имею ввиду Google Spreadsheets) — они решают проблем пересылки файлов по почте, но при этом не решают многих других проблем: если данные становятся сложнее чем одна таблица или список, например когда про одни и те же объекты разные люди вводят разную информацию, может получится дублирование или необходимость повторного ввода по сути одних данных. Самый простой пример — в одном месте мы ведем справочник объектов (клиенты/пользователи и т.п.), в другом про них что-то вводим (цены/звонки/продажи), и тут перевводить данные про исходный не хочется, но хочется видеть про него разную информацию. А в третьем месте хотим видеть отчет по числу звонков или суммарным продажам. Плюс то что написано выше про объем данных и интеграцию.
Но для каких-то случаев гугл-доки вполне нормальное решение, сами их используем активно.
Да, по статье в вики выглядит прямо очень похоже на решение описанной проблемы, спасибо! Сами мы с ним не сталкивались, какие у вас впечатления от него, насколько сложно начать работать?
Да, в этом посте больше про рекламу, но песни мы тоже искали.
data-driven подход к рекомендациям звучит очень заманчиво, да! Интересно, как это можно сделать.
Про студийную/концертную запись сходу не отвечу, нужно попробовать — сложно сказать насколько они в плане темпа точно совпадать будут.
В целом то подход который описан очень ограничен, зато простой.
Очень интересно, спасибо! Насколько я понял, существенную часть работы делает scipy.signal.fftconvolve — но я пока не смог понять интуитивно, как и почему он работает при анализе двух звуковых фрагментов. Не знаете, где про это можно почитать?
Я пробовал reflective padding чтобы предсказывать на краях картинки, на всех классах с мелкими деталями это только ухудшало финальный скор, и визуально было много false positives.
Коннектор к Mango Office планируем, как раз недавно отправили запрос на доступ к закрытой бете, надеюсь ответят в ближайшее время.
Про Power BI: сам с ним не работал, только читал статьи и смотрел видео, выглядит красиво. Насколько я понимаю, у них как раз тоже недавно появилась возможность из коробки получать дашборды и отчеты по гугл-аналитике и некоторым другим сервисам. Кроме коннекторов к российским сервисам, основное наше отличие — это возможность ввода и редактирования данных с полной историей изменений — это интересно в той ситуации, когда после анализа данных хочется сделать выводы и зафиксировать их, например ведя плана продаж, или дополняя данные из других систем (всегда чего-то не хватает), или при бюджетировании. Почти все наши клиенты эту возможность используют.
Есть например Roistat: насколько я понимаю, у них готовое решение как раз в области веб-аналитики + есть интеграции с телефонией и CRM. Мы в отличии от них гораздо меньше понимаем в веб-аналитике и не дадим готовых советов «из коробки», но зато если нужно более универсальное решение, с вводом данных, загрузкой из различных источников (баз данных, 1С, Excel и т.п.) и построением произвольной структуры данных, то в этой ситуации мы лучше подходим.
Есть QlikView/QlikSense — это уже универсальные решения для BI. У них все очень красиво и «волшебно», но дорого и нет (или почти нет) облачной версии, а также ввода данных и коннекторов/модулей к российским сервисам, т.е. для российского SMB на мой взгляд мы лучше подходим.
И наконец есть Excel и Google Spreadsheets — которые проще в начале работы, но не справляются когда становится много данных и людей — сложно поддерживать актуальность отчетов и источников данных, сводить все вместе. Некоторые наши клиенты как раз используют нас просто как замену Google Spreadsheets.
Интересно что CPython 2.7.10 по сравнению с 2.7.2 по многим бенчмаркам работает медленнее (https://mail.python.org/pipermail/python-dev/2015-June/140418.html), интересно исправят ли что-то для 2.7.11? И опять же, интересно насколько это заметно на реальных задачах.
По привязке — понял, действительно бывает, в исходных данных просто не хватает информации. Еще хорошо когда в исходных данных просто все слишком детально, и дальше можно просто указать какие статьи куда ложатся. Хуже когда наоборот.
Для фреша коннектора сейчас нет, думаем об этом.
Про привязку к заказам/проектам и т.п. — как правило исходные данные уже привязаны к заказам/проектам и т.п. Возможно я не понял что вы имеете ввиду. Но в целом финанализа «автоматом» не получится конечно.
SQL Server + импорт файлов + PowerPivot означает, что пользователи вводят данные в excel, дальше они автоматом попадают в SQL Server, и по ним можно строить отчеты при помощи PowerPivot, правильно? Если так, то основное отличие у нас в том, что это один продукт, который проще настраивать/менять модель данных, плюс всякие менее существенные тут отличия вроде наличия истории изменений.
В целом эта связка (sqlserver + excel + powerpivot) выглядит интересно, если позволяет прямо из Excel в базу писать данные.
1) есть небольшие компании или отделы, работа которых сейчас строится прежде всего через Excel
2) они недовольны этой ситуацией по описанным в статье причинам
3) стандартные ERP (или более специализированные) решения или слишком сложны/дороги во внедрении, или требуют слишком существенных доработок
Если задача прежде всего в формализации/автоматизации бизнес-процессов (упор на слово процессы), то это уже 100% задача ERP, согласен. Нам интересны ситуации когда сам процесс не сложный или не формализованный, а упор больше на порядок в данных и на анализ.
Да, если можно все вводить в CRM, это уже хорошо, сильно упорядочивает процесс. Пример был про то, почему google docs не решают всю проблему, возможно не совсем в тему.
Для построения отчетов часто нужна детальная информация (или выгрузки в разных разрезах), но в целом со схемой когда данные вводятся в CRM, дальше автоматом через API перегружаются в гугл-доки и в них всегда актуальные отчеты, наверное тоже можно жить, пока хватает возможностей гугл-докс для анализа и не появляется других источников информации.
Но для каких-то случаев гугл-доки вполне нормальное решение, сами их используем активно.
Да, в этом посте больше про рекламу, но песни мы тоже искали.
data-driven подход к рекомендациям звучит очень заманчиво, да! Интересно, как это можно сделать.
Про студийную/концертную запись сходу не отвечу, нужно попробовать — сложно сказать насколько они в плане темпа точно совпадать будут.
В целом то подход который описан очень ограничен, зато простой.