однако

http://www.bards.ru/archives/part.php?id=35003

Кстати, философский вопрос: Как определить нормальная или ненормальная контора?

Пообщаться с работниками местными

по отзывам знакомых сотрудников

Если дерганые или онлайн на работе в выходные, то это звоночек )

надо делать аналог market.yandex.ru с отзывами о компаниях )

бесполезно

будут накрутки рейтингов?

будут ботов плоидить и накручивать, конкруентов валить, заставялть сотрудников хорошие отзывы писать...

как на маркете

Есть какой-то сервис англоязычный с анонимными отзывами сотрудников.

блина. всё тлен

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

> анонимными отзывами сотрудников лучше всего работает в компаниях до 10 человек ?

https://www.glassdoor.co.uk/

Вот здесь такое было

Маленьких компаний, правда помойму наоборот нет

Но был какой-то другой сервис

https://www.kununu.com/

А кажется вот он

Ищем backend разработчиков с навыками в • Kubernetes • Docker

А там нужны особые навыки?

наверно, т.к. devops-ить будешь ты

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

куб вроде с докером сейчас хочет порвать дружбу. они какой-то свой докер теперь пилят

будут ботов плоидить и накручивать, конкруентов валить, заставялть сотрудников хорошие отзывы писать...

никакого рейтинга

вместо всех отзывов показывать 2 рандомных

один положительный один отрицателньый

Неужели %{from: %User{first_name: name}} выглядит лучше чем %{from: %{first_name: name}}

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

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

В качестве примера того, как по моему мнению должна вестись разработка бота можно привести Buckler ;)

Последнюю ветку мы даже причесали

https://github.com/BucklerBot/buckler/tree/adding-attempts?files=1

я даже тесты на эту ветку написал

но я вам их не покажу (с) Печкин

потому что у нас документов нет?

В качестве примера того, как по моему мнению должна вестись разработка бота можно привести Buckler ;)

о, гляну

спасибо

потому что у нас документов нет?

йеп

Вопрос на миллион - кто как тестирует handle_cast\info методы у GenServer’ов?

Вопрос на миллион - кто как тестирует handle_cast\info методы у GenServer’ов?

2 варика - либо тестируем генсервер интеграционно как апи либо как чистую функцию

Но юнит я считаю плохой практикой

Через внешний интерфейс. Все GenServer.call обычно находятся в том же модуле и экспортируют, к примеру def put(a, b), do: GenServer.call(....) его и тестирую.

Тестировать внутренности имплементации не очень хорошо, как помойму.

ну а если логику из них перенести в модули, модули мокать чтобы при запуске теста они подменялись?

В плане cast и info - тоже самое.

тогда можно тестить логику отдельно ну и работу genserver отдельно

можно при старте GenServer отдавать ему модули с которыми он работает, и при тестовом запуске также передавать ему моки

ну а если логику из них перенести в модули, модули мокать чтобы при запуске теста они подменялись?

мокать в эликсире не тру жи…но вообще так и сделал, конечно - бизнес логика отдельно но это не отменяет того, что в cast проихсодят 2-3 строчки на матчинг результата модуля, и хорошо бы из тоже оттестить…

можно при старте GenServer отдавать ему модули с которыми он работает, и при тестовом запуске также передавать ему моки

вот это не плохо, да

как я понял не тру - мокать рабочие модули(?), а если у каждого модуля определять behaviour и в моках его реализовывать то это вроде норм http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-contracts/

aa, я не так понял значит тебя - я везде так делаю на границах системы, да, через Mock модули

прост не подумал что с генверсерами так же можно намутить

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

по идее можно в генсервере вообще сделать по одному методу def handle_call(request, from, state), do: MyModule.call(request, from, state) def handle_cast(request, state), do: MyModule.cast(request, state) def handle_info(msg, state), do: MyModule.info(msg, state) и весь мачинг перенести в MyModule MyModule.call(:request_1, from, state) MyModule.call(:request_2, from, state) и тд тогда, по идее генсервер вообще можно и не тестить а тестить только MyModule

чет я такого не видел примера использования)

ну надо же кому то начинать )))

По идее - можно как угодно извращаться ? Но лучше всего, когда при использовании GenServer-а есть у него публичное API, которым пользуются и его и тестировать. И не тестировать внутренности и не мокать внутренности.

Если конечно речь не о коммуникации со сторонним удаленным сервисом.

Но здесь тогда мок всего генсервера, просто другой процесс или модуль.

по идее можно в генсервере вообще сделать по одному методу def handle_call(request, from, state), do: MyModule.call(request, from, state) def handle_cast(request, state), do: MyModule.cast(request, state) def handle_info(msg, state), do: MyModule.info(msg, state) и весь мачинг перенести в MyModule MyModule.call(:request_1, from, state) MyModule.call(:request_2, from, state) и тд тогда, по идее генсервер вообще можно и не тестить а тестить только MyModule

Вообще-то для этого придуман параметр в функции GenServer.start_link

какой?

module

Можно сделать GenServer в двух разных файлах

и что в них будет?

Ну в общем то в одном будет АПИ, а в другом - только хэндлы

Т.е. defmodule MyServerApi do def start_link(...) GenServer.start_link(MyServerCallbacks, ...) end def foo(pid), do: GenServer.call(pid, :foo) end defmodule MyServerCallbacks do use GenServer def handle_call(:foo, from, state), ... end

А обычно все пишут GenServer.start_link(__MODULE__, ...)

Ну и конечно можно этот module параметр замокать на этапе любом

Но лучше компиляции

Через Application.get_env(:my_genserver_implimentation)

а ну вот мозг и зашорился. так вот и надо делать тут можно MyServerCallbacks перетестить вдоль и поперек

Можно, но не нужно

Потому что в otp app генсервер - это смысловая единица

И тестить надо только MyServerApi

а генсервер это что? Модуль?

Генсервер? Смысловая единица

а что это такое?

Архитектурная единица

Если так проще

Детали реализации не важны с архитектурной точки зрения

а с точки зрения парадигмы функционального программирования?

С точки зрения функционального программирования ГенСервер - это конечно же функция

В базовом смысле - получил вопрос - отдал ответ

Может не отдать

Тогда это какая-то там монада

Хотя я наврал

Он хранит состояние, значит он и сам монада какая-то

Но это не так важно Ж)

нет монад

просто если писать генсервер так как ты написал то тестить можно только MyServerCallbacks

причем тесты могут быть асинхронными

Ну если в тесте ты напишешь MyServerApi.foo

а апи нефиг вообще тестить... чет там тестить то?

То ты его и протестишь

не не... я напишу MyServerCallbacks.foo1 MyServerCallbacks.foo2 и запущу тесты сразу в двух потоках. независимо

А он под капотом вызовет MyServerCallbacks