На этой неделе столкнулся с замечательным примером того, что даже умные люди способны реализовать одну и туже функциональность в одном и том же случае тремя разными способами (наверняка даже большим количеством, но нам пока только три потребовалось).
Речь пойдёт о non-consumable покупках/товарах в мобильных магазинах Apple, Google и Amazon. Non-consumable — это разовые покупки, которые нет необходимости повторять. Например: наборы уровней, вечный VIP, отключение рекламы. Consumable, наоборот — это расходники — золото, энергия, сундуки и прочий f2p шлак.
На работе потребовалось сформулировать задачи для DevOps. Эта роль протянула свои щупальца почти во все аспекты разработки ПО, и человеческим языком описать её задачи оказалось довольно сложно. В итоге получился такой вот перечень (конечно, это задачи именно melesta-вского DevOps):
Историческая справка по собиранию метрик в линуксах, маленький кусочек вырванный из грандиозного контекста.
Меня периодически спрашивают как же мы в «Сказке» договорились о распределении долей потенциальных безумных доходов. Никакого секрета в этом нет, сейчас расскажу.
Тем более, что несмотря на практическое отсутствие денег для делёжки, выработанный подход за 3 года продемонстрировал свою адекватность.
Одной из практик тестирования является написание тестов по уже найденным ошибкам, чтобы исключить их в будущем. Но что делать, если ошибка не специфична для конкретной логической сущности, а может встретиться в любом месте?
Писать для каждого модуля одинаковые тесты — не самая вдохновляющая идея, тем более, о них ещё помнить надо. В некоторых случаях тест можно написать не для проверки поведения программы, а для проверки непосредственно её кода. Этакий семантический pep-8, если хотите.
В коде «Сказки» уже давно прописалось несколько таких тестов, собранных в файле test_code.py . О них и расскажу, для иллюстрации идеи.