Pull to refresh
50
0
Константин Кузнецов @Joshua

Программист

Send message

Заголовок хороший а статья слабая. Ни каких аспектов о работе инвалидов и с инвалидами нет. Не описаны сложности и что с ними делают хотя-бы в САПе. Ну и мифы были какие то не настоящие.

Как понимаю, нейронные сети, включая рекурентные или даже «Seq2seq с фокусами внимания», требуют для классификации гладкости и непрерывности классифицируемого объекта. Т.е. например, на картинке можно изменить достаточно большое количество пикселей и на ней все равно будет классифицироваться «кошка», и при увеличении шума мы получим плавное снижения вероятности узнавания.
Соотвественно, чем более проявляется свойство «малые изменения входных данных приводят большим изменениям классификации» тем менее применимы глубокие нейронные сети во всех их проявлениях.
Именно по этому проблема NLP гораздо сложнее распознавания образов, т.к. существуют описанные выше особенности натурального языка.
Но(!) в любых ЯП самые малые (!) изменения, например, работающего алгоритма сортировки, приведут не к малым изменениям качества работы алгоритма (чуть хуже / лучше сортирует), а он просто перестанет компилироваться и работать.
Соотвественно, у исследователей не должно быть ожиданий что нейронные сети и другие подходы в решении NLP позволят решить задачу автоматического программирования.
mknrucom, без шуток и с настороженностью прошу Вас обратить внимание на возможность развития у Вас F21.4
Здорово! А думаю, было бы еще круче, если бы AI разбирала все отдельно найденные объекты по слоям. Даем фото и на выходе получаем слой «Небо», слой «Человек», и т.д., чем больше найдет и выделит — тем круче.

Согласнен что микросервисы ТРЕБУЮТ слабой связанности, что хорошо для управояемости. Для управлением слабой связанностью внутри монолита есть сборки, инкапсуляция, средства ЯП и огромное количество паттернов на выбор (конечно же IOC рулит). Т.е. разработчик в проекте с монолитом не должен работать со всеми модулями, у него и в монолите достаточно изоляции и средств её поддерживать. Если архитектор дисциплинирован то сложность моделей можно удерживать на тех же Ваших условных 2-3 единицах, не переходя на микросервисы.

"Размен экспонициалтной сложности?" По-моему не тем Вы зананимались 5 лет, и зря стесняетесь задавать вопросы. Готов утверждать что микросервисы имеют большую асимптотическую оценку сложности разработки. Может конечно не степенную но коэфициент при том же значении будет выше чем у монолита. Автор это затронул в части сложности отладки. Умножте на версионность модулей (разные версии на боевых и тестовых средах) и невозможность статического анализа кода всего решения и вот Вам повышенная(!) сложность разработки.

там 5к+ разработчиков. При команде в 100-200 от такой свободы одни минусы
Друг работал у Вас. Описывал подход как анархия команд и лапша технологий. Например, в проекте было два или три различных ORM и EF использовался для двух сущностей, вроде.
При этом отдаю должное, что проект таки работает.
Это слайд про другое. А именно, это реклама LGPR перед другими способами определения КООРДИНАТ автомобиля. Тут ни чего о том, как автомобиль определяет дорожную обстановку.
Так, а можете объяснить, почему просто коды Хаффмана для кодировки интервалов хуже?
У Вас есть частотность интервалов, дальше их закодировать Хаффманом. Ну и делать отсечки каждые N элементов для более простой расшифровки.
Вроде должен давать теоретический минимум в хранении.
Это распространенный миф. Предлагаю найти исследования.
Сам живу в серьезной компании. Думаю, по описанному сценарию мы бы ничего не отловили. По крайней мере сразу. Только с логов view у клиентов, и то, если бы они сами к нам обратились с проблемой. А сами не поймали бы, т.к. у нас все интеграционные тесты запускаются на машинах с локальных адресов или по локальному имени машины, что легко отследить и проверить. Т.е. те кто пишут, что найдет СБ или мы сами тестами — ребята, по-моему вы оптимисты.
На мой взгляд — там многие головоломки скучноваты и однообразны.
Атмосфера — да. Есть некоторые крутые находки — да. Но ведь мы же ожидали что-то круче Braid!
Вопрос: есть ли в Tarantool какие то алгоритмы сжатия в памяти данных в связи с тем, что как правило БД всегда хорошо сжимаются? Если нет, то есть ли идеи такой разработки?
Меня смущает использование сущности задач (issue) в жире для ведения списка пользователей.

Что то не пойму, что за «СУБД Atlassian JIRA»? Это вы, что ли, в жире подобавляли пользовательских полей и стали ее использовать для списка сотрудников?!!! При том, что в конфлюенсе можно было использовать любой SQL источник?

Но зачем?!!!
Нет, принцип будет нарушен. После постановки ферзя на 20-м ходу его нельзя съесть этим же принципом, и уже нельзя получить цунгцванг для мата. Поставте позицию к 20му ходу, и вместо хода королем поставте ферзя и попробуйте его забрать после этого на любом ходу.
По моему на 20 ходу черные ставят ферзя вместо отступления и будет ничья.
Хм, так вроде postsharp на Interceptor и сделан? В его функциональности чего то не хватает, или просто нет желания платную библиотеку в код добавлять?
Эрик Липтер сравнивал dynamic с раковой опухолью языка. Думал, вы больше по нему пройдетесь.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Registered
Activity