Pull to refresh
21
0
Send message

Пожары и Стратегия

Reading time 5 min
Views 2.1K

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


Когда вы занимаетесь инженерной работой, у вас есть разные виды задач. Некоторые задачи — аварии или тактическая работа. Мы часто называем это "тушением пожаров", особенно когда работа связана с срочной починкой или ее нужно выполнить незамедлительно.


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


Важно понимать, каким видом работы вы занимаетесь в данный момент, и думать о
ней соответственно.


Пожары


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

Читать дальше →
Total votes 8: ↑6 and ↓2 +4
Comments 5

Ваше проектирование – отстой

Reading time 5 min
Views 33K
… но это нормально. Любое проектирование отстой. И всегда будет отстоем.

Если вы мне не верите, давайте объясню…

Ни один проект не переживает встречи с реализацией


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

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

Это нормально.

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

Недостающие данные могут быть сделаны опциональными или заменены умолчальными.

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

Ограничение уникальности можно
Читать дальше →
Total votes 50: ↑35 and ↓15 +20
Comments 29

Unix shell: абсолютно первые шаги

Reading time 12 min
Views 287K

Зачем и для кого статья?


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

Здесь не будет пересказа манов (документации), и статья никак не отменяет и не заменяет их чтение. Вместо этого я расскажу о главных вещах (командах, приемах и принципах), которые надо осознать с самого начала работы в unix shell-е, чтобы работа происходила эффективно и приятно.

Статья касается полноценных unix-подобных окружений, с полнофункциональным шеллом (предпочтительно zsh или bash)и достаточно широким набором стандартных программ.

Читать дальше →
Total votes 36: ↑29 and ↓7 +22
Comments 21

Continuous Integration в 10 строках кода или зачем нужны BuildBot, Jenkins, TeamCity и подобные

Reading time 5 min
Views 60K
Заметка рассчитана на тех, кто уже знает, что такое Continuous Integration, но еще не выбрал, какую именно систему внедрить у себя.

Почитать, что такое CI и зачем его использовать, можно в Википедии и здесь же на Хабре: статья 1, статья 2, тег CI.

А я расскажу, на что стоит обратить внимание при выборе CI для своего проекта, почему стоит использовать готовую стороннюю систему и не стоит ввязываться в написание собственного «велосипеда».


Началось с того, что в одной IT-компании случился такой разговор между коллегами из соседних отделов:

K1: У вас continuous integration есть?
K2: Есть, запускаются тесты на каждый коммит в транке.
К1: На чем работают?
К2: Собственный скрипт. Сейчас переходим на Buildbot.
К1: Может я чего-то не понимаю, но что там сложного? Апнуться, запустить тесты, отправить результат, зачем какой-то Buildbot, проще же самим написать?

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

Итак, пишем «свой маленький скриптик». У меня получилось уложиться в 10 строк, включая shebang, задание в кронтабе и настройку отправки писем.
Читать дальше →
Total votes 34: ↑26 and ↓8 +18
Comments 11

Information

Rating
Does not participate
Registered
Activity