О книге «Онтогенез — от клетки до человека»
Онтогенез — совокупность последовательных морфологических, физиологических и биохимических преобразований, претерпеваемых организмом от оплодотворения до конца жизни.
Если долго интересоваться системной инженерией, самоорганизацией и эволюцией, то рано или поздно купишь книжку по Онтогенезу. Мне повезло и первая книга, на которую я наткнулся, оказалась образцовым примером научно-популярной литературы.
Книга может быть интересна всем, со схожими интересами, но в особенности:
- программистам, чтобы понимали какой примитив эти ваши алгоритмы, которые вы на работе пишите;
- девушкам, чтобы во время беременности не пили, не курили, дышали ровно и, главное, понимали почему надо поступать именно так.
Девушки-программистки, по моим прикидкам, должны глотать эту книгу за раз :-)
На мой взгляд, книга не менее ценна чем «Эгоистичный ген» Ричарда Докинза или «Сумма технологий» Станислава Лема. Хотя и носит сугубо описательный характер, не предлагая новых идей.
Верификация через дублирование логики
Привет.
В посте Тесты, которые тестируют тесты я описал свой взгляд на верификацию программ через дублирование их логики в виде отдельной модели и последующее сравнение с ней. В качестве частного случая выступили юнит-тесты.
В этот раз, опираясь на изложенные идеи, я попробую сформулировать общий подход к оценке уровня верифицированности ПО.
Зачем нужен план
Самый известный план на планете
Сначала я хотел назвать этот текст «Зачем нужен бизнес-план», но к чему себя ограничивать? План — он и в Африке план, не важно для чего. Тот, что для бизнеса, называется бизнес-планом. Тот, что для эвакуации, называется, как ни странно, планом эвакуации. И так далее.
Но идея текста таки пришла из области, где актуальны бизнес-планы. Часто стал встречаться с высказываниями о том, что «бизнес-план, конечно, нужен, но вот конкретно в нашем случае он пользу не принесёт потому, что»:
- у нас слишком большая неопределённость, будет гадание на кофейной гуще;
- и так всё предельно ясно, план — лишняя трата сил.
Сам я тоже страдал этими тараканами, но так получилось, что периодически разного рода планы составлять всё-таки приходилось. И хочу вам сказать — планы делать полезно и нужно.
Но сначала…
Тестирование семантики кода
Одной из практик тестирования является написание тестов по уже найденным ошибкам, чтобы исключить их в будущем. Но что делать, если ошибка не специфична для конкретной логической сущности, а может встретиться в любом месте?
Писать для каждого модуля одинаковые тесты — не самая вдохновляющая идея, тем более, о них ещё помнить надо. В некоторых случаях тест можно написать не для проверки поведения программы, а для проверки непосредственно её кода. Этакий семантический pep-8, если хотите.
В коде «Сказки» уже давно прописалось несколько таких тестов, собранных в файле test_code.py . О них и расскажу, для иллюстрации идеи.