Конечно, если у вас проект на три таблицы по пять полей. DTO - небольшой класс к несколькими публичными полями. Entity представляют из себя анимичные модели и все геттеры и сеттеры генерированы автоматичеси. В пректе всего пара сервисов, в которых нет бизнес логики, поскольку они просто прокси между контроллером и репозиторием. То вы правы. Не тратьте время на интеграционные и Unit тесты. Достаточно нескольких функциональных тестов, покрывающих только позитивное флоу.
Всё же предположу, что вы работаете с несколько более крупными проектами.
Почему "если нет DDD, то и юнит тесты писать не нужно"? Контракт - это не только и не столько интерфейс. Это в первую очередь ожидаемый и стабильный результат работы вашего кода. Если ваш код выдаёт стабильный результат работы, на который рассчитываю остальные, значит у вас есть контракт. И не важно как оформлен ваш код. ООП, функциональный стиль или "макароны".
Как вы проверяете, что весь ваш код работает правильно? Конечно, не стоит тестировать код фреймворка. Но как вы гарантируете, что нет банальных опечаток при объявлении сервисов или в анотациях к полям Entity и доктрина всё сохраняет даже в необязательных полях. Добавили новую зависимость в сервис, а контейнер смог его собрать?
Давайте пока остановимся на сервисах. Если вы используете только функциональные тесты. Вы проверяете только позитивный флоу? Как быть с крайними значениями и заведомо некорректными данными? Вы проверяете обработку таких данных? Юнит тесты прекрасно пишутся и на сервисы. Не только на DTO и Entity. Сервису всё равно откуда он получил данные. Из настоящего репозитория или из мока. И куда он их отправит ему тоже всё равно. И Unit тесты здесь подходят как нельзя лучше.
Если вы в тестах работаете с базой (интегационные тесты и функциональные), то тесты проходят гораздо медленнее потому, что данные нужно сперва записать в базу, потом получить. И для идентификации данных не всегда получается использовать поле с индексом. Значит запросы будут работать ещё медленнее.
Теперь представим, что у вас между контроллером и репозиторием не один сервис-прокси (фасад), а несколько сервисов взаимодействующих друг с другом. В реальных проектах их может быть 5, 10 или больше. Кто-то из них в базу сходит за дополнительными данными. Кто-то на API внешнего сервиса. И в каждом своя часть бизнес логики. Сколько наборов тестовых данных вам понадобится, чтобы проверить все варианты их работы? И нужно, чтобы они не конфликтовали в базе данных. Значит понадобится загружать данные в базу, удалять и снова загружать. И я ещё не упомянул работу парам-конвертеров, валидацию входящих данных, валидацию итогового состояния Entity и прочие вспомогательные обработки, которые многие не учитывают.
Даже не хочу представлять в какой кошмар превратится проверка работы одного такого роута.
А Unit тесты вместе с моками позволяют проверить работу каждого сервиса изолированно.
В том числе и об этом идёт речь в статье. Уменьшайте скоуп проверки в каждом отдельном тесте.
Всё классно. Одно не понятно: зачем мешать енота с носорогом? Гораздо лучше будет, если разделить эту статью на две. Одна — про чтение книг. Другая — про "фишки" в программировании.
Могу ошибаться, но это мне напомнило «накручивание счётчика фоловеров». Можно попробовать соотнести эти данные со знаковыми событиями в истории валюты. Возможно выплывет что-то интересное.
1) Ещё бы разным группам разное время для напоминаний. Чтобы не настраивать каждую задачу. Например для рабочих задач с 9 до 18 и дальше хоть трава не расти. И домашние, если надо, чтобы ни одна не вякнула в это время.
2) объединение задач с системой учёта рабочего времени. И все напоминалки туда же. Я, например днём смартфон беру в руки 1-2 раза и все напоминания на нём бесполезны.
Полностью поддерживаю, что разрабы в курсе проблемы, но просто забили на пользователей. Возможно, они так хотели показать большой приток пользователей в приложение, но по факту нарушили все мыслимые правила конфиденциальности.
Добавлю ещё уточнение проблемы. Есть множество номеров, добавляемых временно. На неделю, на месяц. Теперь все они, кого я больше не хочу видеть в списке контактов, начинают появляться в Телегроме. Больше того, ещё и уведомления об этом приходят. Этот реально бесит. Писал в техподдержку месяц назад. Но ни ответа, ни привета.
Было бы интересно когда эти новинки появятся в продаже и насколько будут доступными. Если формат статьи на geektimes не позволяет, буду благодарен если сделаете статью аля «Новинки CES 2017 и когда их можно купить» у себя на сайте и банер наглавную, чтобы не искать долго.
Замечательно, что автор борется за поддержание здоровья. Но вот это…
Получается, что открытие фактически ставит крест на целой отрасли медицины, которая использовала инъекции стволовых клеток и некоторые другие методы для «самовосстановления» тканей коленного сустава.
Скорее является указанием на на незнание мат. части автором, чем констатацией факта.
Прежде, чем писать подобные статьи нужно не только проводить
беглый анализ Wiki
а читать специализированную литературу/статьи.
Но даже если взять эту статью (статья «не очень», но фото показательное) https://ru.wikipedia.org/wiki/Хрящ
На фото «изюм» — это живые клетки хряща. Как видите, их мало и с возрастом они действительно теряют активность. Всё остальное — это «основное вещество» — то, что клетки хряща «насинтезировали» раньше. Более-мене активные клетки есть только в поверхностном слое хряща. Именно они создают новый хрящ. Именно для их здоровья/питания нужна синовиальная жидкость в суставе (сосудов в хряще нет).
Если вы при травме повредили этот слой. Сделать это легко (помним, что это только поверхностный слой), то естественно будут проблемы с восстановлением хряща. Если при этом не принимать «хондропротекторы» (глюкозамин, хондроэтин) — по сути являющиеся строительным материалом хряща, то проблемы будут ещё больше.
При серьёзных травмах, можно попытаться «заселить» этот слой — использовать, например
инъекции стволовых
Иначе, только замена, поскольку «изюма» в более глубоких слоях будет недостаточно для полноценного восстановления хрящей.
И напоследок. Хрящ не болит — в нём нет нервных окончаний. Как и нет сосудов для его полноценного питания. Болит надкостница, расположенная под ним. Например, при трещинах хряща, когда идёт повреждение уже надкостницы.
Увеличение скорости не может не радовать. Но когда я слышу, что переход с параллельного выполнения задач на последовательное — это круто, что-то во мне говорит что здесь что-то не так. Спустя какое-то время, возможно, эти же люди будут говорить: «А вот было же время… Уже тогда умели...». Сколько раз уже такое было. Поправьте, если я ошибаюсь.
Ага. Тоже мне сказанули: «вовсе НЕВАЖНО, кто что думает о модифицировании генома живых организмов, если речь идет о спасении островов и защите природных экосистем, защите эндемиков.» Как только окажется, что участки отредактированного генома передаются людям и, не дай бог, из-за этого заболеют их родственники или они сами… Это сразу же станет очень-очень важным. Да только будет уже поздно, когда джина выпустят из бутылки.
Весь фокус в том, что большинство технологий редактирования геномов основаны на принципе «липких концов». В этом случае новый генетический материал подобен выброшенной жевачке на мостовой или на скамейме. Вот ты гуляешь по парку и совершенно не собираешься подбирать эту дрянь. Ты просто «оказался рядом» и теперь это уже твоя головная боль…
С другой стороны. Дайте им интернет и у них будет больше возможность как самим совершать новые преступления, так и управлять другими людьми, чтобы те совершали новые преступления.
Видимо испугались, что разработчики массово уходят (ушли) на linux. Сейчас по многим вопросам мануалов под винду уже не найти (очень сложно найти). А где разработчики, туда и пользователи подтягиваются. Добровольно или принудительно.
Потому и бьют по одному из главных вопросов: «А как это установить/запустить на винде?»
Тут важно с какой целью задавался вопрос. Если с позиции «взять какой-то новый фреймворк на изучение или продвинуться в текущем»? То можно посмотреть по вакансиям. «Самый-самый» тренд может и не словите, но в качестве прогноза на ближайшие пару лет сойдёт. Без хлеба точно не останешься.
Итак.
Посмотрел сейчас на jobs.tut.by (тот же hh.ru, только для Беларуси)
Из 221-й вакансии, где требуется (упоминается) PHP
[ Фреймфорки ]
В 46-и вакансиях в требованиях упоминается Symfony
В 25-и Yii
В 29-и Zend Framework (возможно немного меньше, если в одном объявлении использованы обе формы: 20 Zend + 9 ZF)
В 19-и Laravel
В 5-и CakePHP
В 4-х CodeIgniter
[ CMS ]
В 33-и Bitrix
В 24-х Magento
В 21-и Drupal
В 17-и Joomls
В 17-и WordPress
Из подсчёта выкинуты Маркетологи, SEO-специалисты и пр. В одном и том же объявлении может быть упомянуто несколько фреймворков/CMS. Но общее представление можно составить.
Ещё можно воспользоваться wordstat.yandex.ru и посмотреть количество запросов (уровень проявленного интереса) и, возможно, динамику его изменения.
По одному никто не определяет. Определяют процент по выборке с определённой долей вероятности. Т.е. у определённого курильщика рак может быть совершенно из-за другого фактора, а не из-за курива. Точно так же как при опросе долгожителей кто-то из них может заявить, что всю жизнь пил (бухал) и поэтому столько прожил. Если же капнуть поглубже, то выходит, что он прожил не «благодаря», а «вопреки». Так же и скуривом. Может так сложиться, что кто-то проживёт лет на 10-20 дольше как-раз из-за курива, так как никотин может убить анкологическую клетку вместо здоровой (ну что ты сделаешь, коли бес попутал). Но в целом выходит так, что куриво убивает.
О! 30% бюджета — действительно большой кусок пирога, чтобы за него побороться. Главное, чтобы не получилось как с сиднейским оперным театром. Для справки: стоимость постройки оказалась 102 млн (против 7-и запланированных — в ~14 раз больше), строили на ~10 лет дольше (в ~2 раза дольше), при том, что проект ещё и сократили.
Конечно «собрал и потопал» — рассеивание энергии это круто, если, во-первых, собрал всё и ничего не потерялось, во-вторых, ничего не утонуло в какой-нибудь соседней луже.
Спасибо. Посмотрю
Конечно, если у вас проект на три таблицы по пять полей. DTO - небольшой класс к несколькими публичными полями. Entity представляют из себя анимичные модели и все геттеры и сеттеры генерированы автоматичеси. В пректе всего пара сервисов, в которых нет бизнес логики, поскольку они просто прокси между контроллером и репозиторием. То вы правы. Не тратьте время на интеграционные и Unit тесты. Достаточно нескольких функциональных тестов, покрывающих только позитивное флоу.
Всё же предположу, что вы работаете с несколько более крупными проектами.
Почему "если нет DDD, то и юнит тесты писать не нужно"? Контракт - это не только и не столько интерфейс. Это в первую очередь ожидаемый и стабильный результат работы вашего кода. Если ваш код выдаёт стабильный результат работы, на который рассчитываю остальные, значит у вас есть контракт. И не важно как оформлен ваш код. ООП, функциональный стиль или "макароны".
Как вы проверяете, что весь ваш код работает правильно? Конечно, не стоит тестировать код фреймворка. Но как вы гарантируете, что нет банальных опечаток при объявлении сервисов или в анотациях к полям Entity и доктрина всё сохраняет даже в необязательных полях. Добавили новую зависимость в сервис, а контейнер смог его собрать?
Давайте пока остановимся на сервисах. Если вы используете только функциональные тесты. Вы проверяете только позитивный флоу? Как быть с крайними значениями и заведомо некорректными данными? Вы проверяете обработку таких данных? Юнит тесты прекрасно пишутся и на сервисы. Не только на DTO и Entity. Сервису всё равно откуда он получил данные. Из настоящего репозитория или из мока. И куда он их отправит ему тоже всё равно. И Unit тесты здесь подходят как нельзя лучше.
Если вы в тестах работаете с базой (интегационные тесты и функциональные), то тесты проходят гораздо медленнее потому, что данные нужно сперва записать в базу, потом получить. И для идентификации данных не всегда получается использовать поле с индексом. Значит запросы будут работать ещё медленнее.
Теперь представим, что у вас между контроллером и репозиторием не один сервис-прокси (фасад), а несколько сервисов взаимодействующих друг с другом. В реальных проектах их может быть 5, 10 или больше. Кто-то из них в базу сходит за дополнительными данными. Кто-то на API внешнего сервиса. И в каждом своя часть бизнес логики. Сколько наборов тестовых данных вам понадобится, чтобы проверить все варианты их работы? И нужно, чтобы они не конфликтовали в базе данных. Значит понадобится загружать данные в базу, удалять и снова загружать. И я ещё не упомянул работу парам-конвертеров, валидацию входящих данных, валидацию итогового состояния Entity и прочие вспомогательные обработки, которые многие не учитывают.
Даже не хочу представлять в какой кошмар превратится проверка работы одного такого роута.
А Unit тесты вместе с моками позволяют проверить работу каждого сервиса изолированно.
В том числе и об этом идёт речь в статье. Уменьшайте скоуп проверки в каждом отдельном тесте.
Всё классно. Одно не понятно: зачем мешать енота с носорогом? Гораздо лучше будет, если разделить эту статью на две. Одна — про чтение книг. Другая — про "фишки" в программировании.
2) объединение задач с системой учёта рабочего времени. И все напоминалки туда же. Я, например днём смартфон беру в руки 1-2 раза и все напоминания на нём бесполезны.
Полностью поддерживаю, что разрабы в курсе проблемы, но просто забили на пользователей. Возможно, они так хотели показать большой приток пользователей в приложение, но по факту нарушили все мыслимые правила конфиденциальности.
Добавлю ещё уточнение проблемы. Есть множество номеров, добавляемых временно. На неделю, на месяц. Теперь все они, кого я больше не хочу видеть в списке контактов, начинают появляться в Телегроме. Больше того, ещё и уведомления об этом приходят. Этот реально бесит. Писал в техподдержку месяц назад. Но ни ответа, ни привета.
Могу помочь за так (по фану) через недельку. Пишите в личку
Скорее является указанием на на незнание мат. части автором, чем констатацией факта.
Прежде, чем писать подобные статьи нужно не только проводить
а читать специализированную литературу/статьи.
Но даже если взять эту статью (статья «не очень», но фото показательное) https://ru.wikipedia.org/wiki/Хрящ
На фото «изюм» — это живые клетки хряща. Как видите, их мало и с возрастом они действительно теряют активность. Всё остальное — это «основное вещество» — то, что клетки хряща «насинтезировали» раньше. Более-мене активные клетки есть только в поверхностном слое хряща. Именно они создают новый хрящ. Именно для их здоровья/питания нужна синовиальная жидкость в суставе (сосудов в хряще нет).
Если вы при травме повредили этот слой. Сделать это легко (помним, что это только поверхностный слой), то естественно будут проблемы с восстановлением хряща. Если при этом не принимать «хондропротекторы» (глюкозамин, хондроэтин) — по сути являющиеся строительным материалом хряща, то проблемы будут ещё больше.
При серьёзных травмах, можно попытаться «заселить» этот слой — использовать, например
Иначе, только замена, поскольку «изюма» в более глубоких слоях будет недостаточно для полноценного восстановления хрящей.
И напоследок. Хрящ не болит — в нём нет нервных окончаний. Как и нет сосудов для его полноценного питания. Болит надкостница, расположенная под ним. Например, при трещинах хряща, когда идёт повреждение уже надкостницы.
Весь фокус в том, что большинство технологий редактирования геномов основаны на принципе «липких концов». В этом случае новый генетический материал подобен выброшенной жевачке на мостовой или на скамейме. Вот ты гуляешь по парку и совершенно не собираешься подбирать эту дрянь. Ты просто «оказался рядом» и теперь это уже твоя головная боль…
Потому и бьют по одному из главных вопросов: «А как это установить/запустить на винде?»
Итак.
Посмотрел сейчас на jobs.tut.by (тот же hh.ru, только для Беларуси)
Из 221-й вакансии, где требуется (упоминается) PHP
[ Фреймфорки ]
В 46-и вакансиях в требованиях упоминается Symfony
В 25-и Yii
В 29-и Zend Framework (возможно немного меньше, если в одном объявлении использованы обе формы: 20 Zend + 9 ZF)
В 19-и Laravel
В 5-и CakePHP
В 4-х CodeIgniter
[ CMS ]
В 33-и Bitrix
В 24-х Magento
В 21-и Drupal
В 17-и Joomls
В 17-и WordPress
Из подсчёта выкинуты Маркетологи, SEO-специалисты и пр. В одном и том же объявлении может быть упомянуто несколько фреймворков/CMS. Но общее представление можно составить.
Ещё можно воспользоваться wordstat.yandex.ru и посмотреть количество запросов (уровень проявленного интереса) и, возможно, динамику его изменения.