All streams
Search
Write a publication
Pull to refresh
136
0
Вадим Марковцев @markhor

Head of Analytics

Send message
Жаль, не успели смержить BigAutoField — бигдате мешает
Не то чтобы она совсем распалась, половина контрибьюторов сменили работу в надежде использовать проект в фин секторе. Развитие продолжается, но значительно медленнее, чем раньше.
Один в один повторяет наш проект, который мы делали последние 3 года в Самсунге, перед тем как команда распалась — velesnet.ml Но в отличие от нас у Гугла есть на него ресурсы, так что желаю Джеффу Дину и компании успехов, в этой теме много чего интересного.
Вспомнил недавнюю статью на эту тему…
Мда, вспомнилось, чем отличается обсуждение нового проекта на западной площадке и на российской. Англосакс: «Wow! It can be useful to me.» Русский: «Да нафига ты это написал, это никому не надо и т.п.»
Жалко что-ли? :) Я к примеру тоже ощутил ущербность protobuf и согласен с автором. Даже если этот формат не выстрелит — заманчиво применить его у себя в специфических нишах, где он реально судя по тестам может дать профит. Собственно, именно по этой причине я вижу автор его и написал.
У меня такой вопрос, под Linux работает? Python обертку хочется, чтобы поиграться с внутренностями. Я даже готов ее сам создать, благо опыт богатый в этом.
Эх, очень хотел выступить, 2 раза подавал заявку, а в итоге даже не ответили ничего. Жаль, тема интересная была и никем раньше не освещалась.
Как мне объясняли, проблема таких сканеров в обработке полупрозрачных, зеркальных и безтекстурных моделей. А еще клетчатая рубашка на человеке может ломать алгоритм. Еще есть проблема с головой человека (если это цель скана) — камера не может снять темя и приходится изворачиваться. От степени проработки таких граничных кейсов и зависит качество работы приложения.
Технически-то оно работает и на Galaxy S5, и других железках того же класса, просто корейцы решили перестраховаться и начали с одного планшета. А вообще наши *русские* ребята очень постарались и потратили больше года на разработку.
Полностью согласен про ImageNet. Вы очень точно сформулировали, что творилось у меня в голове) соревнование превращается в вещь в себе, в проверку, у кого больше денег на кластер из GPU. Буду теперь давать на эту статью ссылку всем некомпетентным товарищам.
Столкнулся при применении Сонара со следующими проблемами:

  1. Не поддерживает подмодули Git. В результате каждый подпроект имеет по своему сонарному. Неудобно — жуть.
  2. Общая нестабильность работы с гитом, например если не получается blame, то весь анализ фейлится.
  3. (У меня питон) Мало анализаторов для питона, а для, к примеру, pylint, непонятно как прикручивать .pylintrc.
  4. У всех проектов одинаковый view (ссылки слева, нельзя настраивать индивидуально Dashboard-ы, т.е. абсолютно разноплановые проекты чешутся под одну гребенку.

Если кто-то в курсе, как решать эти проблемы, то буду очень благодарен.

Ах да! Всем командой гадаем, как же они измеряют technical debt.
Подтверждаю, поднимал цеф на 8 узлах, в течение месяца 3 непоправимо сломались. Достаточно сложная документация и отсутствие базы ответов stackoverflow в итоге победили.
А откуда брать критическое значение нормированного нормального распределения при данном уровне значимости?
Правильно ли я понял, что E(H) находится «в лоб», с помощью того же самого МНК?
По поводу shorthand, его можно интегрировать с gulp, например так:

var through2 = require('through2');
var shrthnd = require('shrthnd');

.pipe(through2.obj(function (file, enc, next) {
    var contents = file.contents.toString();
    var res = shrthnd(contents).string;
    console.log(file.path + ": shrthnd saved " + (contents.length - res.length) + " bytes");
    file.contents = new Buffer(res);
    next(null, file);
}))
А убрать панель поиска справа (чтобы был омнибокс на всю ширину окна) еще нельзя? Вот тут люди тоже интересуются. После хрома раздражает, честное слово.
Чтобы вычитать из одного признака другой, их нужно сначала пронормировать. Какой тип нормировки использовался в вашем подходе?
Если ваше утверждение состоит в том, что использовать **kwargs в конструкторе класса — бардак в ООП, то, пожалуй, на этом обсуждение можно закончить. Go ahead и копипастите списки из 15-20 именованных параметров с дефолтными зачениями из __init__-а в __init__ в 300 классах (они к тому же все понемногу или помногу разные).

Если нет, то в конце, когда вы на-pop()-ались, и оказался избыток, вам все равно нужно строить матрицу расстояний и сообщать пользователю о похожих или вообще «левых» kwarg-ах. Снова приходим к декораторам и метаклассам для автоматизации этой проверки. Получается, по сути, ваш способ просто делает явным проверку имен, без «магии». Однако, это накладывает дополнительные ограничения на разработчика и N+1-ую строку в JIRA о том, «как у нас принято вести разработку этого проекта». Хотя, в принципе, подход рабочий, можно добавить к существующему. Спасибо.
kwargs.pop() будет давать коллизии при наследовании, когда и родитель и потомок обращаются к одному аргументу. kwargs в конструкторе используем, т.к. у нас есть набор обязательных аргументов и мы их требуем через zope.interface, а другие необязательные и имеют деволтные значения — их засунули в kwargs.

Information

Rating
Does not participate
Location
Madrid, Madrid, Испания
Date of birth
Registered
Activity