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

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

Всех людей можно разделить на две категории: кто уже менял работу и кто будет менять работу. Дело это нечастое, ответственное, а потому требует от человека как минимум решимости, а как максимум — особых интеллектуальных усилий, чтобы взвесить все ЗА и ПРОТИВ (если вы не планируете сразу после перехода заняться поисками нового места). За 6 лет стажа я менял место работы всего один раз и хочу поделиться теми мыслями, которые у меня возникли в процессе этого перехода.

Понедельник. Постановка задачи

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

«Две тропинки идут рядом: путь жизни и путь смерти… Люди не идут никаким путём, ни путём жизни, ни путем смерти. Вихрь носит их, как солому.»
Густав Майринк, «Голем»

В офисе было тихо и темно, лишь стук клавиш и редкие щелчки мыши нарушали едва различимое жужжание кулера, да широкоформатный монитор освещал измождённое лицо regular developer'а Миши. Сторонний наблюдатель мог бы подумать, что идёт обычная рабочая ночь с пятницы на субботу. Так оно и было для тысяч других разработчиков по всему миру, но только не для Миши. Поставив очередную пустую бутылку под стол, он внезапно почувствовал, что граница, отделяющая его от гордого титула «senior developer», не так уж и далека.

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

Миша сглотнул и тихо спросил дрожащим голосом:

— Тим-лид Коля? Проджект-менеджер Изя? Рабочий день уже давно закончился, что вы здесь делаете? И к чему весь этот маскарад?

Не так давно увидел свет еще один документальный фильм о демосцене под названием «The Art Of The Algorithms».



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

Главная страница фильма: Moleman 2. На ней можно скачать фильм в различных форматах с помощью торрента/HTTP/FTP.

Хотелось бы немного рассказать о подходе повествования в данном посте. Всё описанное имеет реальные случаи произошедшие из моей личной практики, в большинстве своём это популярные проекты, поэтому в тексте буду их упоминать. Главное на что я хотел бы обратить внимание — эта статья может показаться не интересной специалистам ИБ, т.к. она не содержит никаких новых векторов атаки и супер крутых подходов. Вся информация ориентирована на разработчиков и проект-менеджеров.
Проводя заказы на аудит целью ставится аналитика максимального ущерба при минимальных действиях и знаниях злоумышленника. Как показывает практика в суровых условиях производства ПО такие нюансы продумывают единицы проектов.



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

• Контрольный вопрос — ответ
• Уникальная ссылка на email
• Отсылка нового/действующего пароля на email
• SMS OTP (One-time password)

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

И так, рассмотрим слабые места каждого из пунктов выше.

В октябре я уже рассказывала о способах оценки тестирования, все страждующие и сочувствующие могут посмотреть запись здесь. А сегодня мне захотелось затронуть тему метрик проекта в целом, причём метрик не «длягалочных», а метрик «пользуприносящих» и «проектыулучшающих». Именно поэтому, вместо сухих формул и перечня метрик, я расскажу 3 истории из опыта о внедрении и использовании строго определённых метрик в строго определённых условиях — и о результатах, которые с их помощью удалось достичь.

Зачем что-либо измерять?

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

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

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

А если не приходят, значит метрику можно смело выбросить ;)

_{Две недели назад на Хабре публиковался перевод «Заблуждения программистов о времени», который по своей структуре и стилю основан на этом классическом тексте Патрика Макензи, опубликованном два года назад. Поскольку заметка о времени была крайне благоприятно воспринята аудиторией, то, очевидно, имеет смысл перевести и исходную статью об именах и фамилиях.}

Джон Грэхем-Камминг (John Graham-Cumming) сегодня жаловался в своём блоге, что компьютерная система, с которой он работал, не приняла его фамилию из-за недопустимых символов. Конечно, там нет недопустимых символов, потому что любой способ, как человек представляет себя, — по определению — является подходящим идентификатором. Джон выразил сильную досаду насчёт данной ситуации, и он имеет полное право, потому что имя — суть нашей индивидуальности, практически по определению.

Существует стереотип, что «IT»-шник должен сидеть в полумраке, освещаемый лишь светом монитора. Не знаю как вам, а мне всегда было комфортнее при ярком освещении. Сначала это было 3x100W обычных лампочек, потом 250W люминесцентных ламп, после последнего переезда — одна 500W галогенка… Но этого все-же было недостаточно. Всегда хотелось иметь такое освещение, чтобы не хотелось свет сделать ярче. О создании такой люстры я сейчас и расскажу.

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

• когда клиент и сервер общаются в доверенной (локальной) сети;
• клиент и сервер взаимодействуют через глобальную, незащищенную сеть.

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

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

Недавно я делал ремонт в квартире и решил проверить, есть ли шанс при текущем уровне развития беспроводного оборудования организовать в квартире полноценную скоростную беспроводную сеть. Изначально задача казалась нецелесообразной (в домашних условия вполне успешно можно использовать Ethernet, зачем заморачиваться с WiFi?), но убедив себя, что беспроводные технологии не стоят на месте, я решил устроить себе небольшое испытание. Одним из основных критериев успеха была возможность просмотра на плазменной панели HD-видео рипов объемом от 10 до 30 ГБ в условиях, когда между хранилищем файлов и проигрывающим устройством отсутствует проводная сеть. Кому любопытно, удалось ли это осуществить и каким образом, прошу под кат! ;)