В пятом сезоне был эпизод, где Форман устраивает 13-тую на клинические испытания лекарства от хореи Гентингтона. При этом следит, чтобы она не попала в контрольную группу с плацебо. За что и получает заслуженное увольнение.
IT компания может быть клиенто-ориентированной и при этом программисты могут не работать на первой линии техподдержки. Все зависит от правильности распределения ролей в команде и желания налаживать производственные процессы.
В любом случае, если отвлекать прогеров на общение с клиентами, то когда им код писать? Я уж не говорю об эмоциональных качествах (типа интровертности, обычной для программистов), которые могут не позволить нормально совмещать состояние потока и перманентное общение с неограниченным кругом лиц.
это было то же самое, что фиксированная передача в соотношении 1:1 (сегодня в большинстве случаев используются передачи с соотношением 3:1). Это как ехать на велосипеде на самых нижних передачах – вы быстро крутите педали, но едете медленно.
Строго наоборот — это как ехать на 21 скорости в горку.
"Части выражения нужно записать в переменную, имя которой поясняет его назначение."
И тем самым ухудшить производительность в 3 раза, исключив условные вычисления.
Повысить читаемость кода, можно используя прокси функции с домен-специфическими именами. В том же C# это делается легко и просто с использованием extension methods. Комментарии, не к публичному API, а по месту — это злое зло, препятствующее рефакторингу и нарушающее принцип DRY второго рода.
Ну тесты и спеки пока пишут люди. И там и там уровень детализации и покрытия требованиями даже близко к 100% не приближаются. Причем даже в формальных спецификациях слишком много подразумевается и мало декларируется. Даже из простейших примеров статьи это понятно. А ведь там по сути хелловорд специфицируется.
Спеки также не дают гарантий. Наоборот, тесты и специфицируют и валидируют бизнес-логику одовременно. Плюс помогают кодированию и отладке. Мало того, фиксируют поведение, отслеживая регресс.
Фолдинг сообщений об ошибках в глубоких шаблонных специализациях был бы действительно полезен. Для всего остального есть Error List и его автоматическая синхронизация с Output по выделению.
Ну это просто вопрос договоренности, с целью уменьшения путаницы. Еще лет 50 назад это было не так и массу делили на релятивистскую и инерционную (гравитационную).
Т.е. в Хаусе соврали про этот момент? Все врут...
В любом случае, если отвлекать прогеров на общение с клиентами, то когда им код писать? Я уж не говорю об эмоциональных качествах (типа интровертности, обычной для программистов), которые могут не позволить нормально совмещать состояние потока и перманентное общение с неограниченным кругом лиц.
Строго наоборот — это как ехать на 21 скорости в горку.
За счет того, что если ось не мак, то сорт браузера и факт изменения размера уже можно не вычислять.
"Части выражения нужно записать в переменную, имя которой поясняет его назначение."
И тем самым ухудшить производительность в 3 раза, исключив условные вычисления.
Насчет "неизвестно насколько" я бы поспорил. Анализ покрытия вполне себе точная метрика.
Ну тесты и спеки пока пишут люди. И там и там уровень детализации и покрытия требованиями даже близко к 100% не приближаются. Причем даже в формальных спецификациях слишком много подразумевается и мало декларируется. Даже из простейших примеров статьи это понятно. А ведь там по сути хелловорд специфицируется.
Чем формальные спеки лучше TDD, кроме того, что они хуже и быстро устаревают?
То что иконки отъехали примерно в это же время в мобильном FF, может быть как-то связано?
Скорее это защита самих краулеров от спама. Бывают ведь страницы с бесконечным содержимым, типа календариков на все года.
out может быть одним и тем же во всех метаморфозах, но при этом ошибочным (например сообщением об ошибке распознавания речи).
"перевела edge на chrome" очевидно вы хорошо разбираетесь в вопросе.
Ну это просто вопрос договоренности, с целью уменьшения путаницы. Еще лет 50 назад это было не так и массу делили на релятивистскую и инерционную (гравитационную).