А методы которые дергаем соответственно тестирует отдельно, в них как правило какая-то бизнес логика или трансформации может быть задействована.
Если БЛ нет, то есть смысл посмотреть на тестирование с помощью снимков (snapshots), перед коммитом ты записываешь данные, которые пришли из БД, третьих сервисов в third_party.json к примеру, и записываешь результат который отдал твой метод контроллера в отдельный response.json, - все это коммитишь. На staging в тесты подсовываются суррогатные данные из твоих third_party.json вместо вызовов реальных сервисов, прогоняются через логику контроллера и сравниваются с response.json. Соответственно если разработчик меняет логику или взаимодействие, то он должен перезаснять снапшоты.
если больше по части программирования, то корректность подкрепляется набором тестов
если по части компьютер сайнс, то посмотри на язык Coq для доказательства теорем, часто используется в длинных выкладках и сильно снижает риск ошибок, которые так легко допустить на бумаге
для доказательств и практики в этом существует огромный раздел, так и называется теория доказательств
ссылки даю на Вики, чтобы максимально просто было описано, если будет желание дальше уже сам нагуглишь, информации море. И напоследок для общего развития есть хорошая книга Маклейна "Теория категорий для работающего математика", читать рекомендуется всем и прикладникам и теоретикам
Это обычный метод, только не глобальный в контексте пакета, а метод у объекта. Некое подобие ООП в других языках.
Да, ты сможешь вызывать метод через точечную нотацию <указатель_на_объект>.<имя_метода>() То есть в твоем изначальном примере должен существовать указатель на объект Page, например это будет переменная p, тогда вызов p.save(). А просто глобально save() вызвать уже нельзя.
, ну а можешь логическую цепочку привести, хочется понимать из чего такие соображения. Мы же в борщ не добавляем кашу+сардельки+рыбу, хотя это все относится к горячей еде :)
часть редиректить на клиентскую часть а другую часть на админку
впереди как правило ставится nginx там в пару директив настраиваются редиректы
Андрей, не в ту, в данном вопросе деревья мной упомянулись лишь для доп полей и как крайняя оптимизации, можно обойтись доп словарями, первоначальный вопрос был о другом
Андрей, моя точка зрения заменить массив на словарь (username, *Client) собственно и высказано в первом сообщении, там где нужны дополнительные поля - или создать доп словари как пример с ролями (role, []username) или использовать деревья
встречный вопрос: какой аргумент в сторону использования массивов перед словарем?
Андрей, хэш таблица с линейной сложностью будет очень редко встречаться на миллиардах данных, на тысячах пользователей это работает за константу и не нужно пробегаться по ним. Мьютексы хороши в других кейсах более низкоуровневых, тут же классическая задача. Вот посмотри, Дэйв Чени рассказывает https://dave.cheney.net/2016/11/13/do-not-fear-fir...
вторая часть статьи "Let’s talk about actors" как раз сравниваются соединения подход с мьютексами и каналами
Андрей, я до сих пор не пойму зачем бегать по массиву? если для клиентов прямо так и напрашивается словарь, для запроса клиентов по другим полям (роль, регион и т.п.) существуют индексы (деревья). И мьютексы тут не нужны, есть более читабельные способы синхронизации через каналы
Chronic 86, а какая орм используется? тут можно пойти от того что требуется отдать API: создать сразу объект нужного типа и в его поля читать ответ из БД. В более сложном и классическом варианте ты создаешь по модели на каждый тип ответа из БД (например у тебя 10 хранимок, которые возвращают 10 разных структур) на чтение, и соответствующие таблицам структуры на запись.
А методы которые дергаем соответственно тестирует отдельно, в них как правило какая-то бизнес логика или трансформации может быть задействована.
Если БЛ нет, то есть смысл посмотреть на тестирование с помощью снимков (snapshots), перед коммитом ты записываешь данные, которые пришли из БД, третьих сервисов в third_party.json к примеру, и записываешь результат который отдал твой метод контроллера в отдельный response.json, - все это коммитишь. На staging в тесты подсовываются суррогатные данные из твоих third_party.json вместо вызовов реальных сервисов, прогоняются через логику контроллера и сравниваются с response.json. Соответственно если разработчик меняет логику или взаимодействие, то он должен перезаснять снапшоты.