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

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



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

Мы уже писали о том, как справиться с останавливающими нас на пути к достижению своих целей страхом и прокрастинацией. Однако после того, как мы вышли из “мёртвой зоны” бездействия и замотивировали себя на результат, мы можем впасть в другую крайность: после длинного 8-12 часового рабочего дня не получается сказать, что же, собственно, удалось сделать. И главное – какой результат от приложенных усилий мы получили? Продвинул ли он нас к поставленным целям?

В результате легко обнаружить себя в ситуации, когда “крутишься как белка в колесе”, а дела словно стоят на месте. Копится только усталость. Ощущения от достигнутых высот так и не появляется.

Ранее мы переводили и публиковали статью, в которой попытались раскрыть секреты успеха Dropbox. Судя по количеству просмотров, тема оказалась востребованной. Поэтому мы решили перевести еще одну статью о компании, которая для многих, и для нас в том числе, является эталоном в определенных сферах. Итак, у Amazon 237 миллионов активных клиентов. Если бы все они жили в одной стране, то она была бы четвертой в мире по населению. В США, например, Amazon владеет 30% рынка электронной коммерции, – такой рынок, даже при всем желании, не назовешь нишевым.

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

Разбираясь с новым Visual C# 2008 (он настолько бесплатный для начинающих разработчиков, что я не удержался), нашел новое для себя слово в науке и технике — GUID.

Привожу пример интересной, как мне кажется, статьи, призывающей использовать глобально-уникальные идентификаторы во всех сферах народного хозяйства. Статья, в основном про .NET и прочий микрософт, но, думаю, будет полезна многим здесь, ибо реализации GUID есть почти во всех современных БД и языках (включая mySQL и PHP ;).

ПС: Если будет интересно, то выложу перевод второй части, где автор отвечает на комменты к первой статье.

Я собираюсь сделать Java-веб-приложение (да, это будет Java, по некоторым причинам, которые сейчас озвучивать не хочу). В процессе работы, я оцениваю кучу J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container фреймворков.

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

Давайте представим, что я решил сделать шкафчик для специй.

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

Мой рассказ будет о том, как я, превозмогая трудности, решал задачу формирования новостной ленты. А также я расскажу о подходах, которые наработали ребята из проекта Socialite, и которыми они поделились на MongoDB World.

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

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

Хвост виляет собакой. ("Wag the dog") — чтобы избежать большого скандала или «замять», оставить незамеченным какое-нибудь важное, но неприятное событие, часто используется простой, но хитрый и ловкий приём, который англоязычные политтехнологи называют «Wag the dog», а русскоязычные — «Хвост виляет собакой». Он заключается в том, чтобы вовремя поднять волну обсуждения вокруг вопроса второстепенной важности, на фоне которой другое, более важное событие или действие пройдёт незаметно.
Примеры таких вопросов: Отмена перехода на зимнее время, российское гражданство Депардье, поездка Путина или Саши Грей на Ладе Калине по России, полёты со стерхами и т.д.
Своё название этот приём получил в честь английского выражения tail wagging the dog, который, в свою очередь, появился из следующего народного пассажа:

— Почему собака виляет хвостом?
— Потому, что собака умнее, чем хвост. Если бы хвост был умнее, он вилял бы собакой.

В прошлой статье мы уже рассказывали о новой NLP библиотеке. Однако тогда мы рассказали «обовсем» и не о чем конкретном. Сегодня мы поговорим о теоретических аспектах разбития предложения на токены лингво-независимыми алгоритмами. Теоретические выкладки будут подкреплены практической реализацией в библиотеке AIF. Поехали…

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

Мы (@ali_aliev и avenat) с удовольствием представляем вашему вниманию перевод интерактивного учебника «Problem Solving with Algorithms and Data Structures» от Брэда Миллера (Brad Miller) и Дэвида Ранума (David Ranum) из Luther College, что в Айове, США.

О чём?

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

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

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

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

Привет, меня зовут Михаил Ройзнер. Недавно я выступил перед студентами Малого Шада Яндекса с лекцией о том, что такое рекомендательные системы и какие методы там бывают. На основе лекции я подготовил этот пост.

План лекции:

1. Виды и области применения рекомендательных систем.
2. Простейшие алгоритмы.
3. Введение в линейную алгебру.
4. Алгоритм SVD.
5. Измерение качества рекомендаций.
6. Направление развития.

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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

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

Под катом — 5 первых названий с описаниями от меня, для затравки.
update 1. В комментариях ещё 10+ названий.

– Папа, а идеальное собеседование существует?
– Нет, сынок, это фантастика.
(с)

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

Я руководитель отдела разработки 1С. В моём подчинении 4 разработчика и 3 специалиста поддержки. Звезды сложились так, что я решил уйти из компании. Подписал заявление, договорился о двух неделях отработки. HR напрягся, бросился искать замену, но скорей всего за 2 недели никого они найти не смогут и у меня встал вопрос, что нужно сделать, чтобы уйти «красиво», так, чтобы человек, который заменит меня смог как можно более безболезненно войти в курс дел. Размышления вылились вот в такой список.

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

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

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

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

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

После прочтения статьи Gephi как средство визуализации данных я оказался под сильным впечатление от программы Gephi. На тот момент я занимался генерацией логов активности пользователей в Google+. И меня посетила идея, а может быть сделать граф отношении между участниками соц. сети Google+. После нескольких часов поисков пришел к выводу, что подобных вещей еще не сделано для Gephi. Даже в wiki gephi алгоритма формирования графа для Google+ не предложено. И на волне вдохновения быстренько дописал в приложении LoggenCSG модуль выгрузки лога в файл бд sqlite, который умеет импортировать Gephi. Результаты импорта графа в Gephi мне очень понравились.
Косвенные отношения между пользователями через их активности.


Прямые связи между пользователями через их активности.

Дальше пойдет описание того как самостоятельно построить подобные графы.