Инструментарий гейм-мастера

Genetica — крутой генератор текстур
3dg.me/ru/2d-graphics/genetica-36-moshchnyy-redaktor-i-generator-besshovnyh-tekstur

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Ага. Но я пробовал написать это двумя словами, успеха не добился. :)

Простая Наука — дайджест опытов #30

Как раз к тому времени реакцию холодного синтеза освоят. :)

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Альтернатива вполне была — заплатить, подождать и поиграть.

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Вы можете гарантировать что ваш «GIU элемент» в процессе краша не влез в память где хранится переменная с номером счета клиента и в итоге не привел к отправке денег к черту на куличики?
Если уверены то да, не надо падаться, надо обрабатывать и продолжать работу.

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

ОБТ — это, вообще, о другом.

О чем?

ЗБТ и предшествующие тесты

Про ЗБТ ничего не говорил.

ОБТ и «Ранний доступ» — это отнюдь не «Fail Fast» за полцены.

Что же это, как не продажа за полцены забагованного приложения?

В жизни сервер, например, имеет право упасть только во время старта

В идеальном мире.
Вспомните сколько раз падали сервера Diablo 3 за время с его старта.

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

ОБТ же и «Ранний доступ». Это в сфере игр. В сфере прикладного ПО не знаю, но уверен там есть аналогичные подходы.

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Может быть я не правильно перевел?

Design by contract (TM) (also called Contract Programming) is another example of a Fail fast! feature. This is because invalid values for input/output arguments and object attributes are immediately detected and raise a program error at runtime.

There are many more Fail fast! features that can be built into a programming language.

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Все принципы надо применять с умом. :)
В программировании подругому и не бывает.

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

После того как написал текст про исключения мне были представлены два факта:
1) Текст получился сумбурным
2) Я описал Fail fast! подход.
Хорошенько разобравшись в ситуации понял, что лучше мне не пытаться рассказывать об этом самостоятельно, а перевести уже существующую статью. Тем более что на русском материалов на эту тему парктически нет.

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Пример про Гагарина — один в один пример про ракету на Марсе из статьи. Где как раз и говорится, что в этой ситуации надо использовать Forgive.
Действительно создается ощущение что статьюв ы не дочитали.

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Хм. Два часа ночи дают о себе знать.
«не было никакого смысла отправлять в релиз ПО с fail fast»
«нет никакого смысла в том»
«автоматизируют обработку ошибок и отправку отчетов на Windows»

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Тут есть нюанс.
Под виндой, особенно раньше, не было никакого смысла в релиз ПО с fail fast. Потому что без поддержки отчетов об ошибках отсылаемых разработчикам нет никакого смысла от того, что программа на стороне пользователя упала.
Но сейчас ситуация иная.
Есть множество инструментов, которые автоматизируют обработку ошибок на Windows и можно быть уверенным, что падение не будет бесполезным.
На Андроиде так вообще уже встроенная система отчетов используется.

Ну и исправление ошибки пользователем очень уж специфичная вещь не так уж часто встречается, чтобы при разработке на этот момент обращать внимание.

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Ответ достаточно очевиден:
Выгрузить драйвер, написать в журанл об этом, сообщить пользователю что в драйвере произошла ошибка.
Если есть информацию о разработчиках драйвера — отослать им отчет об ошибке.
fail fast тут не применим, потому что задача fail fast обрабатывать ситуации нерпедсказуемые, а не полностью заменять обработку ошибок.

Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Цель вашего вопроса показать, что fail fast не применим в 100% случаев?
Ну так об это и в тексте написано. Никто не предлагает пихать fail fast без разбору везде.

Как гироскопом на руле машину измеряли

Тебе поможет железяка под названием ELM327. Стоит не особо дорого.
Умеет работать с бортовыми компьютерыми и передавать данные на RS232 или Bluetooth.
Ее протокол в свободном доступе. Сможет передать все что ей расскажет бортовой компьютер.
Удачи!

Исключение — твой друг

Интересная методика… и так близка сердцу. :)

Исключение — твой друг

Для исключений(именно как средство отлова ошибок) видел вот такой метод:

class cExceptionHack{
protected:
	int					m_Data;
public:
	void throwException(){
		m_Data++;
	};
};

cExceptionHack* Exception = NULL;
Exception->throwException();

Решение более чем спорное, но интересное и результат дает — на выходе отчет об ошибке с call stack внутри.
Хотя мне видится, что включить исключения является значительно более корректным решением.

Государство и Интернет: как избежать силового сценария

Тест Тьюринга не проверяет разумность принятия решений.

Исключение — твой друг

Именно так. Мне и добавить нечего. :)