На одной из конференций произошел комичный случай. Подходит слушательница:

— Александр, есть такой вопрос: Как нам повысить уровень доверия в отношениях с заказчиком?

— А что сейчас не так с уровнем доверия?

— Ну, у нас есть команда, есть менеджер. И мы хотим, чтобы заказчик доверял команде и общался только с менеджером. А он лезет напрямую к инженерам…

— А чем это плохо? Человек сразу получает ответы на свои вопросы, быстрые коммуникации и все такое.

— Понимаете… Мы ему джуниор инженеров продаем как синьор инженеров… И нам не хотелось бы, чтобы он обнаружил этот факт.

Напомню изначальную постановку вопроса: “Как нам повысить уровень доверия в отношениях с заказчиком?”

Вот о заказчиках сегодня и поговорим. А точнее, о простом инструменте, который:

• Поможет осознать, где находятся ваши отношения с заказчиком
• Покажет, почему формы отчетов иногда бывают такие идиотские
• Возможно, поможет понять причины “неадекватного” поведения заказчика

В продолжение предыдущей статьи о тестировании интерфейсов в Тинькофф Банке расскажу, как мы пишем unit-тесты на javascript.

Доклад с прошлогодней конференции специалистов системного и бизнеса анализа — Analyst Days 2013 года от старшего аналитика питерского офиса компании DELL — Петрашева Дмитрия

На странице доклада можно найти презентацию и видео, а здесь текст…

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

Иногда заказчики писали свои цели в официальных документах к проекту. Иногда мне казалось, что я и так понимаю цели заказчика — они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.

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

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

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



Я относился к правой половине людей, которые мало что знают о типах, но при этом искренне верят, что это не удобно. И так было до тех пор пока я не познакомился с одним из строго типизированных языков (c#) вплотную. С тех пор мое отношение к php да и вообще к программированию в целом изменилось.

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

Если думаете, что сейчас я буду читать мантры вроде «нужно сосредоточиться на работе», «обязательно любите свою работу и себя», ошибаетесь. Эта статья не об управлении временем или проектами. Гики решают такие проблемы с помощью даджетов. В данном случае — детектора углекислого газа.

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

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

Тема отображения текущей раскладки беспокоила хабрасообщество уже не раз. Я опробовал множество существующих решений, но по разным причинам они меня не устроили. Чтобы подобрать для себя наиболее удобный вариант отображения текущей раскладки, я написал небольшое приложение на C++, которое при нажатии на левый Shift отображает язык в системном курсоре редактирования текста. Менее 100 строк кода и около 4 килобайт в скомпилированном виде — на основе этого вы можете достаточно просто реализовать свой взгляд на то, как на самом деле должна выглядеть индикация текущей раскладки.

Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно понятный топик, который бы гуглился по запросу «git изменение коммитов».

Недавно наткнулся на jQuery Transit, плагин для плавных трансформаций и переходов. Вместо работы с таймерами, плагин использует CSS3 трансформации.

Работает с тем же синтаксисом, что и animate, но вместо этого стоит использовать метод transition.

С более старыми браузерами новые эффекты не работают, а стандартные CSS будут меняться, хотя и без какой-либо анимации. Для того, чтобы откатиться обратно на animate, достаточно использовать следующее:

if (!$.support.transition)
    $.fn.transition = $.fn.animate;

Всего 2КБ.

Вводная часть

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

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

Если возникнут какие-то вопросы, напишите в личку или в комментарии к посту.

Недавно я узнал об интересном классе устройств DAS (Direct Attached
Storage).



Это такой NAS, который не имеет собвственной операционной
системы на борту, но позволяет создать аппаратный рейд-массив из 2-8
дисков. Признаюсь, что если бы до этого у меня не было NASа, то я бы
усомнился в том, что такое устройство вообще может быть востребовано.
Непонятно, чем же оно лучше обычного выносного жёсткого диска. А
оказалось, что в определённых обстоятельствах DAS — это именно то, что
нужно.

Принципы Metro-дизайна

Обычно мы употребляем слово «Metro» как название стиля дизайна пользовательского интерфейса, который компания Microsoft использует в своей собственной платформе и также предлагает использовать разработчикам и дизайнерам при создании приложений для Windows Phone (в этой серии статей я фокусируюсь на Windows Phone). Но давайте немного углубимся в суть термина «Metro» и выясним, что же в действительности он означает. Начнем с того, что Metro определяется двумя вещами: принципами Metro-дизайна и языком Metro-дизайна.

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

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

Поэтому нет ничего удивительного в том, что интеллектуальная мафия Facebook создала портфель из таких громких стартапов как Quora, Cloudera, Jumo, Asana, Path, а так же многих других. Все они появились на свет и достигли зрелости очень быстро, фактически — еще раньше чем случилось «самое главное» для Facebook. Как и большинство вещей которые делают Facebook уникальным местом в интернете, вышеперечисленные стартапы многим обязаны не только Цукербергу с его творением, но и времени, в котором они выросли.

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

К тому же, большинство технологических компаний очень любят инвестировать «в своих». Это со-инвестирование и поддержка друг-друга позволяет оставлять все богатство «в семье». И несмотря на то что огромное количество умных людей, предпринимателей и ангел-инвесторов вышло из Google, Yahoo, eBay, Amazon и Microsoft, их гигантский бизнес не позволяет внутри зародиться «мафии» о которой мы говорим, способной катализировать в один момент и привнести в мир много нового, разного и классного.

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

Твиттер @turbomilk один из самых популярных корпоративных твиттеров России (почти полторы тысячи фоловеров). Пароли от нашего твиттера есть у каждого работника. Правда, пишут всего несколько человек, но так получилось, что большую часть записываю именно я. Более чем за год наблюдений и опытов на людях у меня набралось некоторое количество немудреных приёмчиков, как сделать твиттер интереснее и популярнее.

Вначале наш корпоративный твиттер был экспериментом. Писали мы туда все что угодно. Для кого-то он вообще стал заменой персональному твиттеру. Как-то раз случайно получилось взглянуть на наши твиты со стороны в небольшой малознакомой компании — помещение наполнилось сдавленными смешками… Так мы поняли, что надо продолжать в том же духе. Итак, что же надо делать в корпоративном твиттере?

Идеальный твиттерянин — это человек, который способен генерировать «короткие интересности», с частотой по две в час. При этом человек он не праздный (и это не парадокс; Твиттер — не заточен под бытие основным занятием, он скорее дерево, на котором усердный труженик ставит зарубки о сделанном (увиденном-услышанном) в «большой жизни»). Идеальный твиттерянин позитивен, не допускает грамматических ошибок, не матерится без повода и не словоблудит. Идеальным твиттерянином можно родиться. А можно им стать. По крайней мере, можно постараться.

Бытует мнение, что «в Твиттер можно писать всё то же, что и в обычный блог, только коротко». Это не так. Посты в Твиттер можно условно разделить на десять видов:

1. Лытдыбры. Такими постами впору грешить людям, которые набрали в Твиттере (или в жизни вне его) определённый «вес». Никому не интересно, что ты, Вася, скушал суп. Если, конечно, ты не Вася Стрельников (почувствуйте разницу). Хотя, если это был «суп из придатков карликовой белой слонихи», которую ты же лично и уохотил, то шансы на успех могут значительно вырасти.

2. Цитаты. У некоторых (пишу с комической гордостью) — цитаты «из себя». А вообще — любые короткие изречения. На злобу дня, или «вневременного философского значения». (Затёртый цитатник «Золотые россыпи» — за пятак у старушки на книжном развале — и дело в шляпе. Шутка.)

3. Шутки. Важно отметить — не анекдоты, а именно шутки. И лучше всего: а) свои; б) свежерождённые. (Да, именно потому, что борода в твит не помещается.)

4. Парадоксы. Блестящие опечатки, до слёз нелогичные высказывания, или полный бред вроде «пассивного некрофила». Есть сущие мастера жанра, которые очередным «задвигом» могут развеять любую депрессию.

5. Ссылки. (Ради которых, как многим кажется, Твиттер и заводят.) О «ситиаре Твиттера» мы поругаемся позже, а пока скажу так: более трёх ссылок подряд — и ты выглядишь, звучишь и пахнешь «ботом». Делай выводы.

6. Картинки. Конечно — ссылки на картинки. Хороший камуфляж для «лытдыбров». Важно! Если картинки сделаны айФоном и выложены на Твитпик, то успех практически гарантирован.

7. Новости. «Свежие новости» — вещь, конечно, фантастическая. Но вдруг тебе повезло, и именно ты держал за руку майкла джексона, провожая его в последний путь? Тогда смело пиши об этом. Но помни! Если есть куда дать ссылку, скорее всего это уже не новость. (Вот и твит, кстати; угадаешь категорию?)

Не так давно в блоге stackoverflow появился интересный пост от сооснователя компании Stack Exchange Joel Spolsky о расчёте зарплат разработчикам. Далее до хабраката выдержка из этого поста, а после — вольный перевод документа по системе компенсации в Stack Exchange.

Сейчас то самое время года, когда мы пересматриваем зарплату каждого сотрудника с целью убедиться, что она соответствует его уровню. Мы зависим от десятка системных разработчиков и платим им на основе системы компенсации, разработанной нашими двоюродными братьями из Fog Creek, которая настолько отличается от Stack Exchange, что возникали некоторые трения.

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

Одним из ключевых принципов Stack Exchange является то, что мы делаем всё, что можно, публичным, и мы стараемся оставлять публичные артефакты для всего, что мы делаем. В духе этого, я загрузил полную версию нашего актуального плана расчёта компенсации, так что вы можете увидеть, как принимаются решения относительно уровня компенсации в Stack Exchange. Только одна вещь не стала публичной – финальные расчёты, которые определяют каждый индивидуальный чек, это потому, что мы должны сбалансировать нашу философию открытости с правом каждого разработчика на личную неприкосновенность.

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

Но почему же он становится плохим руководителем? Причин на самом деле много, детально о них можно почитать у Саши Орлова, я расскажу про одну из наиболее ярких.

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

Похоже, не все поняли, что произошло: вместо того, чтобы говорить о фреймворке от Google, народ обратил внимание на вторичную вещь — компрессор javascript-кода Closure Compiler.

А ведь Closure Library есть ни что иное, как внутренний javascript framework Гугла, компоненты которого использованы в Gmail, Google Docs и прочих веб-приложениях от Г. И это замечательно, друзья мои! Ведь это фреймворк от непревзойдённых профессионалов разработки популярных вебприложений. Что подразумевает собой качество, стабильность и оптимальность кода, единообразность разных частей фреймворка.

До сих пор подобных фреймворков была только одна штука — это YUI, корпоративный фреймворк Yahoo. Безусловно, YUI радует единообразием, отличной документацией, компонентами, удобными для создания вебприложений. Однако мне всегда казалось странным, что Yahoo, далеко не лидер в области rich internet applications, опубликовала свои библиотеки, а Google, та самая компания, которая своими Maps и Gmail просто заставила разработчиков браузеров поддержать всё то, благодаря чему мы сейчас имеем кучу 2.0 сервисов, не обнародавала свои javascript-библиотеки на пользу простым разработчикам.

И вот это произошло. Ура, товарищи!