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

Постараюсь очень лаконично и быстро обрисовать ситуацию с хэшами.

Сразу определю какую задачу применения хешей буду рассматривать — аутентификация пользователей. Не токены восстановления паролей, не аутентификация запросов, не что-то еще. Это также не статья про защиту канала передачи данных, так что комментарии по challenge-response и SSL неуместны!

Вы хотите быть эффективным на работе и в жизни, но есть пара дурных привычек, от которых вы не можете избавиться? Расслабьтесь, избавиться от привычки невозможно.

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

Однако мириться с этим немыслимо, с этим нужно что-то делать, и я хочу поговорить об этом.

Сегодняшний пост написан под влиянием полезной книги Чарльза Дахигга "Сила привычки".

Жизнь — игра, в которую играют буквально все. Эта статья — ваше руководство.

Основы

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

На днях я наткнулся на замечательную карманную книгу для PHP разработчиков «PHP: The Right Way». Скорее, она будет более полезна новичкам. Чем именно? По интернету разбросано огромное количество материла по PHP, но многое уже устарело или не приводит к написанию качественного кода. В этой книге присутствуют основные актуальные сведения с ссылками на проверенные ресурсы. На самом деле, сначала я хотел перевести ее, форкнуть репозиторий, благо лицензия это позволяет. Но оказалось, что перевод уже есть. Нет только русской книги в форматах для электронных книг, но так как используется Markdown в русском форке, то это не составит труда.

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

И вот одному менеджеру не досталось пары, и я встал играть роль сотрудника. До этого всем пар хватало, поэтому к роли сотрудника я был не очень готов…

Моим собеседником оказался молодой человек, назовем его Егор, технический директор небольшой компании.

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

— Александр, как же так, почему Вы не присылаете мне отчеты?

Я стоял, думал-думал, чего сказать. И потом ляпнул первое, что пришло в голову:

— Егор, а чего ты хочешь, если ты такой хреновый менеджер?!

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

— Что значит “хреновый менеджер”?!!! Это недопустимо — так разговаривать с руководством…

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

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

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



При помощи двух регуляторов можно настроить объём поливаемой за раз воды, а также период между поливами. Кому интересно — далее подробная инструкция, как сделать такое устройство.

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

Вы устали? Хотите выпустить пар? Вам требуется передышка? Предлагаю вам присоединится ко мне, тем более, что на дворе пятница.

Когда-то книга “Совершенный код” Стива МакКоннела произвела на меня большое впечатление. Я лично думаю, что эту книгу обязательно должен прочесть каждый, кто зарабатывает на жизнь написанием кода. Особенно настоятельно я рекомендую эту книгу новичкам.

Настоящие размышления о программировании посвящаются главе 33 “Личность” и тем, кто решил связать свою жизнь с разработкой программного обеспечения.

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

Например, Маша, считает, что вечно опаздывающий на работу Вова — страшно неорганизованный человек, который не умеет управлять своим временем.
При этом Вова опаздывает на работу, потому что вынужден с утра умыть, накормить, одеть маленькую дочку и отвести ее в садик. Сама Маша приходит почти вовремя только на работу, во всех иных случаях она всегда опаздывает. Маша винит в своих опозданиях пробки на дорогах, не сработавший будильник, родственников, которые ее отвлекали.
95% бизнесменов терпят крах в первые 1-2,5 года, считая, что знают своего потребителя и могут заставить его купить свой товар. Мысль: «Я знаю, как думает мой покупатель», — главная ошибка начинающего бизнесмена.
На самом деле сам покупатель не знает, как он думает.
Именно поэтому большие компании содержат несколько маркетологов для реализации своей продукции.

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

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

В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана:

• На роль тестировщика готовы брать кого угодно, кто умеет достаточно уверенно нажимать на кнопочки
• Тестировщики редко участвуют в судьбе проекта, принимают решения по требованиям и срокам
• Тестировщиков стараются подключать как можно позже, когда надо «покликать» и «поикать ошибки»
• За исключением небольшого числа продуктовых компаний, большинство работодателей предлагают тестировщикам зарплату в 1,5-2 раза ниже, чем разработчикам.

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

С понедельничком (говорят — самым депрессивным в году), хабровчане!
После публикации этой статьи, многие заметили, что я шустрый карьерист, и у меня начали просить совета на тему: как обеспечить карьерный рост в IT-индустрии. Во избежание повторения одних и тех же советов разным людям в личных сообщениях я и пишу эту статью, делясь в ней историей своего собственного карьерного роста и основными наблюдениями, которые я сделал за 13 лет опыта работы в больших и не очень компаниях.
Сразу предупрежу, что не претендую на изложение универсальной теории карьерного роста сферического коня в вакууме, и большинство замечаний искривлено призмой моего восприятия. То, что неоднократно работало в моем случае, необязательно сработает в вашем.

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

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

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

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



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

По-моему, эта статья — самое важное, что я в жизни сделал. Не самое сложное, объёмное или интересное, а важное.

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

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

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

Предисловие

Есть распространенное мнение: «если бы строители строили дома так же, как программисты пишут программу — первый залетевший дятел разрушил бы цивилизацию». С подачи индийского гуру-программиста Мурали Кришна Чимутури (Murali Krishna Chemuturi), Интернет настойчиво приписывает авторство этой цитаты Джеральду Вайнбергу (Gerald Weinberg), хотя на личном сайте Джеральда она не ищется. Скорее всего, человек, который первый заговорил о психологии в программировании, к этому высказыванию не имеет никакого отношения. И вот, почему.

Это изречение – пример демагогического приемчика. Здесь пропущена главная посылка: разработка ПО это то же самое, что и строительство домов. Эта посылка, по умолчанию, подразумевается как достоверный факт, который не требует доказательства. Применение этого приемчика заставляет неискушенного читателя делать ложный вывод о том, что у программистов, в отличие от строителей, руки растут не из нужного места.

Материальное производство (обработка объектов физического мира) насчитывает десятки тысяч лет истории. На этом пути был накоплен колоссальный объем знаний естественных наук: математики, физики, химии, географии, геологии, биологии и проч.

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

— Багнутый диван! — чертыхнулся Антон, в очередной раз придавив пальцы тяжеленным диваном, который они с Сергеем тащили уже 14 пролётов.
— Багнутый? — переспросил Сергей, — ты тоже программистом раньше работал?
Они уже почти месяц работали вместе, но Сергей ни разу не заподозрил в нем бывшего программиста. Жилистый, мускулистый Антон как-то мало походил на бывшего программиста.
— Приходилось подрабатывать в студенческие годы, — немного сконфузившись ответил Антон.
— Да не дрейфь! Я свой. Три года вёрстки и js под все браузеры, — Сергей оживился и надавил чуть сильнее, придавив Антона.
— Тише ты! Штука тяжелая! Из-за нее у меня уже функционируют только 7 пальцев. И вообще тут лучше о кодопрошлом разговаривать вполголоса. Настучат — вмиг вылетим с работы. Фуух, какой тяжелый! Двигай влево до упора.

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

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

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

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

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

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

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

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

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

«Когда человек не знает, к какой пристани он держит путь, для него ни один ветер не будет попутным». (С) Сенека, Луций Анней

Предисловие

Как-то один из топов уважаемой компании, которая занимается продуктовой разработкой ПО, пригласил меня, как эксперта, чтобы я оценил качество нового продукта. Я внимательно просмотрел и прослушал презентацию. Видно было, что коллеги очень старались и работали по 10-12 часов, чтобы продукт выглядел на высшем уровне. После чего меня спросили: «хороший получился продукт или нет?» Я поблагодарил за представленную презентацию, но попросил ответить на свой последний вопрос: «А какие процессы, и с какой целью вы собираетесь автоматизировать с помощью этого инструмента?» Вопрос почему-то вызвал замешательство у докладчиков. После небольшой паузы, топ, который, видимо, был идеологом нового продукта, ответил: «Был бы инструмент хороший, а какие процессы с его помощь автоматизировать мы найдем!» Мне пришлось сказать, что оценить продукт я не смогу. Не зная бизнес-целей, невозможно понять степень их достижения.

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

Для иллюстрации используем проект «Экспедиция за сокровищами Флинта»

«Человек добился успеха, если он встает утром и ложится спать вечером, а в промежутке занимается тем, чем хочет»

— Боб Дилан

Я – программист по образу жизни. Я в одиночку работаю программистом, чтобы обеспечить себя интересной, полезной, гибкой и хорошо оплачиваемой работой. У меня нет инвесторов, я не собираюсь нанимать сотрудников, не говоря уже о том, чтобы стать следующим Google или Facebook. У меня нет личного самолета, и мое лицо вряд ли скоро появится на обложке Newsweek. Меня это устраивает.

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

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

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

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

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

Я имел дело с перекупщиками, которые понятия не имели, чего хочет конечный покупатель, я встречал неадекватов, которые понимали как надо только после того, как мы сделаем, как просят.

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

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

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

Так вот — каждый раз, когда я встречал очередного «чего там работать, сделайте как в фейсбуке» клиента, я давал себе слово, даже нет – я клялся могилами предков, что вот уж я бы на его месте так себя не вел. Я бы на его месте работал так, что разработчик еще и приплачивал бы за удовольствие иметь со мной дело. Уж я бы на его месте мог бы стать просто самым лучшим заказчиком. И однажды я им стал.