К основному контенту

5 за 5 (история 4)

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

1. Harvest, Yield, and Scalable Tolerant Systems (PDF)
Обычно мне тяжело даются такие "около академические" труды, CAP-теорема и вот это все. Но тут хорошо зашло: новые термины для того, что уже раньше использовалось в работе и обозначалось "на пальцах".

We assume that clients make queries to servers, in which case there are at least two metrics for correct behaviour: yield, which is the probability of completing a request, and harvest, which measures the fraction of the data reflected in the response, i.e. the completeness of the answer to the
query. Yield is the common metric and is typically measured in “nines”: “four-nines availability” means a completion probability of 0.9999 . In practice, good HA systems aim for four or five nines. In the presence of faults there is typically a tradeoff between providing no answer (reducing yield) and providing an imperfect answer (maintaining yield, but reducing harvest). Some applications do not tolerate harvest degradation because any deviation from the single well-defined correct behaviour renders the result useless.

2. За все время работы в разработке я часто сталкивался с верой в магическую должность "Архитектор" (Архитектор ПО, Системный архитектор и прочее). Видимо мне не повезло встретить и поработать с настоящими архитекторами, если они существуют. А сам я, IMHO, как-то хреново "архитектирую".
Тем не менее, вот вам несколько полезных ссылок про архитектуру ПО "на подумать-почитать":
3. "Программный комитет HolyJS изнутри" - подробный рассказ про процесс подготовку докладов (= содержательной части конфы) к конференции HolyJS. В нашем ПК Heisenbug конфы процессы очень похожие.

4. Немного истории из своего блога "Популярная психология в IT и не только".

5. Интересная цитата, надо книжку почитать
An Approach to Cybernetics (1961) by Gordon Pask
"Observers are men, animals, or machines able to learn about their environment and impelled to reduce their uncertainty about the events which occur in it, by dint of learning... [We] shall examine human observers who, because we have an inside understanding of their observational process, belong to a special category. For the moment, we shall not bother with HOW an observer learns, but will concentrate upon WHAT he learns about, i.e. what becomes more certain."




Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu