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

Не секрет, что в больших конторах тема фильтрации Интернета довольно актуальная. С этой задачей справляется немало программных и аппаратных решений. Но в настоящее время все те сайты, которые мы резали ранее, работают по протоколу HTTPS, т.е. порт 443. Как известно, данный протокол проследить, прослушать и т. п., невозможно. А любой кеширующий фильтрующий прокси-сервер, редиректор и т. п. фильтрует только HTTP, т.е. порт 80. Как же резать Вконтакте, Одноклассники, iphide.info и многие другие подобные сайты? Как блокировать доступ к личной почте в организации, если использование оной запрещено порядками в организации? Да, можно фильтровать по IP адресам, но они частенько меняются, да и на многих ресурсах несколько IP адресов. Блокировать их на уровне файрвола как-то совсем не православное решение, и не совсем удобное.

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

В этой статье мы расскажем, как включить HTTP/2 для сайта в NGINX, размещенного на VPS от Infobox и какие преимущества это даст вашему сайту. Поддержка HTTP/2 была добавлена в релиз NGINX 1.9.5.

Зачем нужен HTTP/2

HTTP/2 – новая версия протокола HTTP, стандартизированная в начале 2015 года. Использование HTTP/1.1 из-за некоторых особенностей вносит негативный эффект на производительность веб-приложений.

В частности HTTP/1.0 позволяет выполнять только один запрос одновременно в TCP–соединении. В HTTP/1.1 были добавлены конвейерные запросы, но они только частично помогают параллельному исполнению запросов и по-прежнему приводят к блокировкам. Клиенты HTTP/1.0 и HTTP/1.1, которым необходимо делать много запросов сейчас используют множество соединений к серверу.

Кроме этого, поля заголовка HTTP многословны и часто повторяются, производя ненужный сетевой трафик. Также время тратится на заторы TCP. Это может привести к повышенным задержкам при множестве запросов сделанных с помощью новых TCP–соединений.

HTTP/2 решает эти проблемы, определяя оптимизированную семантику протокола HTTP. В частности это позволяет выполнять чередование запросов и ответов через то же подключение и предоставляет эффективное кодирование полей HTTP-заголовка. Также HTTP/2 позволяет приоритизировать запросы, позволяя более важным запросам выполняться быстрее.

В результате протокол становится более дружественным к сети, требуя установки меньшего количества TCP–соединений в сравнении с HTTP/1.x, что приводит к более эффективному использованию сети. Также HTTP/2 дает возможность эффективнее обрабатывать сообщения с помощью бинарного формата.

HTTP/2 тесно связан с SSL. Несмотря на то, что спецификация не требует обязательного использования SSL, все веб-браузеры выпущенные на текущий момент будут работать с HTTP/2 только если веб-сайт использует SSL.

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Вчера Apple провела Special Event, на котором были представлены обновленные Watch и iPhone 6S, новейшие iPad Pro и AppleTV. Мероприятие прошло очень динамично, вся команда Бандерольки наблюдала за ним с огромным интересом. Не будем высказывать своё мнение о каждом продукте. Скажем лишь, что Apple — большие молодцы: не спеша они делают нашу жизнь лучше.



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

Просматривая ленту новостей я наткнулся на рекомендацию от Типичного Программиста на статью «Implementing a Search Engine with Ranking in Python», написанную Aakash Japi. Она меня заинтересовала, подобного материала в рунете не очень много, и я решил перевести её. Так как она довольно большая, я разделю её на 2-3 части. На этом я заканчиваю своё вступление и перехожу к переводу.

Каждый раз как я использую Quora, я в конечном итоге вижу по крайней мере вопрос вроде этого: кто-нибудь спрашивает, как работает Google и как они могли бы превзойти его по поиску информации. Большинство вопросов не настолько смелые и дезинформирующие, как этот, но все они выражают подобное чувство, и в этом они передают значительное непонимание того, как работают поисковые системы.

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

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

Есть два основный этапа в разработке поискового движка: построение индекса, а затем, используя индекс, ответить на запрос. А затем мы можем добавить результат рейтинга (TF-IDF, PageRank и т.д.), классификацию запрос/документ, и, возможно, немного машинного обучения, чтобы отслеживать последние запросы пользователя и на основе этого выбрать результаты для повышения производительности поисковой системы.

Итак, без дальнейших церемоний, давайте начнем!

Это пост можно сказать является дубликатом моей предыдущей подборки “Самые нужные плагины для Grunt”. Дело в том, что спустя много часов поиска я не нашел крутых плагинов для Gulp, которых нет для Grunt за исключением пары весьма специфичных утилит. Всё как раз наоборот, но проигнорировать множество пользователей Gulp я не мог. Все недостающие плагины я выделил, потому что Gulp умеет использовать их из Grunt, как и Grunt из Gulp.

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

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

А еще я выложил подборку на GitHub, чтобы каждый мог пополнить коллекцию.

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

К чему мы приходим:
— Использование внешних стилей и последующий прогон кода через инлайнер. Из-за усложнения кода это стало целесообразным
— Улучшение семантики через именование классов и сокращение участков кода
— Частичная поддержка the Bat! Хотя Николь на него забила.
— Полная поддержка всех мобильных почтовых клиентов
— Использование ранее опасных конструкций. Благодаря усердному тестированию проблемы решены.

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

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

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



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

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

^{Aqua Mine}

Введение

После многолетнего доминирования дисплеев с высокой плотностью пикселей на мобильных устройствах, данная тенденция наконец-то дошла и до лаптопов с десктопами. По моему мнению, производители не ставили HiDPI-матрицы в основном из-за слабой поддержки DPI, отличных от 96, в Windows. К счастью, ситуация заметно улучшилась с выходом Windows 8 с Modern UI, хотя в десктопном режиме все еще далеко не идеальная — люди до сих пор жалуются на 3200×1800 при 13.3" в лаптопах и сомневаются о покупке 4K UHD 23.8"-монитора.

DPI и Linux

Возможность установки произвольного значения DPI появилась еще во времена Xfree86, но следует понимать, что это просто значение, которое ничего не делает само по себе. Его считывают и используют программы и компоненты, которые и принимают решение, каким образом отразить изменение DPI на экране. Если текст следует установленному значению DPI в 95% случаев (спасибо xft!), то размер элементов зависит от используемого окружения рабочего стола и тулкитов, на которых написаны приложения.

GTK+ 3-приложения поддерживают как целочисленный скейлинг элементов и дробный скейлинг шрифтов, так и изменение DPI на лету, без перезапуска приложений. Скейлингом элементов управляет переменная окружения GDK_SCALE, а скейлингом шрифтов — GDK_DPI_SCALE.
По умолчанию, шрифты скейлятся вместе с элементами. Таким образом, при DPI 96 и GDK_SCALE=2, вы получите шрифт, словно он с DPI 192. Чтобы отменить скейлинг шрифтов, достаточно установить переменную окружения GDK_DPI_SCALE в 0.5 (для GDK_SCALE=2).
Qt4 не умеет скейлить элементы. Для применения нового значения DPI требуется перезапуск приложения.
Qt5, начиная с версии 5.4, поддерживает целочисленный скейлинг элементов через переменную окружения QT_DEVICE_PIXEL_RATIO. DPI менять на лету нельзя, как и в Qt4, но работы в этом направлении ведутся и будут доступны с релизом Qt 5.6, как и скейлинг на каждый монитор отдельно.
WxWidgets-приложения ведут себя так же, как GTK+ 3, только не поддерживают скейлинг элементов.

Я попытался выяснить, какие DE можно комфортно использовать с HiDPI-мониторами. Тестирование проводилось на лаптопе с 12.5" 1366×768 (125 DPI) с подключенным внешним 23.8"-монитором с разрешением 3840×2160 (185 DPI).

Docker в продакшене на Iron.io


Ранее в этом году (прим. 2014 г.), мы приняли решение запускать каждую задачу на IronWorker внутри своего собственного Docker контейнера. С тех пор мы запустили более 300 000 000 программ внутри собственных Docker контейнеров в облаке.

После нескольких месяцев использования, мы хотели бы поделиться с сообществом некоторыми из проблем, с которыми мы столкнулись в построении инфраструктуры, основанной на Docker'e, как мы преодолели их, и почему это стоило того.

С тех пор как мы начали работать над Iron.io, мы пытались решить проблему поддержания наших IronWorker-контейнеров в актуальном состоянии относительно новых сред выполнения и пакетов Linux. В течение последних двух лет IronWorker использовал одну и ту же среду выполнения без изменений. Пока, несколько недель назад, мы не выпустили в продакшен различные окружения для языков программирования.

С момента создания нашего сервиса, мы использовали только один контейнер, который содержал набор языковых сред и бинарных пакетов — Ruby, Python, PHP, Java, .NET и другие языки, а также библиотеки такие как ImageMagick, SoX и другие.

Этот контейнер и стратегия его использования начали устаревать, равно как и Ruby 1.9.1, Node 0,8, Mono 2 и прочие языки со старыми версиями, которые использовались в стеке по умолчанию. Со временем проблема стала ещё острее, поскольку люди начали использовать новые вещи, но были вынуждены изменять свой код для работы со старыми версиями языков.

Образы Docker могуть быть очень большими. Многие превышают 1 Гб в размере. Как они становятся такими? Должны ли они быть такими? Можем ли мы сделать их меньше, не жертвуя функциональностью?

В CenturyLink Lab мы много работали над сборкой различных docker-образов в последнее время. Когда мы начали экспериментировать с их созданием, мы обнаружили, что наши сборки очень быстро раздуваются в объеме (обычным делом было собрать образ, который весит 1 Гб или больше). Размер, конечно, не столь важен, если мы говорим про образы по два гига, лежащие на локальной машине. Но это становится проблемой, когда вы начинаете постоянно скачивать/отправлять эти образы через интернет.

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

Я расскажу о том, как мы с releu придумали, сделали и развиваем сервис мини-уроков английского языка, которым пользуются уже 4000 человек каждый день. Для затравки рост числа активных пользователей:

Предыстория

Так сложилось, что уже пять лет мой раздел ntfs с операционной системой Windows располагается на рамдиске. Решено это не аппаратным, а чисто программным способом, доступным на любом ПК с достаточным количеством оперативной памяти: рамдиск создается средствами загрузчика grub4dos, а Windows распознаёт его при помощи драйвера firadisk.

Однако до недавнего времени мне не был известен способ, как реализовать подобное для Linux. Нет, безусловно, существует огромное количество линуксовых LiveCD, загружающихся в память при помощи опций ядра toram, copy2ram и т. д., однако это не совсем то. Во-первых, это сжатые файловые системы, обычно squashfs, поэтому любое чтение с них сопровождается накладными расходами на распаковку, что вредит производительности. Во-вторых, это достаточно сложная каскадная система монтирования (так как squashfs — рид-онли система, а для функционирования ОС нужна запись), а мне хотелось по возможности простого способа, которым можно «вот так взять и превратить» любой установленный на жесткий диск Linux в загружаемый целиком в RAM.

Ниже я опишу такой способ, который был с успехом опробован. Для опытов был взят самый заслуженный дистрибутив Linux — Debian.

Как мы избавились от JavaScript-библиотек социальных сетей, ускорили скорость загрузки страниц и использовали RESTful API для “шаринга” и “лайков”.

В последние пару дней мне часто приходится отвечать на вопросы, как я нашёл работу в Германии, поэтому я решил объединить весь свой путь (ещё незаконченный) в единый текст и опубликовать здесь, потому как тема мне кажется интересной и актуальной.

Идея уехать жить куда-нибудь за пределы этой страны была давно, но как-то не сказать, что здесь всё было совсем плохо и невыносимо. Однако вернувшись в октябре из двухнедельной поездки по Европе (Барселона, Брюссель, Амстердам и Прага), желание заметно укрепилось. Плюс уже изрядно достали все эти #крымняш, нефть, рубль и великий Пу.

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

Всем доброго дня!

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