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

Моё хобби

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



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

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

Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

В этой статье сосредоточимся на следующем:

• Общее понимание Multicast
• Протокол IGMP
• Протокол PIM
• >>>PIM Dense Mode
• >>>Pim Sparse Mode
• >>>SPT Switchover — переключение RPT-SPT
• >>>DR, Assert, Forwarder
• >>>Автоматический выбор RP
• >>>SSM
• >>>BIDIR PIM
• Мультикаст на канальном уровне
• >>>IGMP-Snooping
• >>>MVR

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

Email – это важный канал связи с пользователем, а для многих сервисов (например, для купонаторов) работа через email становится основой бизнес-модели. При этом как активные пользователи мы испытываем огромное раздражение, когда почтовый ящик начинает заваливать рассылками, информационными письмами, приглашениями от странных сервисов, т.е. тем, что в обиходе мы называем попросту «спам». Реалии нашей жизни таковы, что спам составляет 80-90% входящего потока писем на любой почтовый сервер. Поэтому для современного почтового сервиса фильтрация спама – это must have.

Точные алгоритмы фильтрации по понятным причинам обычно скрываются. Однако мы готовы приоткрыть завесу тайны над одним из аспектов работы антиспам-системы Mail.Ru, чтобы помочь коллегам из разных интернет-компаний грамотно и эффективно производить email-рассылки для наших общих пользователей. Фактически это набор рекомендаций, как не отправиться в спам и увеличить процент доставки писем до конечного получателя. Надеюсь, многим они будут полезны.

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

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

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

Итак. Что у нас по плану после хранения данных?

Тема заезженная до дыр, не спорю… Вероятно, для опытных разработчиков моя статья будет мало, чем полезна. Я бы рекомендовал её к прочтению тем, кто только начал осознавать, что его коду чего-то не хватает, и что он созрел для вникания в это далёкое понятие – «паттерны». По себе помню, что довольно долгое время я путался в шаблонах, иногда даже не понимая, чем один отличается от другого. Именно этот факт стал основой для моей статьи. Примеры в ней не будут реальными. Они будут абстрактными и максимально простыми. Однако я постараюсь все примеры держать в едином контексте, чтобы можно было наглядно видеть отличия их использования в одной и той же ситуации. Я не буду нагружать классы лишним функционалом, чтобы можно было понять, какая именно часть кода имеет непосредственное отношение к шаблону. Главными героями примеров станут Factory (фабрика) и Product (продукт, производимый этой фабрикой). Возьмём это отношение за отправную точку. Возможно, в некоторых примерах это будет не очень уместно, но зато очень наглядно…

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

ОФФТОП: Хочу выразить свою благодарность, всем кто плюсанул мой предыдущей пост и карму, это позволило мне пригласить на Хабр еще несколько хороших людей.

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

Использование хранимых функций СУБД для реализации бизнес-логики или её части, всегда было камнем преткновения. С одной стороны баррикад DBA и программисты БД, с другой — разработчики backend.
Рискну навлечь на себя гнев из обоих лагерей, но всё же просуммирую плюсы и минусы и изложу свои соображения о том, когда стоит писать код в хранимых функциях, а когда следует выносить наружу.

Коллеги, в первой части статьи о SElinux мы рассмотрели основные особенности работы с системой SELinux. Как и обещано, теперь публикуем вторую часть, в которой основное внимание уделено настройке политик. Что же, приступим.

О SELinux на Хабре уже писали, однако, не так много опубликовано подробных мануалов по данной системе. Сегодня мы публикуем именно такой, подробный мануал по SELinux, начиная от информации по системе, и заканчивая гибкой настройкой политик.
Для того, чтобы не превращать пост в «простыню», сложную для понимания, мы решили разделить мануал на две части. Первая будет рассказывать о самой системе, и некоторых ее особенностях. Вторая – о настройке политик. Сейчас публикуем первую часть, чуть позже будет опубликована и вторая часть.

Некоторое время назад я выбирал библиотеку для работы с вебсокетами. На просторах интернета я натыкался на статьи по интеграции node.js с yii, а почти все статьи о вебсокетах на хабре ограничивались инструкциями к тому, как использовать phpdaemon.

Я изучал библиотеки phpdaemon и ratchet, они достаточно монструозны (причём используя ratchet для отправки сообщения конкретному пользователю рекомендовано дополнительно использовать wamp). Мне не совсем было понятно для чего использовать таких монстров, которые требуют установку других монстров. Почитав исходники этих, а также других библиотек, я разобрался как всё устроено и мне захотелось написать простой вебсокет-сервер на php самостоятельно. Это помогло мне закрепить изученный материал и наткнуться на некоторые подводные камни, о которых я не имел представления.

Так я решил написать необходимый для меня функционал с нуля.

Получившийся код и ссылка на демонстрационный чат в конце статьи.

Данная статья касается современных линуксов. Например, RHEL6 с ядрами 2.6.3х — подойдёт, а вот RHEL5 с ядрами 2.6.18 (кстати, наиболее популярный в продакшне) — увы, нет. И ещё — здесь не будет описания ядерных отладчиков или скриптов SytemTap; только старые-добрые простые команды вида «cat /proc/PID/xyz» в отношении некоторых полезных узлов файловой системы /proc.

Диагностика «тормозящего» процесса

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

К счастью, система работает под управлением OEL6, т.е. на достаточно свежем ядре (а именно — 2.6.39 UEK2)

Итак, приступим к диагностике.

1. Схема

Имеем:

• Frontend — NGINX проксирующий сервер для принятия и распределения нагрузки (IP — 1.2.3.4 — внешний, IP — 192.168.5.10 — внутренний DMZ) по хорошему он тоже должен стоять за firewall-ом, но тут схема для простоты понимания.
• Два сервера с поднятыми ownCloud
• cloud-1 IP — 192.168.1.11
• cloud-2 IP — 192.168.1.12
• Хранилище файлов NFS-storage IP — 192.168.1.20 для размещения данных пользователей с доступом по NFS.

Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.

Ура-ура, появился хаб IPv6!
В этой статье я хотел бы рассмотреть все актуальные способы туннелирования IPv6 через готовую IPv4-инфраструктуру, описанные в RFC 7059. Один из немногих RFC, написанных понятным человеческим языком, кстати.
Вы все еще сомневаетесь, нужен ли вам IPv6?

• У всех устройств белый IP. Никаких NAT, никаких пробросов портов
• Выше скорость скачивания торрентов за счет пиров, имеющих IPv6-адрес, но с «серым» IPv4.
• В некоторых случаях, выше скорость доступа к сайтам (YouTube через IPv6 не тормозит по вечерам)
• Доступ к сайтам, заблокированным в РФ, имеющим IPv6-адрес (nnm-club, например)

Но это еще не все. Представьте ситуацию, когда у вас сломался DHCP-сервер, а на компьютер в этой сети нужно побыстрее бы зайти. Он не получает IP-адрес, вы не можете на него зайти. Беда. Однако, если у вас был просто включен IPv6 — даже не настроен — то вы можете просто пропинговать магический адрес ff02::1, получить ответ от этого компьютера (т.к. у него в любом случае будет link-local IPv6-адрес!) и зайти на него.

Ну да ладно, перейдем к туннелированию.

6in4

Один из самых старых способов туннелирования, придуманный аж в 1996 году, и до сих пор очень популярный. Такие крупные туннель-брокеры, как Hurricane Electric, gogo6 и SIXXS используют его. Использует протокол 41 (не путайте с портом!) и не работает через NAT. Поддерживается всеми современными ОС из коробки.

Если вы задумали отбалансировать что-то вращающееся, будь то колесо, винт самолета или летающая тарелка. Или Вам интересна история, как проходят рабочие будни программиста. Увлекательная история по созданию балансировочного стенда…

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

Чтобы выяснить это, мы изучили около 24 миллиардов доставленных почтовых сообщений, темы которых были составлены из приблизительно 22 тысяч различных слов. Если для вас это прозвучало как «очень много данных», поверьте, так все и было.

Перевод статьи ребят из MailChimp выполнен компанией-локализатором Alconost.

tmux — это менеджер терминалов, к которому удобно подключаться и отключаться, не теряя при этом процессы и историю. Как screen, только лучше (в первую очередь потому, что использует модель клиент—сервер).



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

Предисловие

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

Некоторое время назад, в силу определенных причин, мне пришла в голову мысль о том, чтобы начать изучать какой-нибудь новый язык программирования. В качестве альтернатив для этого начинания я определил два языка: Java и Python. После продолжительного метания между ними и сопутствующих нытья и долбежки головой о стену (у меня с новыми языками всегда так — сомнения, раздумья, проблема выбора и т.д.), я все-таки остановился на Python. Окей, выбор сделан. Что дальше? А дальше я стал искать материал для изучения…