Не то чтобы она совсем распалась, половина контрибьюторов сменили работу в надежде использовать проект в фин секторе. Развитие продолжается, но значительно медленнее, чем раньше.
Один в один повторяет наш проект, который мы делали последние 3 года в Самсунге, перед тем как команда распалась — velesnet.ml Но в отличие от нас у Гугла есть на него ресурсы, так что желаю Джеффу Дину и компании успехов, в этой теме много чего интересного.
Мда, вспомнилось, чем отличается обсуждение нового проекта на западной площадке и на российской. Англосакс: «Wow! It can be useful to me.» Русский: «Да нафига ты это написал, это никому не надо и т.п.»
Жалко что-ли? :) Я к примеру тоже ощутил ущербность protobuf и согласен с автором. Даже если этот формат не выстрелит — заманчиво применить его у себя в специфических нишах, где он реально судя по тестам может дать профит. Собственно, именно по этой причине я вижу автор его и написал.
У меня такой вопрос, под Linux работает? Python обертку хочется, чтобы поиграться с внутренностями. Я даже готов ее сам создать, благо опыт богатый в этом.
Как мне объясняли, проблема таких сканеров в обработке полупрозрачных, зеркальных и безтекстурных моделей. А еще клетчатая рубашка на человеке может ломать алгоритм. Еще есть проблема с головой человека (если это цель скана) — камера не может снять темя и приходится изворачиваться. От степени проработки таких граничных кейсов и зависит качество работы приложения.
Технически-то оно работает и на Galaxy S5, и других железках того же класса, просто корейцы решили перестраховаться и начали с одного планшета. А вообще наши *русские* ребята очень постарались и потратили больше года на разработку.
Полностью согласен про ImageNet. Вы очень точно сформулировали, что творилось у меня в голове) соревнование превращается в вещь в себе, в проверку, у кого больше денег на кластер из GPU. Буду теперь давать на эту статью ссылку всем некомпетентным товарищам.
Столкнулся при применении Сонара со следующими проблемами:
Не поддерживает подмодули Git. В результате каждый подпроект имеет по своему сонарному. Неудобно — жуть.
Общая нестабильность работы с гитом, например если не получается blame, то весь анализ фейлится.
(У меня питон) Мало анализаторов для питона, а для, к примеру, pylint, непонятно как прикручивать .pylintrc.
У всех проектов одинаковый view (ссылки слева, нельзя настраивать индивидуально Dashboard-ы, т.е. абсолютно разноплановые проекты чешутся под одну гребенку.
Если кто-то в курсе, как решать эти проблемы, то буду очень благодарен.
Ах да! Всем командой гадаем, как же они измеряют technical debt.
Подтверждаю, поднимал цеф на 8 узлах, в течение месяца 3 непоправимо сломались. Достаточно сложная документация и отсутствие базы ответов stackoverflow в итоге победили.
А откуда брать критическое значение нормированного нормального распределения при данном уровне значимости?
Правильно ли я понял, что E(H) находится «в лоб», с помощью того же самого МНК?
А убрать панель поиска справа (чтобы был омнибокс на всю ширину окна) еще нельзя? Вот тут люди тоже интересуются. После хрома раздражает, честное слово.
Если ваше утверждение состоит в том, что использовать **kwargs в конструкторе класса — бардак в ООП, то, пожалуй, на этом обсуждение можно закончить. Go ahead и копипастите списки из 15-20 именованных параметров с дефолтными зачениями из __init__-а в __init__ в 300 классах (они к тому же все понемногу или помногу разные).
Если нет, то в конце, когда вы на-pop()-ались, и оказался избыток, вам все равно нужно строить матрицу расстояний и сообщать пользователю о похожих или вообще «левых» kwarg-ах. Снова приходим к декораторам и метаклассам для автоматизации этой проверки. Получается, по сути, ваш способ просто делает явным проверку имен, без «магии». Однако, это накладывает дополнительные ограничения на разработчика и N+1-ую строку в JIRA о том, «как у нас принято вести разработку этого проекта». Хотя, в принципе, подход рабочий, можно добавить к существующему. Спасибо.
kwargs.pop() будет давать коллизии при наследовании, когда и родитель и потомок обращаются к одному аргументу. kwargs в конструкторе используем, т.к. у нас есть набор обязательных аргументов и мы их требуем через zope.interface, а другие необязательные и имеют деволтные значения — их засунули в kwargs.
Жалко что-ли? :) Я к примеру тоже ощутил ущербность protobuf и согласен с автором. Даже если этот формат не выстрелит — заманчиво применить его у себя в специфических нишах, где он реально судя по тестам может дать профит. Собственно, именно по этой причине я вижу автор его и написал.
У меня такой вопрос, под Linux работает? Python обертку хочется, чтобы поиграться с внутренностями. Я даже готов ее сам создать, благо опыт богатый в этом.
Если кто-то в курсе, как решать эти проблемы, то буду очень благодарен.
Ах да! Всем командой гадаем, как же они измеряют technical debt.
Правильно ли я понял, что E(H) находится «в лоб», с помощью того же самого МНК?
Если нет, то в конце, когда вы на-pop()-ались, и оказался избыток, вам все равно нужно строить матрицу расстояний и сообщать пользователю о похожих или вообще «левых» kwarg-ах. Снова приходим к декораторам и метаклассам для автоматизации этой проверки. Получается, по сути, ваш способ просто делает явным проверку имен, без «магии». Однако, это накладывает дополнительные ограничения на разработчика и N+1-ую строку в JIRA о том, «как у нас принято вести разработку этого проекта». Хотя, в принципе, подход рабочий, можно добавить к существующему. Спасибо.