Category: техника

Category was added automatically. Read all entries about "техника".

69. Отойдите от клавиатуры

Поскольку не всем во френд-ленте интересно читать про программирование, буду тут размещать только анонсы.

Итак, следующий перевод - доступен тут

Добавлю, что описанное там действительно имеет место быть. Однажды я просидел за отладкой девайса непосредственно "в поле" у заказчика целый день и так и не нашел, в чем же была проблема. Пришлось оставаться на второй день - найти было надо. И вот уже засыпая вечером в отеле, я вдруг понял, что являлось причиной очень странного поведения девайса! На следующее утро первым делом проверил эту пришедшую мысль - именно так и оказалось!

Лицензионный контент

На днях впервые купил электронную книгу на литресе (http://www.litres.ru/). И все, что литресу нужно было сделать, чтобы я вдруг решил потратить 50 евроцентов за нормально отформатированную для чтения на налодоннике книгу вместо упорного поиска халявы - это добавить поддержку платежей через пейпел.

Плюс то, что вроде бы авторы или правообладатели таки реально получают оттуда деньги, если верить Гришковцу, тоже является небольшим стимулирующим фактором.

В общем, думаю, что таки буду и дальше этим сервисом пользоваться...

И кстати - ни разу не реклама :)

61. Единственный исполняемый файл

(В оригинале - One Binary)

Мне встречались проекты, в которых процесс сборки модифицировал исходный код с целью получить различные исполняемые файлы для различного окружения. Такой подход все только усложняет и добавляет риск того, что версии окажутся рассогласованными между собой. Такой подход приводит к получению нескольких практически идентичных копий ПО, каждую из которых нужно установить в корректное окружение. Слишком много движущихся частей в механизме повышают вероятность того, что что-нибудь где-нибудь пойдет не так.

Однажды я работал в команде, где изменение каждого свойства запускало полный процесс сборки, в результате тестерам значительную часть времени приходилось ждать, даже в случае незначительных изменений (и да, процесс сборки был, конечно же, очень долгим). На другом проекте, на котором я работал, было правило запуска процесса сборки с нуля для получения финальной версии – релиза, что означало то, что не было гарантии того, что клиент получал то же самое, что тестировали тестеры.

Правило же здесь простое: создавать единственную версию исполняемых файлов, с возможностью идентификации этой версии и продвижения ее по «линии жизни» проекта. А специфику среды сохранять непосредственно в среде окружения (в файле или папке, например)

Если у вас процесс сборки изменяет исходный код или сохраняет установки среды непосредственно в коде, это означает лишь то, что никто на этапе дизайне не продумал того, как разделить ядро приложения от платформо-зависимых деталей. Или даже хуже – команда знала, что и как надо делать, но приоритеты были расставлены так, что сделано этого не было.

Конечно же, бывают и исключения. Возможно, вам нужно будет делать сборку для различных окружений, имеющих очень серьезные отличия и ограничения. Однако эти исключения не применимы в большинстве случаев из серии «извлечь из базы, показать на экране и записать назад в базу». Или же вам приходится мириться с доставшимися в наследство проблемами, которые сложно исправить прямо сейчас. В таком случае вам нужно последовательно двигаться вперед, небольшими шагами, но начать движение надо как можно раньше.

И еще одна важная деталь. Сохраняйте установки среды окружения в системе контроля версий наравне с кодом. Нет ничего хуже, чем повредить конфигурацию и не быть в состоянии посмотреть, какое именно изменение все сломало. Информацию об окружении лучше помещать отдельно, поскольку она меняется с другой частотой и по другим причинам по сравнению с кодом. Некоторые команды используют распределенные системы контроля версий для этого (подобные bazaar и git), поскольку в них проще поместить изменения непосредственно из рабочего окружения (что рано или поздно, но неизбежно случается) назад в репозиторий.

Автор оригинала - Steve Freeman

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

Новый объектив, или место, где много птиц

Несколько дней назад обзавелся теле-зумом 55-200, и с нетерпением ожидал возможности испытать его. А где же его лучше всего испытывать, как не на озере с большим количеством лебедей и других птичек?

Тем более что погода этому благоприятствовала - можно сказать, первый весенний денек выдался, с солнцем и плюсовой температурой.

Давно желанная цель - лебедь, расправивший крылья, так и осталась целью. Зато получилось много остальных кадров, снятых новым объективом, позволившим приблизить происходящие слишком далеко события.

Collapse )

38. Любая система рано или поздно откажет.

(В оригинале Everything will ultimately fail)

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

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

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

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

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

Любой механизм, предназначенный для предотвращения какого-либо сбоя или поломки, привносит новые возможные сбои или поломки. Мы создаем кластерное ПО для переноса приложения с отказавшего сервера на работающий, но при этом не можем никак проконтролировать работоспособность кластерной сети.

Стоить вспомнить, что авария атомной станции на острове Трех Миль была вызвана неисправностью предохранительного клапана – механизма безопасности, предназначенного для предотвращения последствий превышения давления в контуре выше допустимого.

И что же мы можем с этим сделать?

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

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

Автор оригинала - Michael Nygard

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

9. Вы участвуете в переговорах чаще, чем вы думаете

(В оригинале You're negotiating more often than you think.)

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

«Нам действительно нужна функциональность Х?» - задает вопрос инвестор.

Под «Х» может пониматься любая жизненно необходимая для проекта вещь: лицензии на ПО, резервные сервера, удаленное архивирование или источники бесперебойного питания. Вопрос этот обычно задается в снисходительном тоне, как будто бы взрослый уличил ребенка в том, что он растратил все свои карманные деньги на комиксы и жвачки.

Правильный ответ на подобный вопрос: «Да, действительно нужна». Ответ, который дается крайне редко.

В конце концов, мы инженеры, а инженеры всегда готовы искать компромиссы. Все мы хорошо знаем, что такое расточительство, как источники бесперебойного питания на самом деле не столь и нужны, а в крайнем случае можно нанять студентов и посадить их крутить педали в серверной. Поэтому вместо «Да, действительно нужна» мы часто говорим что-то вроде «Ну... в принципе можно обойтись без резервного сервера, если вас устроит то, что система будет в оффлайне во время сервисных работ и в случае аппаратных сбоев, но если использовать память с поддержкой коррекции ошибок, то этих сбоев можно будет избежать, и останутся только глюки Windows, случающиеся где-то раз в три дня, и значит, нужно будет делать профилактический ресет каждую ночь, это как раз могут делать студенты в перерыве между кручением педалей...»

Все это может быть правдой, но к сожалению дать такой ответ будет в корне неправильно. Инвестор перестанет вас слушать сразу после слова «Ну...».

Проблема в том, что вы по-прежнему видите себя в роли инженера, в то время как инвестор на 100% уверен, что он обсуждает условия. Вы ищете решение, которое бы всех устроило, а он ищет выигрышный вариант для себя (и скорее всего, проигрышный для вас), или же, говоря простым языком, торгуется. А в обсуждении условий ни в коем случае нельзя соглашаться на первый предложенный вариант. На самом деле, правильный ответ на «А нам действительно это надо?» должен быть примерно вот таким.

«Без резервного сервера вся система будет падать минимум трижды в день, практически всегда в моменты максимальной нагрузки, или же когда вы будете что-то демонстрировать совету директоров. На самом деле нам даже нужно четыре сервера, тогда мы сможем сделать две резервных пары и гарантировать работоспособность системы в полном объеме, даже если выйдут из строя сразу два сервера».

Конечно, вы понимаете, что на самом деле вам не нужны четыре сервера. Это такой прием в переговорах, чтобы дать возможность инвестору сменить тему. Вы повышаете стоимость, показывая, что вы и так уже находитесь на самой границе, на самом минимуме все еще приемлемой конфигурации. И если вы вдруг в результате таки получите четыре сервера вместо двух, то вы всегда сможете на одном из лишних серверов развернуть копию системы для тестирования, а второй использовать для нужд разработки.

Автор оригинала: Michael Nygard

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

Realterm

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

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

Вот ее интерфейс:



Чем он мне не нравится? Ну например:

- Что делает кнопка "Change"?
- А что делает галочка рядом с ней?
- После того как я выбрал нужный порт, что нужно сделать с нажатой кнопкой "Open"?
- А что делает маленькая кнопочка без надписи рядом с кнопками "Clear" и "Freeze"?

На других закладках все не менее прозрачно и интуитивно понятно :)

Понимаю, что софт этот бесплатный и сделан на чистом энтузиазме, но все же чуть больше времени уделить юзабилити было бы можно. А так из-за тяжелого интерфейса программой реально сложно пользоваться несмотря на продвинутую функциональность, и в результате предпочтение отдается программе Teraterm, простой и удобной, но не имеющей возможности управлять контрольными пинами, что, к счастью, не приходится делать слишком часто...

И снова Виста!

Невероятно! Пропользовавшись ноутбуком с вистой два года, я наконец-то нашел их знаменитое трехмерное переключение окон Windows Aero! Все дело оказалось в маленькой кнопочке на панели быстрого запуска.

Теперь мне интересно - а что будет, если эту кнопочку оттуда удалить? Смогу ли я вернуть ее назад?

И почему этот интерфейс не появляется по стандартной комбинации переключения Alt-Tab?

Да уж, делать "пасхальное яйцо" из основной функциональности - новый шаг в повышении удобства пользовательского интерфейса от Микрософт! :)