Добрый день, хабровчане. Сегодня хочу представить результат почти года работы — две бесплатные книги.

Первая книга уже довольно давно существует, и некоторым из Вас может быть известна. «Работа с PostgreSQL: настройка и масштабирование» (четвертое издание) рассказывает, что такое PostgreSQL база данных и как много полезного можно делать с помощью неё. В книге обновились разделы про репликацию (новые Londiste, Bucardo, BDR), добавлены новые расширения и примеры использования их. Также сделана чистка разделов с правкой на актуальные версии базы данных.

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

В практике системного администрирования довольно часто приходится cталкиваться со сложными ситуациями, в которых не помогают ни инструменты сбора статистики (например, netstat), ни стандартные утилиты на основе протокола ICMP (ping, traceroute и другие). В таких случаях часто используются специализированные диагностические утилиты, дающие возможность «слушать» сетевой трафик и анализировать его на уровне единиц передачи отдельных протоколов. Они называются анализаторами трафика, а на профессиональном жаргоне — снифферами. С их помощью можно, во-первых, локализовывать сетевые проблемы и более точно их диагностировать, а во-вторых — обнаруживать паразитный трафик и выявлять в сети зловредное ПО.

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

В этой статье я опишу интересное решение на базе Nginx для случая, когда дисковая система становится узким местом при раздаче контента (например, видео).

Представляю вашему вниманию перевод статьи Everything is Broken, опубликованной в мае 2014 года на The Medium американской журналисткой Quinn Norton, которая специализируется на проблемах информационной безопасности. Статья рассматривает современный мир информационных технологий и место вопросов безопасности и конфиденциальности данных в нем. Статья местами содержит довольно резкую критику, тем не менее, поднимаемые в ней проблемы актуальны и не решены по сей день. В конечном счете, в этом, отчасти, и заключается работа журналиста — задавать неудобные вопросы.

---

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

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

Компьютеры и компьютерные технологии — все сломано.

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

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?

1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.

Вид на City, сердце деловой Великобритании

Перед тем как перейти «на контракт» я работал в постоянным сотрудником в Лондоне в небольшой (700 серверов / 8 коллег) компании. Моя специализация — Wintel engineer, то есть я могу работать к в суппорте так и в техподдержке проектов. Все что связано с продуктами Microsoft. Я подумывал об уходе с постоянной работы, однако волею судеб пришлось уйти совершенно неподготовленным. Именно отсюда начинается мой рассказ о контрактниках в Великобритании.

Одной из наиболее популярных техник для построения персонализированных рекомендательных систем (RS, чтобы не путать с ПиСи) является коллаборативная фильтрация. Коллаборативная фильтрация бывает двух типов: user-based и item-based. User-based часто используется в качестве примера построения персонализированных RS [на хабре, в книге Т.Сегаран,...]. Тем не менее, у user-based подхода есть существенный недостаток: с увеличением количества пользователей RS линейно увеличивается сложность вычисления персонализированной рекомендации.

Когда количество объектов для рекомендаций большое, затраты на user-based подход могут быть оправданы. Однако во многих сервисах, в том числе и в ivi.ru, количество объектов в разы меньше количества пользователей. Для таких случаев и придуман item-based подход.

В этой статье я расскажу, как за несколько минут можно создать полноценную персонализированную RS на основе item-based подхода.

Привет, Хабр!
Хочу рассказать вам о readyto.travel — особенном поисковике авиабилетов, разработанном rtt.
Его отличительная черта — собственный алгоритм поиска маршрутов, который позволяет находить неочевидные дешевые и быстрые варианты перелетов.



За счет чего же это достигается?

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

На западе есть такой термин “портфель простака”, “портфель лежебоки”. Пусть я простак (это предположение недалеко от истины) и у меня нет экономического образования. Я выбираю, куда можно инвестировать. Какие рынки мне могут прийти в голову? Их не так-то много:

Эта статья — продолжение доклада «Как просить деньги через телевизор», сделанного нашим проектировщиком Екатериной Юлиной (Katarios) на конференции ProfsoUX 2014. Основной темой доклада были интерфейсы коммерческих интернет-поставщиков: типичные ошибки пользовательских интерфейсов, хорошие примеры, аппаратные действия, осложняющие взаимодействие пользователя с телевизором. Отчет о конференции можно почитать на habrahabr.ru.

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

Здравствуйте.

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

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

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

Исповедь 1

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

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

Привет. Ей! Не говорите “Да блин! Я знаю, чем отличается список от вектора, мне не нужна эта статья”. Прошу, загляните под кат и освежите свои знания. Я надеюсь, однако, что вы сможете почерпнуть из этой статьи намного больше и, некоторые, возможно, наконец-то разберутся, почему существует так много типов данных для коллекций объектов.

Подолжаю публиковать авторскую переработку Understanding EXPLAIN от Guillaume Lelarge.
Ещё раз обращу внимание, что часть информации для краткости опущено, так что настоятельно рекомендую ознакомиться с оригиналом.

Предыдущие части:

Часть 1

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

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

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

Итак, хе-хе, приступим :)

apt-get install dh-make devscripts cdbs libmysqlclient-dev libcurl4-gnutls-dev
wget sunet.dl.sourceforge.net/project/zabbix/ZABBIX%20Latest%20Stable/1.8/zabbix-1.8.tar.gz
tar zxvf zabbix-1.8.tar.gz
cd zabbix-1.8
dh_make --createorig


На вопрос dh_make, какого типа пакет мы хотим создать, нужно ответить «b» (cdbs). В результате будет создан шаблонный пакет, с кучей файлов в директории debian на все случаи жизни (большую часть мы потом удалим).

Создание пакетов — это все-таки немножко шаманство и магия. Дело в том, что более простые, чем zabbix, программы, уже на этом этапе можно заканчивать пакетировать. Т.е. если для установки программы нужно сделать только ./configure && make install, то все готово, можно собирать и ставить. Zabbix — несколько более сложный вариант, поэтому впереди еще несколько шагов: