Pull to refresh
125
3.1
Александр Рябиков @rsashka

Системный архитектор

Send message

Привязать карту для оплаты можно хоть в мобильном приложении, хоть в обычной веб версии.
И не знаю как у вас, а я трачу гораздо больше времени на поиск товара и сравнение предложений нескольких продавцов, чем на непосредственную оплату покупки.

Понимаю, что аргумент "И чо?" довольно универсальный :-)
Я вам привел мнение, полностью противоположное вашим восторженным выводам. Что принципиальные алгоритмы работы нейросетей были известные еще в 50-е годы, а их успех обоснован наличием большого объема данных для обучения и громадными вычислительными мощностями. Но все это не говорит о том, что в этих нейросетях зародился искусственный интеллект.

Почитайте эту статью вики в англоязычном варианте:

The sudden success of deep learning in 2012–2015 did not occur because of some new discovery or theoretical breakthrough (deep neural networks and backpropagation had been described by many people, as far back as the 1950s)[i] but because of two factors: the incredible increase in computer power (including the hundred-fold increase in speed by switching to GPUs) and the availability of vast amounts of training data, especially the giant curated datasets used for benchmark testing, such as ImageNet.

А как вы видите адресную атаку на конкретного человека?

Предположим тут (на Хабре) половина комментариев генерируется для персонального человека с целью, ну незнаю, изменить его точку зрения. Но это будет работать, если видимость комментариев будет индивидуальна для атакуемого пользователя (одному показывают один комментарий, другому - другой комментарий).

Но пользователь получает информацию не только в тут, но и в других местах, и в этом случае будет нужно таргетировать фейки и пропаганду. Хотя знаете, в принципе это действительно будет возможно в случае повальной обязательной идентификации пользователей в интернете :-)

Качество распознавание голоса два-три десятилетия назад тоже было на уровне 70-80%, а в некоторых случаях даже 90%. Но реальное применение подобных программ было очень узкоспециализированным, так как неправильно работающие 10-20% напрочь нивелировали все подобные достижения. И потребовался дополнительных фактор в виде нейронных сетей, чтобы запустить распознавание голоса в массы.

И текущая ситуация с успехами в создании нейронных сетей, связана не с появлением в этих нейросетях искусственного интеллекта (как твердят журналисты, изнасиловавшие ученых), а в больших вычислительных мощностях, позволивших им скормить громадные объемы данных.

Это стало поставленным на поток с момента появления радио, а потом и телевидения.
Не знаю, как насчет эффективности, но насчет массовости соглашусь и даже Хабр не избежал подобной участи :-(

и распространяющие всякую недостоверную информацию, фейки, ложь и клевету

ИИ то тут причем? Как будто раньше этого не было :-)

Жаль только — жить в эту пору прекрасную Уж не придется — ни мне, ни тебе.

:-)

Ну, насчет этого, мне кажется, тоже переживать не стоит, так как развитие циклично :-)

Трудные времена рождают сильных людей. Сильные люди создают хорошие времена. Хорошие времена рождают слабых людей. Слабые люди создают трудные времена ...

А мне кажется этого не случится по очень простой причине. Деградация большинства не влияет на развитие самой цивилизации, так как для ее развития достаточно всего либо небольшой группы увлечённых людей, а порой хватает даже одного человека, чтобы перевернуть представление о мире (даже если это и не происходит мгновенно).

Я, например, из мобильного не покупал ничего, кроме заказа такси, все остальное только с десктопа. И точно так же думаю, что таких людей больше одно.

У изоляции нет уровней

Я писал про уровень изоляции для иерархии классов приложения. Например при нисходящем тестировании (когда вызывается интерфейс высокого уровня, а реализация нижележащих классов постепенно заменяется с MOCK реальную).

Если вы одновременно тестируете два или более "юнитов", то на мой взгляд это уже интеграционные тесты.

GTF тесты можно запустить хоть все стразу, хоть по отдельности, и это точно не интеграционные тесты, так как все "юниты" должны быть изолированы. Хотя отдельные тесты действительно можно назвать интеграционными, если внутри используются не mock объекты, а другие модули.

Но как я уже писал, в данном случае терминология не принципиальна и может зависеть как от конкретного проекта, так и от принятых соглашений (например, в моей практике был случай, когда приемочными и функциональными тестами были юнит-тесты на GTF, когда разрабатывалась низкоуровневая библиотека, а заказчиком выступал другой проект).

Какие "описаннве мною тесты" вы имеете в виду?

Тесты отдельного метода или класса, написанные разработчиком с использованием mock объектов.

Я тоже пишу в том числе и для десктоп приложения и практически все тесты у меня на google test framework. И там есть тесты и с моками, а есть и без них. Просто уровень изоляции может быть разный. Для одного теста обязательно нужен mock (чтобы можно было локализовать ошибку), а для теста более высокого уровня mock может и не потребоваться.

И если честно я не даже не знаю как их можно назвать, ведь ни к функциональным, ни к приемочным тестам их отнести не получится, так как я не смогу их предъявить заказчику, т.к. они выполняются на отдельной сборке, а не на законченном приложении.

Функциональные тесты, это подтверждение работы конкретной функциональности согласно ТЗ или беклогу.

Приемочное тестирование, это тестирование функциональность продукта методом «чёрного ящика» на соответствие заданным критериям.

Описанные вами тесты не соответствуют ни одному их этих определений.

Но от этого такие тесты не становятся юнит-тестами.

А как тогда вы их называете?

Если БД для каждого теста создаётся заново или каждый раз "ресетается" до одного и того же состояния, то это ещё можно считать юнит-тестом.

Да, примерно это и имеется ввиду.

Потому что у вас появляется дополнительная сущность которую вы тестируете. И если тест выдаёт ошибку, то вы не знаете является ли причиной ошибки ваш "функционал" или содержание вашей SQLLite.

Конечно, название типов тестирования, это больше вопрос терминологии и соглашений конкретного проекта, хотя мне больше всего нравится считать, что юнит тесты, это тесты отдельной сущности, которые может запустить разработчик на своем компьютере автономно, тогда как интеграционные тесты, это область ответственности тестировщиков с подготовкой правильного окружения.

И в первом случае могут быть как моки вместо БД, так и непосредственное использование встроенной БД, так и оба варианта тестов одновременно (и с моками и без них). И какой тест запускать, это зависит от решаемой разработчиком задачи. Например, для регрессионного тестирования достаточно сразу запускать тесты со встроенной БД, т.к. требуется только подтверждение работоспособности, а не локализация ошибки.

Юнит-тест, это небольшой тест функциональности без необходимости запускать всю системы целиком.

Делать внутри юнит-теста моки или нет, зависит от объема и локализации зависимостей. Например, если для тестов нужно поднимать сервер БД, тогда логично заменить его на мок, а если в проекте используется SQLLite, то в некоторых тестах его можно и не мокать.

Там засвечивают глаза пилотов, а не камеры.

Или публикацию исходников... Вроде на русском языке все написал...

Вы уже успели забыть, что сами же и написали комментарием выше? "Но все же интересно, а хотя бы чтото вы отдали назад в комьюнити, части кода улучшающие оригинальный проект?"

Да, да и вам удачи

А вы ни о чем не спрашивали, а сразу кинули топикастеру непонятную предьяву как раз из-за собственного непонимания ограничений у разных типов свободный лицензий.

Потрудитесь хотя бы для собственного образования выяснить, в каких случаях у создателя производного продукта под свободной лицензией возникают обязанности в публикации исходников.

Information

Rating
933-rd
Location
Россия
Works in
Date of birth
Registered
Activity

Specialization

Embedded Software Engineer, Software Architect
Lead
C++
OOP
Linux
Programming microcontrollers
Embedded system
C
Qt
Software development