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

Казалось бы, работа у IT-шников несложная — вагоны не разгружаем, землю не роем и уставать физически не должны. Однако о дичайшей усталости людей занятых интеллектуальным трудом приходится слышать чаще, чем хотелось бы. После того как я приехал в Москву 3 года назад — я почему-то начал дичайше уставать на совершенно ровном месте, и ни я, ни врачи не могли найти причину. После 2-х лет поисков тривиальная и легко исправимая причина нашлась, и на мой взгляд — в группе риска находятся практически все люди, занимающиеся интеллектуальным трудом. Ситуация усугубляется двумя народными обычаями.

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

1) Летом все ок, а зимой — апатия, ничего не хочется делать. Это любят называть сезонной «депрессией».
2) Утром все ок, а к вечеру на работе — мозги «не варят», ничего не хочется делать — только хабр и reddit листать. Приходите домой — и с дичайшей усталостью падаете в кресло. Сил хватает только лазить в интернете до ночи. Этот пункт — касается и работодателей, есть шанс, что люди вечером перестают работать не из-за своей лени.
3) Даже если вы просыпаетесь без будильника — вы не высыпаетесь.
4) Кофе и прочие стимуляторы — не дают бодрости, лишь делают вас злее.
5) Даже если вы спите «сколько влезет» — сны короткие и не запоминающиеся, или их нет вообще.
6) Вы замечаете, что даже 1 вещь вам иногда трудно удержать в голове. Мы можете забыть что вы сейчас хотели сделать.
7) Вы просыпаетесь уже с дичайшей усталостью
8) Вам кажется, что в комнате темно и все несколько не резкое.

Вот ждёте вы важное письмо от коллеги. 5 минут, 10, 20 — а нет его! Блин, а проверю-ка я спам. И точно — есть, 19 минут назад пришло. Чёрт, я же вроде уже добавлял этого человека в whitelist — почему письмо в спаме? Надо разобраться, проверить правила… Но сейчас нет времени, это мелочь, письмо срочное, а в эти правила как закопаешься, так на полчаса, еще и админов может быть придётся дёргать. Нет, потом…
А завтра письмо от коллеги опять в спаме.

Так, заходим на сайт… Блин, не сохранилась авторизация. Вот на всех сайтах сохраняется, а тут нет. Почему? Может быть почистить куки? Может сохранился старый пароль? Надо разобраться… Нет, ну это сейчас и в настройках рыться, и не дай бог, сохранённые пароли для других сервисов потру, нет, потом. Это ведь, в сущности, мелочь, а мне надо работать…
А завтра снова раздражение от не сохранённой авторизации и минута на размышление о причинах.

О, вот библиотека, которая делает то, что мне надо. Хм, на Python, а мне надо на С++. А на С++ такой нет. Ну ок, почитаю питоновский код, пойму общую идею и перепишу на С++. Ух ты, у моего редактора нет подсветки кода на Python! Может быть есть какой-то плагин? Или поискать другие редакторы? Ай, ну ладно, это ведь одноразовая задача, не буду тратить время — сейчас полдня потрачу на сравнение десятка IDE и редакторов кода на Python, а у меня ведь задача совсем другая, плюну, это ведь мелочь…
А завтра к библиотеке на Python выходит обновление и его снова приходится читать.

Почему бы не перестать страдать по мелочам?

Многие документы я подготавливаю в LaTeX, а не в Word. И к моменту, когда я определяюсь со следующим местом работы, я подвожу итоги сделанного, и, уж чтобы не пропадало, фиксирую их в документах, составляющих каркас моего CV. По моему личному убеждению, тщательность в создании документов для будущего работодателя нужна не столько для коммуникаций с «эйчарами», сколько для осмысления дороги, по которой идешь, и направления, в котором решаешь двигаться дальше. Итак, почему я для резюме выбрал LaTeX?

Никогда не планируйте

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

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

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

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

Всем доброго дня! Поднимите руку те, у кого дома стоит монитор с диагональю 27 дюймов? :) Что-то мало рук, опустите. Двадцатисемидюймовки давно спустились из профессионального и полупрофессионального сегментов в домашний, не растеряв при этом основных потребительских качеств. Все модели можно условно поделить на две большие группы — 27" FullHD и 27" WQHD/WQXGA. Основное отличие — разрешение матрицы. В первом случае имеем классические 1920х1080, во втором — 2560х1440/1600. Вторая группа мониторов требует приличных аппаратных мощностей для работы с таким разрешением, так что её мы рассмотрим как-нибудь в другой раз. А вот про 27«FullHD монитор расскажем сегодня.

Изменять код
В процессе разработки программного обеспечения нет такого понятия, как «стагнация». Все, что вы разрабатываете сейчас — просто очередная версия компонента, который вероятно будет меняться в будущем. Изменение является самым распространенным явлением в мире разработки программного обеспечения и вам лучше принять это как факт. Рассчитывайте на возможные изменения всего, что вы разрабатываете и поэтому проектируйте ваш код более модульным. Это упрощает изменения и в тоже время увеличивает качество кода. Старайтесь придерживаться концепций DRY и YAGNI. Вы часто будете в ситуации, когда вы смотрите на ваш код и представляете, что вы могли бы сделать это лучше. Так пусть эта мысль не мешает вам спать. Садитесь сразу за дело и рефакторинг! Если не сделаете это сейчас, вы возможно никогда этого не сделаете. Чем дольше ждете, тем сложнее и дороже это будет. И это может вырасти в лишнюю головную боль, с которой не захочется связываться.
«Хороший код — это код, который легко изменять. Код стремится измениться до момента, когда его уже не легко изменять. Весь код становится плохим кодом». Неизвестный автор.

Это перевод 1.17 версии руководства от Rafe Kettler.

Содержание

1. Вступление
2. Конструирование и инициализация
3. Переопределение операторов на произвольных классах
   • Магические методы сравнения
   • Числовые магический методы
4. Представление своих классов
5. Контроль доступа к атрибутам
6. Создание произвольных последовательностей
7. Отражение
8. Вызываемые объекты
9. Менеджеры контекста
10. Абстрактные базовые классы
11. Построение дескрипторов
12. Копирование
13. Использование модуля pickle на своих объектах
14. Заключение
15. Приложение 1: Как вызывать магические методы
16. Приложение 2: Изменения в Питоне 3

Вступление

Что такое магические методы? Они всё в объектно-ориентированном Питоне. Это специальные методы, с помощью которых вы можете добавить в ваши классы «магию». Они всегда обрамлены двумя нижними подчеркиваниями (например, __init__ или __lt__). Ещё, они не так хорошо документированны, как хотелось бы. Все магические методы описаны в документации, но весьма беспорядочно и почти безо всякой организации. Поэтому, чтобы исправить то, что я воспринимаю как недостаток документации Питона, я собираюсь предоставить больше информации о магических методах, написанной на понятном языке и обильно снабжённой примерами. Надеюсь, это руководство вам понравится. Используйте его как обучающий материал, памятку или полное описание. Я просто постарался как можно понятнее описать магические методы.

Тема анонимности в Интернете является сейчас достаточно модной и интересной, и особенно теперь, когда новостные порталы пугают наc всякими там PRISM, правительственными инициативами и прочим. Большинство людей озабочены тем, как сохранить тайну своей личности в сети и поэтому все темы так или иначе посвящены ЗАЩИТЕ. Но иногда, раскрытие анонимности это не такое уж и плохое дело. Да-да, эта заметка — мой опыт борьбы с анонимностью своими силами, без помощи спец-служб…

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



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

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

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

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

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

Все основано на реальных событиях, но примеры были максимально упрощены, чтобы в них осталась лишь суть проблемы.

Эта статья написана Павлом Минаевым int19h — разработчиком из команды PTVS специально для публикации в нашем корпоративном блоге на Хабрахабре. Делитесь вашими впечатлениями в комментариях. Все отзывы будут переданы команде.

Здравствуйте! Я – разработчик из команды Python Tools for Visual Studio. На днях мы выпустили новую бета-версию нашего продукта, и, воспользовавшись поводом, в этот раз я хотел бы поподробнее рассказать о том, что из себя представляет PTVS, и что он может вам предложить.

Технология UAC — не лишний компонент безопасности ОС Windows последних версий и пользователи приходят к этой мысли, борясь с malware и вирусами. Программистам, в свою очередь, стоит грамотно подходить к написанию приложений и принимать во внимание наличие такого «обстоятельства».



На хабре и вообще в сети много статей на тему «Как отключить UAC», «Как обойти UAC» и др. Но зачем отключать, функция ведь полезная? Зачем обходить, мы ведь не злоумышленники?

Нужно дружить!

Ниже я расскажу как это делать в Вашем приложении.

По роду занятий я часто общаюсь с различными русскими и западными командами. Очень частый вопрос — есть ли какая-нибудь специфика в работе наших и как это влияет на разработку?

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

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

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

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

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

В апреле в Бристоле прошла встреча комитета С++, на которой были рассмотрены первые предложения по внесению изменений в новый стандарт С++14. Все рассматриваемые в этой статье изменения были одобрены на этой встрече и уже занимают свое почетное место в последней версии черновика нового стандарта (N3690 от 15 мая 2013).

Краткий перечень:

• Автоматическое определение типа возвращаемого значения для обычных функций
• Обобщенная инициализация захваченных переменных лямбд с поддержкой захвата-по-перемещению
• Обобщенные (полиморфные) лямбда-выражения
• Упрощенные ограничения на создание constexpr функций
• Шаблоны переменных
• exchange
• make_unique
• Обособленные строки
• Пользовательские литералы для типов стандартной библиотеки
• optional
• shared_mutex и shared_lock
• dynarray

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

Дисклаймер

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

Проверяем хабр

Единственное упоминание о парадоксе Кондорсе (не путать с теоремой Кондорсе о жюри присяжных) есть в комментарии пользователя TimTowdy.

Я сполна получил п***й за первый пост. Самое время писать продолжение! Итак, чего же мне надо от резюме разработчика?

Все ниже в порядке приоритета.

Код

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

Честно скажу, когда я искал работу, мое резюме смело можно было отнести к категории плохих. Да, там было несколько хороших секций (типа, а вот я написал 2 книжки и 30 статей), но также там была и таблица скилов со строчкой: C#, 1 year of experience, Intermediate (!).

Сейчас я читаю много резюме и приглашаю людей на интервью. За последние 3 года я провел около сотни интервью, а резюме повидал раз в 5 больше. Так что сейчас я довольно четко представляю, что я хочу видеть в резюме. Но для начала я расскажу, чего в резюме я видеть не хочу.

Шаблоны

Многие аутсорсинговые компании придумали себе шаблоны резюме. Мотивация, в принципе, понятна, они хотят все унифицировать чтобы использовать machine learning для извлечения хороших кандидатов все выглядели одинаково, как рядовые в строю. Однако, шаблоны эти одинаковы для всех позиций и составлены мудрыми CTO недалекими HR, которые понятия не имеют, что такое реально классный программист.

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

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

Ошибка №1

Соискатель получает столько приглашений на собеседование, что не в состоянии их обработать.
Логичный вывод соискателя: «на рынке острый дефицит кадров, так что могу отсеивать компании как хочу, отфутболив тех, кто заикнется о коде на бумажке, сортировках или гномиках». Возможна и менее скромная вариация того же вывода: «раз меня все хотят, значит, я классный профессионал, могу всем диктовать свои условия». Звучит, вроде, логично, но абсолютно бесполезно.

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