В ответ вот на эту статью, про выбор покупки серверов или оптимизации.

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

Как обычно происходит и почему

Действительно, существует такое распространенное мнение, что железо купить проще и надежнее, чем оптимизировать код.
Другой вопрос, а проводились ли достоверные исследования на эту тему? Думаю, нет, и это только подтверждает тезисы статьи «Программирование, как новый вид человеческой деятельности».

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

Информационная безопасность, пожалуй, остаётся одной из самых неблагодарных отраслей IT: специалистов по ней то подозревают в безделии, пока всё в порядке, то обвиняют в халатности, когда что-то случилось. Вся же работа по обеспечению information security часто сопровождается раздражённым отношением других сотрудников, которые воспринимают все мероприятия и требования безопасников как желание помешать всем остальным спокойно делать их работу.

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

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

Вчера мы опубликовали наш «Манифест работы с людьми» — 12 принципов, к которым мы пришли после 7 лет обучения умных людей тому, как работать с другими умными людьми.

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

Мысль пошла дальше и возникла идея сделать конкурс историй «Чему я научился у своих руководителей и коллег». Наверняка у вас есть свои поучительные истории из рабочей жизни. Истории, которые ВАС многому научили. Давайте ими поделимся?

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

Баста карапузики, кончилися танцы.

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

В статье будет показан перехват рукопожатия клиент-точка доступа, перебор паролей как с помощью ЦП, так и ГП, а кроме этого — сводная статистика по скоростям на обычных одиночных системах, кластерах EC2 и данные по разным типам современных GPU. Почти все они подкреплены моими собственным опытом.

К концу статьи вы поймёте, почему ленивый 20-значный пароль из букв a-z на пару солнц более стоек, чем зубодробительный 8-значный, даже использующий все 256 значений диапазона.

Оглавление:
1) Матчасть
2) Kali. Скрытие SSID. MAC-фильтрация. WPS
3) WPA. OpenCL/CUDA. Статистика подбора

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

Синоптики предсказывают, что к 2016 году наступит второй ледниковый период трафик в беспроводных сетях на 10% превзойдёт трафик в проводном Ethernet. При этом от года в год частных точек доступа становится примерно на 20% больше.

При таком тренде не может не радовать то, что 80% владельцев сетей не меняют пароли доступа по умолчанию. В их число входят и сети компаний.

Этим циклом статей я хочу собрать воедино описания существующих технологии защит, их проблемы и способы обхода, таким образом, что в конце читатель сам сможет сказать, как сделать свою сеть непробиваемой, и даже наглядно продемонстрировать проблемы на примере незадачливого соседа (do not try this at home, kids). Практическая сторона взлома будет освещена с помощью Kali Linux (бывший Backtrack 5) в следующих частях.

Статья по мере написания выросла с 5 страниц до 40, поэтому я решил разбить её на части. Этот цикл — не просто инструкция, как нужно и не нужно делать, а подробное объяснение причин для этого. Ну, а кто хочет инструкций — они такие:

Используйте WPA2-PSK-CCMP с паролем от 12 символов a-z (2000+ лет перебора на ATI-кластере). Измените имя сети по умолчанию на нечто уникальное (защита от rainbow-таблиц). Отключите WPS (достаточно перебрать 10000 комбинаций PIN). Не полагайтесь на MAC-фильтрацию и скрытие SSID.

Оглавление:
1) Матчасть
2) Kali. Скрытие SSID. MAC-фильтрация. WPS
3) WPA. OpenCL/CUDA. Статистика подбора

Недавно ребята из books.ru в очередной раз пополнили раздел электронных книг, предлагаемых по свободной цене. Акция продажи новых электронных изданий будет идти до 1 июня (судя по опыту прошлых акций свободная цена на некоторые книги сохранится и в будущем).

Но в любом случае, я бы не стал писать этот пост, если бы не увидел, что коллекция пополнилась настоящими бриллиантами. «Алгоритмы: построение и анализ (CLRS), 2-е издание» (Томас Х. Кормен, Чарльз И. Лейзерсон, Рональд Л. Ривест, Клиффорд Штайн) (читал эту книгу в печатном варианте и могу сказать, что перевод просто отменный). Искусственный интеллект: современный подход (AIMA-2), 2-е издание (Стюарт Рассел, Питер Норвиг).

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

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

Итак, что в принципе, должен делать (уметь делать) системный администратор:
Устанавливать/обновлять/удалять ПО
Настройку ПО
Планировать работы
Документировать
Мониторить состояние ИТ-систем
Диагностировать и поддерживать ИТ-системы
Резервное копирование/архивацию ПО и данных

Для всего этого есть немало различного ПО, постараемся описать все самое необходимое.

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

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

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

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

В этой статье мы расскажем о том, как можно получить спецификацию Linux-сервера в командной строке.

Тиффани Фаррант-Гонзалез и Джарред Ромли из компании JESS3 подробно расскажут вам о 10 основных шагах, необходимых для создания содержательной и привлекательной инфографики.

В прошлом году в Санкт-Петербурге прошла конференция бизнес и системных аналитиков в разработке ПО. Был там довольно интересный доклад минчан Марии и Сергея Бондаренко, под названием «Полезные навыки аналитиков. Как стать профессионалом». Ниже публикуем статью, сделанную на основе доклада.

Ларри Пейдж и Сергей Брин всерь­ез считали, что их компании управленцы незачем. В 2002 году они попытались выстроить горизонтальную оргструктуру — без менеджеров, руководящих программистами. Так, считали они, ничто не будет мешать быстрому обмену и появлению идей. Кроме того, им хотелось воссоздать ту атмосферу студенческой жизни, которая так нравилась им в университете. Эксперимент длился недолго: спустя несколько месяцев его пришлось прекратить. Брин и Пейдж изменили свое мнение о внутреннем устройстве компании, когда сотрудники валом повалили к Пейджу с вопросами, далекими от творчества: с финансовыми отчетами, жалобами друг на друга и т.п. А уж когда компания стала расти, ее основатели убедились, что управленцы полезны и в других отношениях: объясняют стратегию, значимость проектов и их очередность, налаживают сотрудничество в коллективе, следят за карьерным ростом людей и за тем, чтобы все рабочие процессы и системы соответствовали задачам бизнеса.

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

Страховая компания, оформляя полис, допустила ошибку в моих документах. Обнаружив ее, сотрудница пересчитала сумму и потребовала доплату в 10 тысяч. Если бы это произошло два-три года назад, я бы убеждал, волновался. Или просто заплатил. Сейчас же задал спокойно всего два вопроса, и полис мне оформили с новыми данными по прежней цене. Что помогло мне?

Моё хобби

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



Сделать первый шаг за стол переговоров было трудно. Это стресс. А когда были зрители, поединки приобретали особый накал. Но я справился и уже через полгода стал участвовать в турнирах, а вскоре и побеждать. Например, в 2011 и 2013 году становился победителем Московского открытого турнира по быстрой управленческой борьбе, в 2012 и 2013 завоевывал Осенний кубок Москвы в классической управленческой борьбе.

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

В этом посте хочется поделиться личным опытом создания продукта с нуля. Путь «а давайте запилим/скопируем и выкинем на рынок» мы уже проходили. Такой подход чуть не убил нашу компанию.



По статистике, около 50% фич среднестатистического продукта никогда не используются и только 12% опций клиенты используют активно. Как всегда попадать в эти 12% функционала? А что, если я сам не являюсь пользователем этого продукта? Как сделать продукт простым и удобным? Наконец, стоит ли его вообще делать нашей компании? И как понять, будет ли продукт востребован рынком еще до его создания?

Салют, хабровчане!


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

Добрый день.

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

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

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

Почему? Maxifier представляет собой SaaS-продукт с клиентами в США, Бразилии, в нескольких странах Европы и в Японии, так что у нас около сотни серверов, раскиданных по всему миру. Для оперативной работы нам необходимо иметь удобный доступ к логам наших приложений и быстрый поиск ошибок в них в случае проблем на сторонних сервисах/api, появления некорректных данных т.д. Кстати, похожей системой сборки логов пользуются The Guardian (одни из наших клиентов).

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

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



Чтобы объяснить, о какого рода доказательствах пойдет речь, рассмотрим пример: есть компьютерная программа, авторы которой утверждают, что программа делает что-то определенное (конкретные примеры будут чуть позже). Программу можно запустить и получить ответ. А как можно удостовериться, что программа делает то, что должна делать? Хорошо бы, если кроме ответа программа выдавала бы доказательство того, что этот ответ правильный.

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



Напомним, что граф называется двудольным, если его вершины можно покрасить в два цвета так, что ребра графа соединяют вершины разных цветов. Паросочетанием в графе называется такое множество ребер, что никакие два из них не имеют общего конца. Множество вершин графа называется покрывающим, если каждое ребро графа имеет как минимум один конец в этом множестве. Теорема Кенига гласит, что в двудольном графе размер максимального паросочетания совпадает с размером минимального покрывающего множества. Таким образом, чтобы доказать, что паросочетание является максимальным, можно предъявить, покрывающее множество, размер которого совпадает с размером данного паросочетания. Действительно, это покрывающее множество будет минимальным, поскольку каждое покрывающее множество обязано покрыть хотя бы один конец каждого ребра этого паросочетания. Например, в графе на рисунке паросочетание (M1, G3), (M2, G2), (M4,G1) будет максимальным, поскольку есть покрывающее множество размера 3, которое состоит из G2, G3 и M4. Отметим, что проверить такое доказательство гораздо проще, чем вычислять максимальное паросочетание: достаточно проверить, что размер паросочетания совпадает с размером покрывающего множества и проверить, что все ребра покрыты.

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



Как можно доказать правильность результата? Если система совместна, то доказательством совместности может стать решение этой системы (нетрудно доказать, что если у такой системы есть решение, то есть и рациональное решение, т.е. его можно записать). А как доказать, что система несовместна? Оказывается, что это сделать можно с помощью леммы Фаркаша, которая утверждает, что если система нестрогих линейных неравенств несовместна, то можно сложить эти неравенства с неотрицательными коэффициентами и получить противоречивое неравенство 0≥1. Например, система на рисунке несовместна, и если сложить первое уравнение с коэффициентом 1, второе с коэффициентом 2, а третье с коэффициентом 1, то получится 0≥1. Доказательством несовместности будет как раз набор неотрицательных коэффициентов.

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

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

Я видел много примеров, где для совместной разработки использовали dropbox, для отладки приложения после каждой строчки вставляли print, для автоматических тестов писали свои велосипеды (признаюсь, я и сам все это делал).

Это не правильно!

Сейчас в распоряжении программиста, пишет он на Python, C++, Haskell или Ruby, есть огромное количество различных инструментов, которые он может использовать в повседневной разработке.

Компиляторы, интерпретаторы, отладчики, профилировщики, генераторы документации, системы контроля версий, текстовые редакторы, автоматизаторы сборки, статические анализаторы, эмуляторы и виртуальные машины — все это в нашем распоряжении!

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

Если вам интересно, как улучшить свою продуктивность, начать писать программы лучше, да и просто почитать что-то интересное — добро пожаловать под кат!

Добрый день, уважаемые коллеги. В этой статье я бы хотел рассказать о своем аналитическом понимании различий паттернов MVC, MVP и MVVM. Написать эту статью меня побудило желание разобраться в современных подходах при разработке крупного программного обеспечения и соответствующих архитектурных особенностях. На текущем этапе своей карьерной лестницы я не являюсь непосредственным разработчиком, поэтому статья может содержать ошибки, неточности и недопонимание. Заинтригованы, как аналитики видят, что делают программисты и архитекторы? Тогда добро пожаловать под кат.