Всем привет. Меня зовут Борис, уже несколько лет я увлекаюсь теорией обучения и запоминания — тем, как работает мозг с новой информацией. Сегодня я поделюсь своим способом читать книги.

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

Алгоритм для обычных книг

Всё очень просто:

1. Читаем автора и название;
2. Задаем вопросы, ответы на которые мы хотим найти в книге;
3. Пролистываем: разглядываем картинки, цитаты;
4. Читаем содержание, оглавление, аннотации;
5. Читаем книгу (чем быстрее, тем лучше);
6. Выделяем основную тему;
7. Выделяем факты и новизну;
8. Пролистываем книгу;
9. Опционально: записываем в табличку в экселе, о чем книга, кто ее посоветовал, стоит ли перечитывать и почему.

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

Увы, читать таким способом книгу Дэвида Флэнэгэна «JavaScript. Подробное руководство, 6-е издание» или ng-book бессмысленно и бесполезно. В голове не останется ничего, а время потеряется. И вообще, техника скорочтения для подобных книг скорее вредна, чем полезна.

В последние два месяца лета в управлении хранилищ данных (Data Warehouse, DWH) Тинькофф Банка появилась новая тема для кухонных споров.

Всё это время мы проводили масштабное тестирование нескольких in-memory СУБД. Любой разговор с администраторами DWH в это время можно было начать с фразы «Ну как, кто лидирует?», и не прогадать. В ответ люди получали длинную и очень эмоциональную тираду о сложностях тестирования, премудростях общения с доселе неизвестными вендорами и недостатках отдельных испытуемых.

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

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

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


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

Уже несколько лет дата-центры многих компаний работают с вычислениями с ускорением на GPU. Наша компания сейчас изучает этот вопрос, поскольку такой тип вычислений становится все более востребованным. Так, вычисления с ускорением на GPU можно (и нужно) использовать для ускорения требовательных к ресурсам приложений, созданных для работы в таких сферах, как глубокое обучение, аналитика и проектирование. Этот метод используют в дата-центрах крупных компаний, в лабораториях научно-исследовательских организациях, на предприятиях.

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

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

(Заранее извиняюсь за обилие английских слов, какие-то из них я не знаю как перевести, а какие-то мне переводить не хочется.)

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

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

Помимо статей о непосредственно программных продуктах и методах их внедрения, я также интересуюсь и другими аспектами бизнеса. Как консультант я изучил работу значительного числа компаний, которые работают в самых разных сферах. И по этому вопросу я также пишу статьи. Я изучал причины неудач, и написал статью “Как теряют бизнес”, изучал методы злоупотребления в различных компаниях, и также написал статью в помощь бизнесменам “10 способов злоупотребления сотрудниками своим служебным положением и методы борьбы с ними с помощью учетной системы”, есть у меня и статьи, посвященные сложностям сотрудничества IT-компаний и бизнеса, например, “Посредники или почему в России всегда «виноват» исполнитель на примере IT проекта”, а также описания негативного влияния на бизнес злоупотреблением дружескими и родственными связями “Родственники и друзья в бизнесе”.

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

Продолжение предыдущих публикаций «Инструменты DataScience как альтернатива классической интеграции ИТ систем» и
«Экосистема R как инструмент для автоматизации бизнес-задач».
Настоящая статья является ответом на возникшие вопросы по пакетам R, которые полезны для реализации описанных подходов. Я ее рассматриваю исключительно как справочную информацию, и отправную точку для последующего детального изучения заинтересовавшимися, поскольку за каждым пакетом скрывается огромное пространство со своей философией и идеологией, математикой и путями развития.

Как правило, все пакеты (9109 штук на 07.09.2016) находятся в репозитории CRAN. Те, что по тем или иным причинам, пока не опубликованы в репозиторий, могут быть найдены на GitHub. Итак, кратким списком:

В настоящий момент уже можно считать, что страсти по Big Data и Data Science немного утихли, а ожидание чуда, как обычно, было сильно скорректировано реальностью физического мира. Самое время заняться конструктивной деятельностью. Поиск тем на Хабре по различным ключевым словам выдал крайне скудный набор статей, поэтому я решил поделиться тем опытом, который был накоплен в части практического применения инструментов и подходов Data Science для решения повседневных задач в компании.

Один из аспектов профессии разработчика — посвящение профанов в особенности процесса разработки ПО.
С. Макконнелл, Совершенный код

Цель этой публикации — поделиться опытом работы над проектом со сложной историей и тяжёлым наследием. После ухода из очередного т.н. «стартапа», я решил что хочу попробовать новых ощущений: enterprise, legacy, etc. Для этого взялся за работу над корпоративным приложением для транснационального концерна. Разработка на тот момент шла уже третий год, приложение пережило несколько поколений разработчиков, но стабильного релиза так и не было.

Полагаю публикация будет полезной:

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

Затрагиваемые в статье вопросы:

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

Давайте разберём уровни зрелости ИТ-процессов на примере управления инцидентами. Это всё то, что сыплется на ИТ-отдел в виде тикетов от пользователей, шефа, текущих задач и всего, что надо сделать. Забегая чуть вперёд, скажу, что в среднем по стране у крупного бизнеса с инцидентами довольно хорошо, в большинстве случаев это 4-й уровень. Ну просто потому, что работа со сбоями — это первое, по чему судят об ИТ-отделе.

Первый уровень — это когда:

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

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

Привет! Это пятый с 2010 года список полезных книг. Набралась всего дюжина за два года. Смотрите, что можно скачать в дорогу или просто почитать, когда будет время, и делитесь, пожалуйста, в комментариях своими (я буду поднимать их в пост). В этой подборке довольно много социнжиниринга, точнее, тем около него. Поехали.

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

Evil by Design, Крис Ноддер
Один из лучших подходов к проектированию чего-то хорошего — это спроектировать сначала самое ужасное из возможного. Пользователь обычно не скажет, как сделать ему хорошо, но точно знает, как бывает плохо. Например, юзер не говорит «я хочу, когда нажимаю на ссылку напоминания пароля, там в поле уже была введена почта», зато вполне способен сказать: «слушай, меня дико бесит, когда логинишься, тебе показывают новую страницу про то, что пароль не подошёл, и, чтобы его восстановить, надо ещё один долбанный раз вводить почту». Вся книга Криса состоит из таких «тёмных» шаблонов, когда какие-то гады намеренно вводят вас в заблуждение. Он там очень переживает за этику, поэтому вступления лучше пропустить. Единственная в этом обзоре книга на английском, но довольно простом.

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

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

Теперь посмотрим на сам процесс продажи. Он делится на пять шагов — приветствие, засада, разработка, презентация, продажа. Самая частая ошибка приветствия в том, что продавец, скорее всего, не доктор. Поэтому «Вам чем-нибудь помочь?» — это где угодно, но только не в стенах нашего магазина. Правильно улыбнуться и поздороваться с человеком, когда он заходит на точку. Задать настроение и обозначить, что вы его увидели. И всё. Не лезть к нему и не подходить даже. Человек зашёл — не надо набрасываться.

Хотя нет, прежде чем переходить к пунктам, обсудим подготовку.

Главный наш принцип в отношении покупателя — относиться к нему как к другу. Это не красивые слова, а одна предельно конкретная вещь — не делай ничего такого, что не сделал бы с другом.

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

Прошло чуть больше недели с окончания Чемпионата Европы 2016 во Франции. Этот чемпионат запомнится нам неудачным выступлением сборной России, проявленной волей сборной Исландии, потрясающей игрой сборных Франции и Португалии. В этой статье мы поработаем с данными, построим несколько графиков и отредактируем их в векторном редакторе Inkscape. Кому интересно — прошу под кат.

Статья была опубликована на smashingmagazine автор статьи Scott Lewis.

Найти недорогие качественно сделанные иконки и векторные изображения не составляет труда – именно для этого есть такие веб-сайты, как Iconfinder (где работает автор настоящей статьи). В распоряжении дизайнеров тысячи наборов иконок премиум класса, и сотни наборов доступны для бесплатного скачивания.

В данной статье приводится руководство по дизайну векторных иконок, которое включает в себя шесть этапов. Мы рассмотрим эти этапы после того, как разберем основные принципы успешного дизайна иконок. Эти принципы хорошо известны и подробно рассмотрены в таких работах, как Руководство по дизайну иконок Джона Хикса, а также в руководстве от Google Материальный дизайн в разработке системных иконок. Шесть этапов, которые мы будем рассматривать в данной статье, должны восприниматься, как рекомендации, а не как догмы. Способность чувствовать, где нужно следовать правилам, а когда их лучше нарушить – это важное качество, которое должен развить в себе каждый хороший дизайнер, и мы наглядно это продемонстрируем.

Представьте, что у вас есть класс:

class MyCounter(object):
    def __init__(self):
        self.__counter = 0
    def incCounter(self):
        self.__counter += 1
    def getCounter(self):
        return self.__counter

И вы хотите сделать его распределённым. Просто наследуете его от SyncObj (передав ему список серверов, с которыми нужно синхронизироваться) и отмечаете декоратором @replicated все методы, которые изменяют внутреннее состояние класса:

class MyCounter(SyncObj):
    def __init__(self):
        super(MyCounter, self).__init__('serverA:4321', ['serverB:4321', 'serverC:4321'])
        self.__counter = 0
    @replicated
    def incCounter(self):
        self.__counter += 1
    def getCounter(self):
        return self.__counter

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

Думаю, нет нужды рассказывать хабрапользователю что такое Git / GitHub, pre-commit и как наносить ему hook справа. Перейдем сразу к делу.

В сети много примеров хуков, большинство из них на shell'ах, но ни один автор не уделил внимание одному важному моменту — хук приходится таскать из проекта в проект. На первый взгляд — ничего страшного. Но вдруг появляется необходимость внести изменения в хук, который уже живет в 20 проектах… Или внезапно нужно переносить разработку с Windows на Linux, а хук на PowerShell'е… Что делать? ??????? PROFIT…

«Лучше так: 8 пирогов и одна свечка!»

Примеры, конечно, сильно утрированы, но с их помощью выявлены неудобства, которых хотелось бы избежать. Хочется, чтобы хук не требовалось таскать по всем проектам, не приходилось часто «допиливать», но чтобы при этом он умел:

• выполнять проверку отправляемого в репозиторий кода на валидность (например: соответствие требованиям PEP8, наличие документации итд);
• выполнять комплексную проверку проекта (юнит-тесты итд);
• прерывать операцию commit'а в случае обнаружения ошибок и отображать подробный журнал для разбора полетов.

И выглядел приблизительно так:

python pre-commit.py --check pep8.py --test tests.py

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

UPD: Продолжение статьи по ссылке — habrahabr.ru/company/avito/blog/322510

О чем статья

Незаметно пролетел год, как начались работы по разработке и внедрению хранилища данных на платформе Вертика.
На хабре уже есть статьи про саму СУБД Вертика, особенно рекомендую эту: HP Vertica, первый запущенный проект в РФ, ведь ее автор очень помог нам на начальном этапе. Алексей, спасибо еще раз.
Хотелось бы рассказать о том, какая методология применялась для проектирования физической структуры хранилища, чтобы наиболее полно использовать возможности HP Vertica.
Эту статью хотел бы посветить обоснованию оптимальности выбранной методологии, а в следующей — рассказать о том, какие техники позволяют анализировать данные, содержащие десятки млрд.

Постановка задачи

Рассмотрим высоконагруженный сайт крупной российской интернет-компании (теперь можно — это Авито ;)).
Деятельность компании описывается следующими цифрами: ~ 10 млн. активных пользователей, ~100 млн. просмотров страниц в день, около 1 тыс. новых объектов, размещенных пользователями на сайте в течение 1 минуты, ~10 тыс. поисковых запросов пользователей в минуту.
Грубая оценка количества действий, подлежащих сохранению в хранилище, составляет 100 млн. новых записей в сутки (~100 GB новых данных в сутки).
Т.е. при построении классического хранилища данных с отказом от стирания поступивших ранее данных, объем хранилища через 3 месяца эксплуатации составит 10TB сырых данных. Big Data как она есть.
Нужно построить хранилище, которое хранило бы не меньше 6 месяцев данных, позволяло их анализировать, визуализировать, и отставало бы от реальной жизни настолько мало, насколько это возможно (в худшем случае — отставало бы на день, в лучшем — на минуты).
Вынося сразу за скобки вопрос выбора платформы — хранилище должно работать на HP Vertica, MPP базе колоночного хранения, см. вводную статью в заголовке.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

_{Grimoire ensorcele by naiiade}

Любую достаточно развитую технологию можно сравнить с оружием: когда у врага есть ружье, а у тебя нет, поневоле хочется изменить баланс сил в свою пользу. В области IT-безопасности знания, передаваемые различными способами, и есть то самое оружие, использование которого ограничивается не столько нормами УК, сколько этическим выбором.

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

Вы наверняка слышали, что недавно вышел новый релиз IaaS-платформы OpenStack — OpenStack 13 «Mitaka». Это хороший повод написать небольшой анализ-сравнение OpenStack с каким-нибудь более ранним проектом и выяснить, что же сделало OpenStack настолько успешным.

Идея этого поста — в одном из моих предыдущих переводов, где были перечислены проблемы, с которыми сталкиваются компании, пытающиеся вести бизнес на Open Source. А если точнее, о проблемах писал руководитель компании XenSource, и в первую очередь, про проект Xen. Там была такая фраза: «Если вы думаете, что это всё осталось в прошлом и сейчас уже не актуально, я вам скажу, что вижу похожую ситуацию, происходящую сегодня с OpenStack, и такое, вероятно, происходит со многими другими успешными open source проектами.»

Давайте посмотрим, о каких трудностях XenSource писал Питер Левайн (Peter Levine) и как с этим обстоят дела в OpenStack.