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

Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…

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

Зачем?

• Большинство проектов, с которыми мне приходится сталкиваться, устроены по принципу двух-трех-уровневой иерархии, причем наверху пищевой цепочки находятся серьезные боссы, управляющие серьезными клиентами, а внизу – кодеры за еду разной степени продвинутости. В золотой середине сидят тимлиды, они же техлиды, они же координаторы, на которых, собственно говоря, и ложится основная ответственность за реальный value и реальный delivery.
• Эти люди чаще всего – собственный продукт компании, начинавшие как молодая шпана, прошедшие длинный путь развития, и при этом – они категорически не рвутся превращаться в больших начальников, поскольку свежий ветер еще шумит у них в голове, и отрываться от своей, любовно возделанной на .NET грядки, им совсем даже не хочется.
• Тем не менее – к ним приходят и говорят: у тебя растут года, парень, пора руководить, че.

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

Вчера вечером компания Microsoft выпустила новый продукт – Microsoft Visual Studio LightSwitch 2011. Официальное определение этого продукта звучит следующим образом «гибкий инструмент разработки, используемый для быстрого создания и развертывания настольных бизнес-приложений и бизнес-приложений для облака». Если вам интересно, что же на самом деле представляет из себя LightSwitch, почему он позиционируется именно таким образом и как работает — добро пожаловать под кат.

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

Перевод статьи молодого греческого программиста «Why I bill hourly»

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

Я люблю сравнивать разработку программного обеспечения с возведением здания, начиная с пустого земельного участка. Процесс выглядит примерно так:

Клиент: Вот участок, на котором мы будем строиться. Вот наброски того, что мы хотим построить. Можете назвать точную стоимость постройки?

Любой инженер-строитель шарахнется от такого предложения, программисты же в своей жажде заключить сделку прикинут смету, удвоят ее, добавят 30% и будут надеяться на лучшее. Как отвечаю на такой вопрос я?

Контракты с фиксированной ценой — это зло, вот что можно услышать от адептов agile. С другой стороны, такие контракты — это реальность, с которой сталкиваются многие agile команды. Но что, если мы попытаемся укротить это зло, а не бороться с ним?

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

Так давайте же начнем с самого контракта.

Фиксированная цена, время и объем обязательств

Такие контракты фиксируют сразу три магических фактора — деньги, время и объем обязательств. Являются ли цена и сроки проблемой для agile команд? Ну, не должны быть. На самом деле, таймбоксинг (timeboxing) — это обычная практика. Ограничение бюджета только помогает таймбоксингу лучше работать.

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

В одной старой шутке говорится: если у вас есть проблема, и вы собираетесь решать ее с использованием регулярных выражений, то у вас есть две проблемы. Мне кажется, сверхурочная работа — что-то из той же серии. Я сформулировал бы это так: если у команды есть проблема, и для ее решения планируется работать сверхурочно, то у команды две проблемы. В чем же заключается вторая проблема?

У регулярной сверхурочной работы множество вредных последствий — как для команды, так и для компании. Давайте их рассмотрим.

Истощение

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

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

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

В то же время оказывается, что многие специалисты мечтают о хорошей работе, связанной с тестированием. Тестировщики часто спрашивают меня, как «втереться» в команду, работающую по Agile-методике, или как им найти просто хорошую работу. Если у них нет опыта в программировании, они переживают, что недостаточно технически подкованы, чтоб попасть в Agile-команду. С моей же точки зрения, навыки безусловно важны, но отношение к делу — это самое главное. Если вы готовы учиться, делать все для того, чтоб на выходе у команды получился по-настоящему хороший продукт, то у вас хорошие перспективы как у тестировщика. Мой вам совет — добровольно подключайтесь к любой деятельности, которая принесет новые знания и умения, и работайте на совесть, чтоб отточить приобретенные навыки.