Все так, GFN.ru так же сделала свой сервис бесплатным, но на бесплатном тарифе есть ограничение игровой сессии (вроде 1 час). А так же если наплыв людей большой, придется подождать в очереди :)
Хм, я бы хотел подискутировать об особенных условиях жизни на Земле. Так как в последнее время начал много думать и читать по этой теме. И у меня складывается впечатление, что никаких тепличных условий текущей Земли для зарождения жизни были не нужны. Предполагаемые следы первой жизни находят все в более и более глубоких слоях, уже на границе той эпохи от которой вообще никаких геологических следов не осталось. Плюс кирпичики жизни (сложная органика) которые находят на кометах и метеоритах. Вещества из которых мы состоим очень распространены в космосе.
Влияние активности правого или левого полушария на способности человека на сегодняшний момент считается мифом.
А нейропластичность мозга подразумевает, что мозг можно «перековать», к примеру в математический, в любом возрасте. Было бы желание и упорство.
задач для нейросетей, одна распознает объекты на экране, вторая, натренированая на стиль Фентези рассказов, генерит текст по распознанным объектам на картинке)
Интеллектуальная активность, в том числе увлечение игрой в шахматы, и регулярное общение коррелируют со сниженным риском развития болезни Альцгеймера, по данным эпидемиологических исследований, однако причинно-следственная связь пока не доказана.
У тестирования на настоящей базе есть другие недостатки, кроме создания и поддержки скриптов инициализации минимального набора данных.
Unit тесты можно прогнать любой разработчик сразу, локально и быстро. Для прогона интеграционных тестов, как правило, надо поплясать с настройками локального окружения разработчика.
Написание нового интеграционного теста может занимать больше времени, чем любого unit теста, из за возни с предварительной настройкой окружения. И сами тесты могу проходить далеко не быстро, а значит их скорее всего не будут запускать локально вообще или не будут запускать часто.
Они могут падать по причине не связанной с самим тестируемым кодом (были проблемы с соединением с базой, кэшом в redis), а значит будет меньше реакция на упавший интеграционный тест в CI, чем на упавший unit тест.
Из этого следует, что если какой то метод содержит сложную бизнес логику с множеством кейсов, то писать на каждый такой кейс интеграционный тест не выгодно, так скоро время выполнения всех тестов может перевалить за часы.
Как представляется общая картина, сложную бизнес логику лучше выделить в классы которые можно спокойно покрыть необходимым количеством unit тестов. Общую работоспособность фичи можно проверить несколькими интеграционными тестами. А еще можно использовать end to end тестирование которое проверяет какой то конкретный бизнес кейс включающий в себя новую фичу.
Получается такая пирамида тестов
Более того, по противоречивому и неполному тз!
Как раз читаю его книгу Происхождение жизни.
Такое ощущение, что 95% считают "какие ещё черные дыры, фигней какой то занимаются, лучше бы мне эти деньги отдали".
здесь можно сделать ссылку на книгу "код — тайный язык информатики"
А нейропластичность мозга подразумевает, что мозг можно «перековать», к примеру в математический, в любом возрасте. Было бы желание и упорство.
Правда он платный, хотя бесплатные способные подменять статические и невиртуальные методы я не встречал.
Unit тесты можно прогнать любой разработчик сразу, локально и быстро. Для прогона интеграционных тестов, как правило, надо поплясать с настройками локального окружения разработчика.
Написание нового интеграционного теста может занимать больше времени, чем любого unit теста, из за возни с предварительной настройкой окружения. И сами тесты могу проходить далеко не быстро, а значит их скорее всего не будут запускать локально вообще или не будут запускать часто.
Они могут падать по причине не связанной с самим тестируемым кодом (были проблемы с соединением с базой, кэшом в redis), а значит будет меньше реакция на упавший интеграционный тест в CI, чем на упавший unit тест.
Из этого следует, что если какой то метод содержит сложную бизнес логику с множеством кейсов, то писать на каждый такой кейс интеграционный тест не выгодно, так скоро время выполнения всех тестов может перевалить за часы.
Как представляется общая картина, сложную бизнес логику лучше выделить в классы которые можно спокойно покрыть необходимым количеством unit тестов. Общую работоспособность фичи можно проверить несколькими интеграционными тестами. А еще можно использовать end to end тестирование которое проверяет какой то конкретный бизнес кейс включающий в себя новую фичу.
Получается такая пирамида тестов
И кстати, под это определение прекрасно подходит java, почему не на нее?