Как все начиналось

Порядка 5 лет назад, я начал свое шествие по миру ламповой техники. За это время было собраны десятки разных схем и прослушано порядка пяти десятков «оригинальных» ламповых усилителей. В результате, сформировалось четкое понимание «как должно звучать» и какой «гибкостью» должен обладать аппарат.
В процессе знакомства с разными гитарными усилителями, долгое время, меня не оставлял в покое звук «головы» от фирмы Krank. Но в тот момент, к сожалению, оценить его и попробовать — было невозможно. Продажи начались только-только в Штатах, а живых экземпляров в Санкт-Петербурге не было. Было принято решение во что бы то ни было, достать столь «лакомый кусочек». К счастью нашлись подходящие люди которые смогли купить и привезти его в Питер. Долгие 14 дней ожидания и моя прелесть стояла на пороге квартиры. Счастью не было предела. Чем больше я на нем играл, тем больше мною овладевала мысль: «Как же устроена эта штука».
В один прекрасный момент, собравшись с духом, я твердо решил: “Я должен узнать «тайну » этого чуда”.

Шли дни, летели недели. Кусочек за кусочком вырисовывалась схема.

Этой статьей я начинаю цикл, цель которого – создание наиболее полного руководства по Managed Extensibility Framework (MEF) на русском языке. Результатом цикла, в моих планах, станет создание бесплатной электронной книги о MEF. Если у вас есть соображения или предложения по этому поводу – дайте мне знать в комментариях. Я надеюсь, что совместными усилиями мы можем создать отличное руководство.

Эта статья составлена по материалам моих докладов про MEF на разных встречах, в том числе на конференции DevConf.

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

Автор оригинальной статьи — Майкл Эбраш, человек и пароход. Для тех, кому лень изучать википедию, отмечу, что это программист с более чем 30-летним стажем работы, который в свое время помог Кармаку сделать Quake, разработал GDI для Windows NT, приложил руку к созданию первых двух версий Xbox, а сейчас работает в R&D-отделе компании Valve.
В своей заметке он вспоминает, как зарождалась индустрия 3D-игр вообще и Valve в частности, рассказывает про свой опыт работы в различных корпорациях, приоткрывает завесу внутренней кухни Valve и ищет новых сотрудников. Статья большая, и я посчитал ее достаточно интересной для того, чтобы перевести на хабр.

---

Всё началось с Лавины*.

Если бы я не прочел её и не влюбился в идею Метавселенной, если бы она не заставила меня представить, насколько распределенная 3D сеть близка к воплощению в жизнь, если бы я не подумал я могу сделать это и, что более важно, я хочу сделать это, я бы никогда не встал на путь, который в конечном счете привел меня в Valve.

В 1994 году я уже несколько лет как работал на Microsoft. Однажды вечером, когда моя дочка рассматривала книги в магазине Little Professor в Sammamish Plateau, мне посчастливилось заметить Лавину на полке. Я взял книжку, прочитал первые страницы, решил купить и в итоге проглотил её за день. Параллельно я начал задумываться о том, что 80 процентов описанного в ней осуществимо прямо сейчас, и мне захотелось реализовать это сильнее, чем когда-либо вообще хотелось сделать что-то с компьютером — я всю жизнь читал научную фантастику, и вдруг мне выпал шанс превратить её в реальность. Так я попытался начать в Microsoft проект по созданию технологии сетевого 3D.

Доброго времени суток, Хабр!
Охрана квартиры, дачи, гаража, машины — эти вопросы всегда стояли особенно остро и это не только в нашем государстве, а вообще. Как говорится «есть спрос, есть и предложения», т.е. всегда будут кражи, так как есть те, кто скупает краденое. Таким образом, хочу представить Вам небольшой проект, который поможет Вам немного обезопасить дом, и если не поймать преступников (что в данном случае и не требуется), то хотя бы вспугнуть их и проинформировать Вас о том, что была попытка проникновения в ваше святая святых.

От переводчика
Выгорание в жизни программиста может случиться по самым разнообразным причинам; если задаться целью перечислить все пути, которыми оно подкрадывается к нам, то одно лишь это перечисление займет немало времени. Это еще один повод, по которому не стоит недооценивать процесс выгорания — иначе однажды вам придется искать дорогу обратно, и стоить это может очень дорого. Последняя строка вовсе не голословна — мне самому однажды смогла помочь лишь любовь к коду — когда уже, казалось бы, все осточертело и ничего не хотелось, чтение подвернувшегося Макконнелла навеяло воспоминания о том, как же когда-то мне нравилось программировать. И сегодня мне нравится делать это снова.
А теперь — слово автору.

Я отошел от своего выгорания только недавно — несмотря на то, что случилось оно несколько лет назад. Да, мне было непросто… очень непросто. Когда я думаю о произошедшем, на ум приходит немало причин тому, что случилось со мной — но самое интересное заключается в том, что каждой из них я никогда раньше не придавал значения. Хотите повторить мой путь и выгореть? Пожалуйста, у меня готов целый список, как следует поступать в таком случае:

1. Думать о проекте и только о нем

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

В чем суть?

У меня нет обычного зомбо-телевидения — я не смотрю эфирные каналы уже лет 7, чему несказанно рад и вам советую. Для вечернего диванного времяпрепровождения после трудового дня дома имеется полный стек продуктов от яблочной компании — начиная с компьютера-лаптопа и заканчивая тв-приставкой (подключенной к обычному 34" телевизору по HDMI). Все это между собой прекрасно работает и дружит, а используя некоторые онлайн-сервисы я вообще могу смотреть любимые сериалы прямо из интернета и не качая торренты. Жилось-былось мне так вполне хорошо, но вот в России проводят Олимпиаду, а тут еще и тесть приехал — заядлый спортсмен. Хочется посмотреть Игры! И таким вот образом образовалась задача — обеспечить качественный показ спортивных передач (то есть не на экране мобильного телефона), которые идут на нескольких эфирных каналах и все это используя подручные средства. И чтобы не очень долго и сложно было реализовывать.

Наблюдая за своими родителями-пенсионерами, а точнее за размерами их пенсий, я крепко задумываюсь о том, как обеспечить себе нечто оное в достойном меня размере. На государство в составе СНГ рассчитывать, похоже, не приходится. Значит, надо что-то делать самому! И начинать надо сейчас, пока мне 32 года, есть какой-никакой заработок и силы крутиться. Раньше были мысли, что я буду вечно молодым, вечно здоровым и все время что-то делать. Постепенно начинаю осознавать, что лет 20… 30 — и силы будут таять (или распыляться). Поэтому пару лет назад я начал понемногу что-то делать в этом направлении. Получил некоторый опыт, который может быть интересен уважаемому сообществу. Даже если для читателя вопрос пенсии сейчас звучит безумно абстрактно, то все равно рекомендую хотя бы пробежаться. Если бы я 5 лет назад почитал такой материал — я был бы уже существенно богаче!..
UPD: в статье добавил про смысл диверсификации, а то в комментариях много вопросов было…

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

Суть

Перец — такая глобальная случайная строка, которая дописывается ко всем паролям (помимо соли). Она секретна (в отличии от соли). Таким образом, получив базу, узнать пароли становится невозможно. И все, казалось бы, хорошо…

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

Подхожу к своему сотруднику — назовем его Серега:

— Серега, — говорю, — ты в какую сторону вообще хочешь развиваться: в техническую или в менеджерскую?

— Сань, ну голова варит уже не очень, возраст… (Серега старше меня на 3 года) Поэтому, наверное, в менеджерскую.

Ну, в менеджерскую — так в менеджерскую. Я ж на тот момент был менеджер опытный, уже 4 года опыта! Энергии много, желания помочь людям — через край!

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

А кончилось все тем, что пришлось нам с Серегой расставаться. Как так получилось, где Серега в итоге реализовал себя, и какой правильный управленческий инструмент я мог бы тогда применить — об этом сегодня и поговорим.

Заодно поговорим, что делать, если вы обнаружили себя и/или своих сотрудников в квадрате C в статье:

• Управленческие инструменты: Как играть в нелинейные шахматы

Наша команда занимается разработкой интерфейсов для четырех крупных проектов: Яндекс.Картинки, Яндекс.Видео и их версий для смартфонов. Разработка верстки поисковых сервисов в Яндексе обладает своей спецификой. Задачи стекаются с разных сторон: от менеджеров, разработчиков бэкэнда, поиска, проявляются баги и т.д. Внедряются новые фичи, требующие отображения в верстке. Все это стекается в наш таск-трекер (JIRA).

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



В конечном итоге большинство наших проблем удалось решить при помощи Agile Board и Scrum, но пришли мы к этому далеко не сразу, а поэтапно.

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

DISCLAIMER: более навороченной книги по ООП в природе нет и в ближайшее время, скорее всего, не будет; эта книга заслуженно считается классической книгой по объектной технологии и не зря является первой в списке рекомендуемых книг по этой теме (причем она первая не только в моем списке).

Основная сложность при изучении объектно-ориентированного программирования (или любой другой парадигмы программирования) заключается в том, что весьма сложно подобрать формальные критерии, которые бы сказали: «ок, теперь я знаю ООП и стану писать более клевые (читай модульные, реюзабельные и легкие в сопровождении) программы». Например, при изучении языков программирования мы относительно быстро замечаем, опа, level-up, я, кажись, перешел на новый уровень понимания идиом и конструкций языка программирования и могу использовать его более интересным образом, да еще и другим рассказывать, где они не правы.

Я получил образование по специальности «Электротехника» и единственными языками программирования, которые мы изучали были C/C++, ассемблер и Matlab. После того как я посетил Startup Weekend, я понял, что информатика и разработка программного обеспечения мне небезразличны и решил погрузиться в эти области с головой. Также я осознал, что мне требуется изучить еще несколько языков программирования, помимо тех, которые я изучал в университете.

За прошедшие полтора года я начал изучать Java (для Android), а также Python, JavaScript, HTML и CSS (для web-разработки) и выявил для себя, что лучший способ изучать язык программирования, разбирая книгу или туториалы, — читать все по три раза! Да, именно по 3 раза!!! Чтение нового материала подобным образом, хорошо помогло мне понять новые языки программирования и концепции.

Для тех, кому одного курса на праздники мало и кто хочет больше, продолжаем нашу серию курсов от Школы анализа данных Яндекса. Сегодня подошла очередь курса «Дискретный анализ и теория вероятностей» – даже более фундаментального, чем предыдущий. Но без него нельзя представить ещё большую часть современной обработки данных.

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



Читает курс Андрей Райгородский. Доктор физико-математических наук. Профессор кафедры математической статистики и случайных процессов механико-математического факультета МГУ им. М. В. Ломоносова. Заведующий кафедрой Дискретной математики ФИВТ МФТИ. Профессор и научный руководитель бакалавриата кафедры «Анализ данных» факультета инноваций и высоких технологий МФТИ. Руководитель отдела теоретических и прикладных исследований компании «Яндекс». (Ещё больше можно узнать в статье о нём на Википедии).

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

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

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

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

То есть, умный дом — это дом, который может все. А удобный дом — это дом, который все, что может, делает сам.

Давайте сначала я просто похвастаюсь тем, что умеет мой дом сейчас, а вы решите, имеет ли смысл читать про мой местами горький (а местами очень даже ничего) опыт дальше, ок?

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

Project Management Institute на прошлой неделе опубликовал результаты исследования зарплат руководителей проектов в 2013.

Слышали ли вы когда-нибудь в свой адрес упреки в неконструктивности? Может быть, сами кого-то упрекали? Как вы понимаете, что вот это конкретное обсуждение не конструктивно, а вот это конструктивно?

Если начать думать на эту тему, то тут есть на что потратить пару часов. Эту задачу мы сейчас постараемся облегчить. И в рамках нашей серии статей по управленческим инструментам (ушедшей в отпуск на время новогодних праздников), разберем принципы конструктива, предложенные когда-то Энди Гроувом, одним из основателей компании Intel.

Принципы простые, но объясняют довольно много рабочих и не только рабочих конфликтов. И разобравшись с ними вы:

• Поймете причины поведения своих коллег, руководства и заказчиков в некоторых ситуациях
• Занесете в свой арсенал несколько простых приемов, которые помогут вам легче договариваться по работе
• Сможете абсолютно точно объяснить любому коллеге, что он неконструктивен (и в чем именно), если он действительно неконструктивен

Здесь не будет полюбившихся нам матриц 2 на 2, но пару схем мы разберем.

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.