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

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

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


Посмотрите или прочитайте доклад Алексея Катаева на Saint TeamLead Conf, если не знаете, по каким формальным признакам определить классная ли у вас команда. Если хотите уметь измерять технический долг в часах, а не оперировать категориями «совсем чуть-чуть», «сколько-то», «ужасно много». Если ваш продакт-менеджер считает, что команда из трех человек за месяц сделает 60 задач — покажите ему эту статью. Если ваш руководитель обвешал разработку метриками и предлагает вам принимать меры на основе результатов вроде: «34% считают, что в команде есть проблема с планированием», этот доклад для вас.

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

Данная статья написана, в первую очередь, для начинающих руководителей. Надеюсь, их более опытные коллеги также найдут что-то интересное для себя. Повторение – мать учения!

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

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

Современная DDR3 SDRAM. Источник: BY-SA/4.0 by Kjerish

Во время недавнего посещения Музея компьютерной истории в Маунтин-Вью моё внимание привлёк древний образец ферритовой памяти.


Источник: BY-SA/3.0 by Konstantin Lanzet

Всем привет! Я работаю в Veeam над проектом Veeam Agent for Linux. С помощью этого продукта можно бэкапить машину с ОС Linux. «Agent» в названии означает, что программа позволяет бэкапить физические машины. Виртуалки тоже бэкапит, но располагается при этом на гостевой ОС.

Вдохновением для этой статьи послужил мой доклад на конференции Linux Piter, который я решил оформить в виде статьи для всех интересующихся хабражителей.

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

Всех заинтересовавшихся прошу под кат!

В начале года мы решили научиться хранить и читать отладочные логи ВКонтакте более эффективно, чем раньше. Отладочные логи — это, к примеру, логи конвертации видео (в основном вывод команды ffmpeg и список шагов по предварительной обработке файлов), которые иногда бывают нам нужны лишь спустя 2-3 месяца после обработки проблемного файла.

На тот момент у нас было 2 способа хранения и обработки логов — наш собственный logs engine и rsyslog, которые мы использовали параллельно. Стали рассматривать другие варианты и поняли, что нам вполне подходит ClickHouse от Яндекса — решили его внедрять.

В этой статье я расскажу о том, как мы начали использовать ClickHouse ВКонтакте, на какие грабли при этом наступили, и что такое KittenHouse и LightHouse. Оба продукта выложены в open-source, ссылки в конце статьи.

Меня зовут Роб Стакл, я консультант по безопасности из Феникса, штат Аризона, и в основном работаю пентестером. Я участвую в конференциях DefCon с 1996 года, увлекаюсь высотной фотографией, а в эти выходные была одиннадцатая годовщина нашей свадьбы. Я хочу поблагодарить мою удивительную и понимающую жену Линду, которая не ожидала, что моё участие в DefCon означает, что каждый год я буду вынужден проводить годовщину нашей свадьбы в Вегасе, о чём я очень сожалею.



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

Конференция DEFCON 21. DNS может быть опасен для вашего здоровья. Часть 1

При этом предполагалось, что границы домена организации – это foo.com и вы никогда не захотите использовать www.com. Microsoft изменила это поведение DNS, потому что, очевидно, не все организации имеют два уровня для доменных имён.



Если ваш домен верхнего уровня – Великобритания, то при соединении с конкретным доменом ad.foo.co.uk поведение DNS по умолчанию будет выглядеть так:



То есть запрос будет отсылаться за границы вашего доменного имени на www.co.uk. Поэтому был создан случайный хотфикс, исправление безопасности, сужающее организационные границы домена до 3-х, и в этом случае деволюция DNS останавливалась после второго запроса www.foo.co.uk.

Доклад Никиты Налютина на конференции SQA Days – 13, 26-27 апреля 2013 г. Санкт-Петербург, Россия

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

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

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

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

Deleted Deleted

В этой статье пойдёт речь о том, как реализован словарь в Python. Я постараюсь ответить на вопрос, почему элементы словаря не упорядочены, описать, каким образом словари хранят, добавляют и удаляют свои элементы. Надеюсь, что статья будет полезна не только людям, изучающим Python, но и всем, кто интересуется внутренним устройством и организацией структур данных.

Создание пакетов или packet crafting — это техника, которая позволяет сетевым инженерам или пентестерам исследовать сети, проверять правила фаерволлов и находить уязвимые места.
Делается это обычно вручную, отправляя пакеты на различные устройства в сети.
В качестве цели может быть брандмауэр, системы обнаружения вторжений (IDS), маршрутизаторы и любые другие участники сети.
Создание пакетов вручную не означает, что нужно писать код на каком-либо высокоуровневом языке программирования, можно воспользоваться готовым инструментом, например, Scapy.

Scapy — это один из лучших, если не самый лучший, инструмент для создания пакетов вручную.
Утилита написана с использованием языка Python, автором является Philippe Biondi.
Возможности утилиты практически безграничны — это и сборка пакетов с последующей отправкой их в сеть, и захват пакетов, и чтение их из сохраненного ранее дампа, и исследование сети, и многое другое.
Всё это можно делать как в интерактивном режиме, так и создавая скрипты.
С помощью Scapy можно проводить сканирование, трассировку, исследования, атаки и обнаружение хостов в сети.
Scapy предоставляет среду или даже фреймворк, чем-то похожий на Wireshark, только без красивой графической оболочки.
Утилита разрабатывается под UNIX-подобные операционные системы, но тем не менее, некоторым удается запустить ее и в среде Windows.
Эта утилита так же может взаимодействовать и с другими программами: для наглядного декодирования пакетов можно подключать тот же Wireshark, для рисования графиков — GnuPlot и Vpython.
Для работы потребуется права суперпользователя (root, UID 0), так как это достаточно низкоуровневая утилита и работает напрямую с сетевой картой.
И что важно, для работы с этой утилитой не потребуются глубокие знания программирования на Python.

Привет, Хабр!

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




Во-первых, появилась возможность поиска по цене за 3, 6 или 12 месяцев. Очень часто хостеры делают скидки при длительной оплате, поэтому уже сейчас можно указывать период, за который вы хотите произвести оплату и минимальное и максимальное значение цен. При этом, в информации о тарифе будет отображаться общая цена за указанный период.

Не прошло и 40 лет, как компания Microsoft решила открыть для публики исходный код MS-DOS v1.1 и v2.0, а также одной из первых версий Word for Windows 1.1a. Сказать спасибо за это надо The Computer History Museum и Microsoft Research.

Ссылки:
MS-DOS v1.1 & v2.0
Word v1.1a

Зеркало [mega]
Зеркало [sendspace]

Согласно пресс-релизу, оба программных продукта стали краеугольным камнем в жизни компании, заложив основу ее коммерческого успеха. Исходный код MS-DOS v1.1 относится к 1982 году, v2.0 — к 1983. Кстати, в версии 1.1 вся операционная система умещалась в 12 килобайтах памяти — что, конечно, несравнимо с сегодняшними «монстрами».

Версия Word для DOS, выпущенная в 1983 году, особого успеха не снискала, проиграв лидеру рынка на тот момент — процессору по имени WordPerfect. Зато выпуск в 1989 году Word для Windows изменил все — за четыре года этот программный продукт сумел захватить более половины доходов всего рынка текстовых процессоров, что стало впечатляющим успехом работы маркетингового отдела и инженеров компании.

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

Последнее время в Сети активизировалось брожение вокруг космических изысканий. И это понятно, то там новые солнечные батареи изобрели, с удивительным КПД, то здесь микроспутники стандартизировали и Arduino в космос запустили, то то, то это. А когда Curiosity удачно примарсился и стал передавать изображения, тут уж сам Бог велел общественности взорваться в обсуждениях.
И это закономерно, назрело уже, так сказать. Больно уж много времени прошло с полета первого спутника, первого человека и высадки на луну. А воз, как говорится, и ныне там. Кардинально нового в космической отрасли ничего не произошло, никаких громких прорывов, только улучшения и улучшения… Отсюда и повышенный интерес к теме, люди чувствуют, что пришло время для новых свершений.

Далее прошу под кат, будет много эмоций и фотографий.

Осторожно, трафик! Но можно хотя бы посмотреть картинки )

   Идея создать дома свой «рабочий кабинет» у меня зрела давно – как-то сам дошел до осознания его необходимости, хотя немалый вклад в начинания сделал этот давний пост на Хабре. У меня было своё рабочее место – большой удобный стол, где помещалось практически всё и даже больше… но, по сути, он был проходным двором – все время кто-то ходил, был рядом, отвлекал… такое очень часто мешает сосредоточиться и начать работать. Иногда, бывает, сидишь весь вечер за компом и понимаешь, что абсолютно ничего не сделал, хотя родным заявил «так, мне надо поработать».

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

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

Это вольный перевод-пересказ этой статьи 2006 года, на которую я наткнулся около mailinator.com, за авторством Paul Tyma. Упоминаний на хабре не нашел, да будет перевод!

Итак, у вас есть отличная идея.

За годы работы я запустил небольшую кучку проектов и создал несколько компаний. Например Mailinator, Preemptive Solutions, Inc., и Classhat. На самом деле я наделал их гораздо, гораздо больше, но про большинство слышала разве что моя бабушка. Всё потому, что преимущественно это были глупые идеи, неудачные попытки что то сделать, или чересчур масштабные начинания, чтобы я мог довести их до релиза. Поучившись на своих ошибках, я теперь каждую новую идею проверяю на соответствие определённому набору правил, чтобы отсеять хорошие идеи от плохих. Ну или тех, которые мне кажутся таковыми.
Не забывайте, эти правила для канонічного стартапа — когда из сотрудников только вы и ваш друг, а денег — на пиво и чипсы. Если у вас в загашнике завалялись лишние пару миллионов — вы можете творить магию и без этих советов.

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

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис