Всегда когда можно придумать property-based тест. Типичные примеры — валидация, сериализация/десериализация, сжатие, шифрование. Но при желании можно найти применение и в других областях. Так например проперти бейзед тестами доказывают корректность распределенных алгоритмов. Находят инвариант который всегда должен выполняться. И потом пишут тест в стиле — неважно что происходит с системой, для любой последовательности событий этот инвариант держится. Почему лучше обычных тестов — кода меньше, самих тестов в сотни раз больше. Больше покрытие, больше багов ловится, больше КПД программиста. Часто проверяются такие граничные случаи о которых программист и не подумал бы при написании теста вручную. Например что если передать на вход методу в качестве double значение NaN или + бесконечность и такого рода вещи.
Testing in Scala хороша. Я бы еще обязательно добавил к ней ScalaCheck: The Definitive Guide. ScalaCheck — реально мощнейший и очень простой в использовании инструмент, который очень легко интегрируется в ScalaTest. Грех им не пользоваться.
Спасибо за интересную статью. Но мне кажется, что тема использования всей мощи ScalaTest в ней не до конца раскрыта. С вашего позволения я рискну дополнить статью парой ссылок для заинтересованных читателей. По первой детально описывается DSL ScalaTest, по второй рассматривается вопрос написания с его помощью property based тестов.
Спасибо большое за статью. Прочитал по диагонали и, как мне кажется, кое-что было упущено. С вашего позволения, оставлю ссылку на свою версию сравнения PostgreSQL и MySQL, и оставить небольшое дополнение.
На мой взгляд, эти РСУБД сильно отличаются по функционалу. Например, PostgreSQL поддерживает курсоры и функциональные индексы, что потенциально позволяет более эффективно использовать СУБД. С другой стороны, в MySQL/MariaDB из одной и той же БД можно реплицировать разные таблицы на разные реплики, и, если я правильно помню, чуть ли не столбцы одной таблицы на разные реплики, что делает MySQL/MariaDB потенциально более масштабируемой. Плюс в PostgreSQL upsert появится только в версии 9.5 (которая вроде еще не до конца вышла), плюс есть недостатки в плане усложненной схемы database, schema, table, плюс MySQL/MariaDB реально знает больше людей.
Такой немного глупый вопрос, если позволите. Имеет ли смысл тратить 5-10 лет своей жизни на такое скучное занятие, чтобы начать этим что-то зарабатывать? Не лучше ли посветить это время более интересному и стабильному занятию?
В прошлом году конференция показалась мне скучной и совершенно точно не стоящей своих денег. Запомнился разве что доклад по LSM trees.
Как мне кажется, главная проблема HL++ — что из года в год с докладами выступают одни и те же люди из одних и тех же компаний. Зачастую с теме же докладами. Это только первый раз интересно. Ну может два, так как потоков несколько. А потом — ну понятно, Лапшин опять пиарит Erlang, ребята из MongoDB делают вид, что она классная и не теряет данные, Tarantool развивается, в Badoo все классно. По моему мнению, бесплатные митапы, которые почти не рекламируются и регулярно проводятся в офисе того же Яндекса, в десятки раз интереснее.
Мой совет организаторам — старайтесь звать больше новых людей.
Спасибо за перевод. Самая большая проблема RethinkDB на данный момент — это отсутствие драйверов. Официальные драйверы есть только для JS, Ruby и Python. То есть даже для JVM нет. А неофициальные драйверы, увы, в очень запущенном состоянии.
Позвольте поинтересоваться, в чем же по вашему мнению заключается грамотность? Времени сэкономлено не было, так как посмотреть через YourKit, под что же используется память, и оптимизировать соответствующее место заняло бы явно меньше времени, чем изучение нового языка и переписывание на нем части системы. Не говоря уже о том, что в проекте теперь используется не один язык, а два, с необходимостью поддерживать клиентские библиотеки к разным сервисам на обоих. Не говоря уже о том, что такой подход — ни в чем не разбираться, а просто переписывать — в принципе неправильный. То есть, в следующий раз, когда что-то пойдет не так, автор статьи снова все с нуля перепишет?
Думается, что «хм, жрется много памяти, давайте все перепишем на X» — реакция скорее какого-то зеленого студента, а не «человека старой закалки». Вместо того, чтобы разобраться в проблеме и прокачать владение технологией, человек потянул в проект новую модную игрушку. Ну и конечно же его эксперимент нельзя повторить. Я не то, чтобы большой противник Go или фанат Java. И наверное это здорово, если язык и вправду позволяет получить более эффективный в плане потребления памяти код без необходимости ни в чем разбираться. Но следует отметить опасность, которую такие посты предоставляют для молодых и впечатлительных разработчиков.
Буквально сегодня делился в бложике своими мыслями по той же теме. В двух словах — если я что-то и понял, работая с микросервисами (последних года три), это следующее. Если нет вот прямо сейчас вполне конкретной проблемы, которую можно решить только путем распиливания на сервисы, то не нужно ничего ни на что распиливать, потому что это модно или потому что потом пригодится. Если проблемы нет или можно решить ее без помощи сервисов, лучше ничего не распиливать.
Только наверняка не предусмотрели в нем обратную совместимость при добавлении полей, возможность когда-нибудь удалить поля, которые стали ненужными, не сделали кодогенераторов для кучи других языков, и как любой велосипед получили нечто ни с чем не совместимое, с чем никто не знаком, и с кучей багов которые еще предстоит найти.
Большое спасибо за интересную статью! Пользуясь случаем хотелось бы оставить для заинтересованных читателей ссылку на серию из трех статей об Akka Cluster.
Также, если позволите, несколько вопросов:
Как вы решили проблему обратной совместимости сообщений между разными версиями приложения и Akka?
Kryo или не Kryo? Kamon или не Kamon?
Не в облаках ли вы хоститесь? Не возникает ли у вас проблемы, что кластер время от времени разваливается и нужно поднимать его руками? В AWS такое иногда случается.
При падении одной машины остальной кластер детектит это не сразу. В результате акторы продолжают долбиться на упавшую машину, получать ask timeout'ы, вот это все. Из-за падения одной машины страдает весь кластер. Как вы с этим живете?
Я когда читал у меня самого возникло чувство, что речь обо мне. Но на самом деле не сходится. Я на Perl за деньги писал три года назад и тогда подкаста не было, о блоге никто не слышал, да и ФП, насколько помню, я вроде бы не особо расхваливал, сам только разбирался во всем. Есть подозрения, что образ, описанный господином platoff является собирательным. Или нет? ;)
Обожаю статьи о практическом опыте разработки приложений. Спасибо и с нетерпением жду продолжения! Особенно интересно было бы почитать про архитектуру серверной части (имеется ввиду БД, кэширование, репликация, фейловеры, монитроинг, где хоститесь — вот это все) и как вы делали такой крутой UI. Здесь и тут для примера список вопросов, ответы на которые было бы особенно интересно получить :)
Спасибо за статью. Если позволите, пара моих постов по связанной теме: раз, два, три, четыре и далее по ссылкам.
По своему опыту скажу, что для написания REST'ов и микросервисов Haskell просто отлично подходит уже сегодня. Можно еще прикрутить blaze-html и писать веб спокойно.
На мой взгляд, эти РСУБД сильно отличаются по функционалу. Например, PostgreSQL поддерживает курсоры и функциональные индексы, что потенциально позволяет более эффективно использовать СУБД. С другой стороны, в MySQL/MariaDB из одной и той же БД можно реплицировать разные таблицы на разные реплики, и, если я правильно помню, чуть ли не столбцы одной таблицы на разные реплики, что делает MySQL/MariaDB потенциально более масштабируемой. Плюс в PostgreSQL upsert появится только в версии 9.5 (которая вроде еще не до конца вышла), плюс есть недостатки в плане усложненной схемы database, schema, table, плюс MySQL/MariaDB реально знает больше людей.
Как мне кажется, главная проблема HL++ — что из года в год с докладами выступают одни и те же люди из одних и тех же компаний. Зачастую с теме же докладами. Это только первый раз интересно. Ну может два, так как потоков несколько. А потом — ну понятно, Лапшин опять пиарит Erlang, ребята из MongoDB делают вид, что она классная и не теряет данные, Tarantool развивается, в Badoo все классно. По моему мнению, бесплатные митапы, которые почти не рекламируются и регулярно проводятся в офисе того же Яндекса, в десятки раз интереснее.
Мой совет организаторам — старайтесь звать больше новых людей.
Буквально сегодня делился в бложике своими мыслями по той же теме. В двух словах — если я что-то и понял, работая с микросервисами (последних года три), это следующее. Если нет вот прямо сейчас вполне конкретной проблемы, которую можно решить только путем распиливания на сервисы, то не нужно ничего ни на что распиливать, потому что это модно или потому что потом пригодится. Если проблемы нет или можно решить ее без помощи сервисов, лучше ничего не распиливать.
Также, если позволите, несколько вопросов:
По своему опыту скажу, что для написания REST'ов и микросервисов Haskell просто отлично подходит уже сегодня. Можно еще прикрутить blaze-html и писать веб спокойно.