WTF moments: 1) зачем 100500 раз вызывать TO_DATE() для данных вместо одного вызова для параметра (CURRENT_DATE - 10) ? 2) если требуется дописывать значения в history_b , то проблемой будет не сколько формат поля results, а сколько конфликты при update => нужно ещё поле version (хотя на время select это не должно драматически повлиять)
P.S. 3) если нужен только Array - мы уверены, что хотим JSONB не из желания поэкспериментировать с JSONB?
КоллЭга, no offense(c), но это реальный мир, а не институт - здесь такой вещи, как "баллы", просто не существует. Либо решение неприемлемо по каким-то критериям, либо - "сойдёт".
а) конструктор бросает исключения - зло б) оптимизировать конструктор, который вызывается один раз - обычно глупость в) вложенные if-ы любой SonarQube высветит как "вонь в коде", но иногда нужно, НО! здесь не тот случай - лучше писать как "guard clause" + break/continue (раз уж используете шаблон while(true)) г) 283 раза по два создания DateTime - странно выглядит (если не вникая в суть)
Весь пост ждал, когда дойдёт до описания механизма создания idempotency key _на клиенте_, но как раз этого момента совсем нет. AFAIU, для этой проблемы бы сработал любой рандом id, генерящийся при открытии формы .
Что делать, если я нищеброд работаю в компании, подходящей консервативно к покупке софта? В прошлый раз между предложением «давайте попробуем Appium» и каким-то результатом успело пройти три месяца :(
Будет ли версия без поддержки GPU работать после окончания 14-дневного триала?
Статья начинается с того, что именно автоматическая система заставляет автора купить ненужный билет — и это используется автором, как обоснование необходимости роботизации всего. Потом автор признаётся, что ему сложно заговорить с незнакомым человеком — и опять проблему видит в недостаточной роботизированности всего вокруг. Странная логика, нэ?
Ну, подождём...(с) мыш из анекдота. Лиха беда — начало, когда-то и мой 386SX стоил 640 баков.
КМК, не стоит зацикливаться (в плане использования) исключительно на летающих дронах.
Стереозрение на SoC за 400 евро — это уже неплохо. Плюс hd-камера — и мы уже можем начинать экспериментировать с созданием робота, который в состоянии съездить в магазин за булкой.
JeVois же а) университетский стартап б) предлагает моно-зрение.
Под качеством я подразумевал именно качество, а не разрешение картинки.
Если камера для робота, она должна давать хорошую картинку в помещении при неидеальном освещении. В видео у них картинка на уровне дешёвых веб-камер. Будет жаль, если эта деталь загубит всю идею.
Хотя и с разрешением картинки не всё однозначно(с). Допустим, задача ориентирования в реальном мире — нужно распознать метку, а она находится на расстоянии 10-15-20-50 метров. Другая задача — функция видеонаблюдения. Сами уже понимаете, да? Какой мне смысл в модуле детектирования лица или человека, если фото подозреваемого будет 16*16 пикселей?
Мне одному показалось, что сам видео-сенсор почему-то взят весьма убогий?
ИМХО картинка ощутимо проигрывает тому, что выдаёт камера MobiusHD (сравнимых габаритов) за 70 баков.
Угу, " ... в преддверии старта курса ..." от людей, которые путают понятия "runtime" и "VM"
А что, есть "компонент" входит в несколько "продуктов"? Система не взорвётся?
Или такого переиспользования не бывает ? :-/
WTF moments:
1) зачем 100500 раз вызывать
TO_DATE()для данных вместо одного вызова для параметра (CURRENT_DATE - 10) ?2) если требуется дописывать значения в
history_b, то проблемой будет не сколько формат поляresults, а сколько конфликты приupdate=> нужно ещё полеversion(хотя на времяselectэто не должно драматически повлиять)P.S. 3) если нужен только
Array- мы уверены, что хотим JSONB не из желания поэкспериментировать с JSONB?Любопытно — как именно? В каком виде?
КоллЭга, no offense(c), но это реальный мир, а не институт - здесь такой вещи, как "баллы", просто не существует. Либо решение неприемлемо по каким-то критериям, либо - "сойдёт".
Ок, сорри - писал "на лету".
Да, если аргумент там не прошёл проверку - это норм.
Если в конструктор залез код "тяжёлой" иниализации - это беда.
ХЗ как там что с ТЗ, просто общие замечания:
а) конструктор бросает исключения - зло
б) оптимизировать конструктор, который вызывается один раз - обычно глупость
в) вложенные if-ы любой SonarQube высветит как "вонь в коде", но иногда нужно, НО! здесь не тот случай - лучше писать как "guard clause" + break/continue (раз уж используете шаблон while(true))
г) 283 раза по два создания DateTime - странно выглядит (если не вникая в суть)
Весь пост ждал, когда дойдёт до описания механизма создания idempotency key _на клиенте_, но как раз этого момента совсем нет. AFAIU, для этой проблемы бы сработал любой рандом id, генерящийся при открытии формы .
Хотя как себя ведут совсем небольшие модели, которые ставят на яхты — не знаю.
нищебродработаю в компании, подходящей консервативно к покупке софта? В прошлый раз между предложением «давайте попробуем Appium» и каким-то результатом успело пройти три месяца :(Будет ли версия без поддержки GPU работать после окончания 14-дневного триала?
КМК, не стоит зацикливаться (в плане использования) исключительно на летающих дронах.
Стереозрение на SoC за 400 евро — это уже неплохо. Плюс hd-камера — и мы уже можем начинать экспериментировать с созданием робота, который в состоянии съездить в магазин за булкой.
JeVois же а) университетский стартап б) предлагает моно-зрение.
https://www.youtube.com/watch?v=0XbLz0L6UdI
Если камера для робота, она должна давать хорошую картинку в помещении при неидеальном освещении. В видео у них картинка на уровне дешёвых веб-камер. Будет жаль, если эта деталь загубит всю идею.
Хотя и с разрешением картинки не всё однозначно(с). Допустим, задача ориентирования в реальном мире — нужно распознать метку, а она находится на расстоянии 10-15-20-50 метров. Другая задача — функция видеонаблюдения. Сами уже понимаете, да? Какой мне смысл в модуле детектирования лица или человека, если фото подозреваемого будет 16*16 пикселей?
ИМХО картинка ощутимо проигрывает тому, что выдаёт камера MobiusHD (сравнимых габаритов) за 70 баков.