Задача: массово удалить ключи их хранилища redis, старше 1 месяца (изначально у всех ключей выставлялся ttl = 1 год).
Вот как это выглядит для запуска из консоли:
redis-cli -n 2 keys "*" | while read LINE ; do TTL=`redis-cli -n 2 ttl $LINE`; if [ `echo 31622400 $TTL | awk '{print $1 - $2}'` -gt 2678400 ]; then redis-cli -n 2 del "$LINE"; fi; done;
Уволил сегодня человека. Год, а то и два этого не делал. Он был нанят 3 недели назад и не прошел испытательный срок. Техдиректор говорит «давай отработанные им трудовые часы поделим на 2» (рассчет ЗП, мол, сделал мало). Я так не могу. Во-первых, на испытательный срок вполне оговоренная ЗП, обсуждаемая на или после собеседования. Во-вторых, что для меня более значимо, я не могу взять и вот так оставить человека без денег. Для компании эти 30т.р. дела не сделают, а он, может быть, и не рассчитывал, что его сегодня уволят, планировал что-то, да и вообще это могут быть единственные его деньги на жизнь. Он может и виноват, что не справился, но же не сволочь, чтобы с ним поступать как с таковой.
Вообще, в коллективе назревает какой-то раскол. Новых требуемых людей почему-то на рынке найти не можем, старой небольшой командой с объемом работ не справляемся, управление вообще почти отсутствует, некоторые аналитики постоянно давят на то, что мы зажрались, ничего толкового сделать не можем, зато все нам подай, кто-то на все смотрит пофигистически и делает ровно то, что от него просят, а некоторые наооборот так рьяно выражают свою точку зрения, что на любой нововведение сразу же отвечают, что это г и работать не буду, мало того, они так работать не будут. Полгода попытались работать по Scrum, не пошло. Сейчас пытаемся внедрить Kanban.
Я гляжу на это со своей мизантропичной колокольни и кажется мне, что просто у нас собралась команда, в который каждый знает и умеет свое дело, но от того, кто всех состыкует, его вот и нет. При этом люди совершенно не пытаются вдаваться в личности своих коллег, им все подай как должное, они привыкли работать только с собой и ни с кем больше. В итоге каждый делает и двигает что-то свое. В итоге каждый день превращается в переживание и сострадание, глядя на всё и всех вокруг..
Я люблю заниматься чем-то креативным, но иногда приходится делать рутину. Так и сегодня на одном из сайтов под управлением Netcat мне понадобилось поставить 28! обновлений системы. Человек не обновлялся несколько лет.
Ладно, черт с ним. Сделаю. Убил на это около часа времени. Еще полчаса ушло на выявление некоторых ошибок после установки. Но потом меня ждала засада.
Стоит сказать, что у меня нет всех обновлений, выпущенных на данный момент, есть еще 1-2 патча, которыми я не владею. Ну так вот, на сайте перестали работать урлы вида /news/2007, которые должны возвращать только новости за 2007 год. Я полчаса трейсил код, чтобы понять, где ошибка. Она оказалась в ядре системы. У меня есть все вышедшие патчи для другой редакции системы (Extra). Я туда заглянул и увидел, что эту ошибку исправили в последнем патче.
И вот я вынужден был из-за каких-то неведомых космических причин находить и исправлять ошибку сам. А надо было лишь за 1000 р купить клиенту поддержку на неделю, чтобы скачать все вышедшие патчи (ну или на просторах интернета порыться).
Печалька.
Сделать плохой проект в моей области деятельности легко. Достаточно отправить требования от клиента разработчику и сказать «делай». При этом или игнорируя, или сильно идя на поводу клиента в вопросах, в которых разработчик говорит, что так «плохо». Все, больше никаких транзакций. (а зачем, ведь у менеджера еще есть другие проекты, между которыми надо разрываться и тратить силы)
Что в таком случае происходит? Разработчик первое время, имея какой-то запас энергии, старается что-то сделать «правильно». Со временем эта энергия из-за происходящего «тупизма» (в конце проекта менять ключевой аспект системы, потому что так захотелось, например) исчезает, а источников ее пополнения нет. В итоге получается, что клиента говорит, менеджер транслирует (при этом стараясь думать на минимальном уровне), а разработчик делает со словами «как сказали, так и сделал» (ни шага вправо или влево, ни инициативы).
В итоге имеется некачественный продукт, который затем еще и поддерживать (я сейчас не буду говорить про внешнюю составляющую проекта, только про внутреннюю «кухню»). Итого компания теряет деньги на всех этапах: на этапе производства на некачественном функционале, реализуемом чаще всего за бортом спланированного, на этапе поддержки на всплывающих недочетах этапа реализации.
Причины могут быть такие:
— менеджер заинтересован только в том, чтобы уложиться в план, «сдать» и получить бонусы, на все проблемы просто мотает головой и не комментирует
— разработчик работает положенные 8 часов, ибо все остальное ему не компенсируется, отсутствие мотивации влечет к потере качества
— клиент, который говорит «хочу», считая себя гуру во всем, игнорируя объективность
— выше стоящее руководство, которое все пустило на самотек, полагая, что там сами справятся
— внешние обращения, не связанные с проектом, но отвлекающие всех участников проекта
— слабая нервная система людей
— полное отсутствие общей технологической концепции, участие разных людей, неведующих «предысторию»
Решения:
— адекватный менеджер, который прежде всего заинтересован, пусть даже ему не хватает знаний и опыта
— адекватное отношение к разработчикам, которые не являются «скотом», которому корм бросил и забыл, а есть люди, которые хотят делать что-то нужное, «правильное», и быть за это вознагражденными
— попытаться уладить отношение с клиентом, а точнее человек, который сможет убеждать человека на той стороне в том, что правильно, а что нет, чтобы не идти на поводу всегда
— адекватное управление не только в рамках этого проекта, но и смежных
— грамотное управление внутренней структурой проекта, выделение одного ведущего специалиста, который разбирается в «технике», который бы смог помочь менеджеру в вопросах, в которых тот не ведает
Ну и вообще, одна сильная, харизматичная личность в проекте (раз уж вертикаль власти отсутствует) способна решить все проблемы и объединить людей!
Последние исследования показали, это продуманная брачная окраска обусловленная соответствующей матримониальной стратегией. Используя растянутые на коленках джинсы и не глаженые футболки с надписями «Йа креведко» программисты умело избегают цепких когтистых лапок глянцевых блондинок с активной, очень активной потребительской позицией… И попадают в руки более гуманных женских существ.
Приручать программистов нужно тихо и ненавязчиво, самыми что ни на есть консервативными способами: приготовить завтрак, помыть пол, поправить воротничек, попросить починить компьютер и вывести погулять. Идея состоит в том, чтобы кротко внедриться в алгоритм его жизни, и оттуда не выпасть. Хотя последнее мало вероятно, так как, сами понимаете, это будет дефект, а дефект приводит к ошибке.
Но тут нужно понимать, что приручить его это еще пол беды. Прикормленный программист может еще пару десятков лет пребывать в мутноватой стадии «да, все конечно славно, но действительно ли она ТА САМАЯ или стоит подождать новую более продвинутую версию?» А поскольку, любая версия нет-нет, да и взывает нарекания пользователей, в этом состоянии он может зависать бесконечно. Это у них, кстати, называется гордым словом – перфекционизм.
Знавала я одного человека, который 5 лет семье не мог стиралку купить по причине того, что идеальное соотношение цена-качество все никак не находилось.
Остальная часть истории о том, Как выйти замуж за программиста.
P.S. 14 февраля — неофициальный, но широко отмечаемый в профессиональном мире День компьютерщика. 14 февраля 1946 году научному миру и всем заинтересованным был продемонстрирован первый реально работающий электронный компьютер ENIAC I (Electrical Numerical Integrator And Calculator).