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

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



Фото Johan Larsson / Flickr / CC

Андрей Ситник (Iskin, Злые марсиане)

В 2013 году Holowaychuk анонсировал свой проект Rework в статье «Модульный CSS-препроцессинг с Реворком» (http://tjholowaychuk.tumblr.com/post/44267035203/modular-css-preprocessing-with-rework ).

Как раз тогда я искал какой-то инструмент для того, чтобы сделать автопрефиксер. Когда я прочитал эту статью, я был поражен, потому что это был действительно революционный подход, он менял все. И поэтому первые версии автопрефиксера базировались на Rework’е. Но, к сожалению, Rework – это был Proof Of Concept, это было первое поколение, чтобы доказать, что это вообще работает. Поэтому мы его жестко форкнули, переманили всех разработчиков, устроили маленькую революцию и сделали PostCSS.

PostCSS – это второе поколение модульного процессора.

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

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

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.

Я не самый талантливый кодер в мире. Правда. Так что я стараюсь писать как можно меньше кода. Чем меньше кода я пишу, тем меньше кода может ломаться, поддерживаться и требовать пояснений.

А еще я ленивый — мед, да еще и ложкой (я решил использовать в статье аналогии с едой).

Но, оказывается, что единственный гарантированный способ повысить производительность в вебе — это писать меньше кода. Минифицировать? Окей. Сжимать? Ну, да. Кэшировать? Звучит неплохо. Вообще отказываться кодить или использовать чужой код изначально? А вот теперь — в яблочко! Что есть на входе — должно выйти на выходе в той или иной форме, независимо от того, смог ли ваш сборщик растворить и переварить это своими желудочными соками (я, пожалуй, откажусь от пищевых аналогий).

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

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

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

Так как веб-сайты и онлайн-сервисы с каждым годом становятся все «тяжелее», возрастает необходимость и сжатия данных в вебе. По этой причине Google выпустил новый алгоритм сжатия данных для веб-сайтов — Brotli, что в переводе с швейцарского немецкого означает «маленькая булка хлеба». Алгоритм уже доступен широкой аудитории на GitHub.

Всем привет, сегодня я расскажу о том, как настроил server push на своём сайте и добился увеличения скорости рендеринга страниц. Для начала о том, что же такое server push в HTTP/2. Это технология, позволяющая серверу «протолкнуть» дополнительные данные клиенту, в момент запроса основного документа. То есть в обычной ситуации запрашивает браузер html-страничку, затем обрабатывает её и приходит к выводу, что ему для корректного отображения необходимо подгрузить дополнительные файлы: стили, скрипты, изображения. После чего скачивает их и отображает конечный результат. Server push позволяет отправить дополнительные файлы уже в момент получения основного документа, и они уже будут иметься в кэше, когда они потребуются браузеру. За счёт этого возрастает скорость загрузки сайта.

На этот раз схема будет следующая:

В своей предыдущей статье по оптимизации сайта на WordPress я рассказал об очень эффективном подходе к оптимизации за счёт кэширования страниц. В результате чего для незалогиненных пользователей время ожидания страницы клиентом (исключая время на установление TLS-сессии) сократилось с 820 мс до 30 мс (этот и все последующие замеры проводились с сервера, расположенного в том же городе, что и мой VDS), что, согласитесь, является отличным показателем. Однако, для залогиненных пользователей генерация страницы происходила по-прежнему долго — в среднем 770 мс на сервере. В этой части я расскажу о том, как я сократил это время до 65 мс, при этом полностью сохранив работоспособность пользовательского функционала.

Целью этой и предыдущей статей является моё желание показать возможность оптимизации сайтов не только на WordPress, а вообще любого веб-приложения. Поэтому я использую такое количество инструментов, и так детально разбираю их конфигурацию. Если же Вам просто нужно ускорить WordPress — установите плагин WP Super Cache. Если Вас, как и меня, интересуют технологии, позволяющие оптимизировать любой сайт, а также Вам интересно, что стоит учитывать при разработке веб-приложений, рассчитанных на высокие нагрузки — прошу под кат, но только после прочтения первой части — дорабатывать я буду ту же систему.

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

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

Предлагаю читателям "Хабрахабра" перевод статьи "Why, oh WHY, do those #?@! nutheads use vi?" за авторством John Beltran de Heredia.

Да, даже если вы не можете в это поверить, у редактора vi, увидевшего свет более тридцати лет назад (и его более молодого, всего-то пятнадцатилетнего лучшего клона & большого улучшения — vim) очень много фанатов.

Нет, они не динозавры, которые не хотят идти в ногу со временем — сообщество пользователей vi продолжает увеличиваться: я, который начал только два года назад (после десяти лет работы программистом). Мои друзья переходят на vi сейчас. Черт, большинство пользователей vi даже еще не были рождены, когда он был написан!

Да, есть конкретные причины, почему модель редактирования vi/vim превосходит любую другую. Вам не надо быть экспертом в Unix, чтобы использовать vi — он доступен бесплатно практически для любой существующей платформы; для большинства IDE существуют плагины, позволяющие использовать его возможности. Давайте же развеем некоторые заблуждения и рассмотрим пару примеров, демонстрирующих его превосходство.

Недавно вспомнилось мне, что есть такой сервис — StartSsl, который совершенно бесплатно раздаёт trusted сертификаты владельцам доменов для личного использования. Да и выходные попались свободные. В общем сейчас напишу, как в nginx настроить HTTPS, чтобы при проверке в SSL Labs получить рейтинг А+ и обезопасить себя от последних багов с помощью выпиливания SSL.

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

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

Мало кто знает, что Николай Горькавый не просто талантливый писатель, но серьезный ученый-физик. Наиболее известной из его работ является разработка модели резонансного происхождения тонких колец Урана и Сатурна, проведенной в соавторстве с А.М. Фридманом. Эта работа позволила предсказать целую серию спутников Урана, которые и были открыты при полете «Вояджера-2». В настоящее время живёт и работает в США, является директором и старшим научным сотрудником частного Гринвичского научно-технологического института (Greenwich Institute for Science and Technology, GIST) в штате Вирджиния. Подробнее о научных достижениях можно почитать на wiki.

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

Сразу оговорюсь и скажу, что метод работает и с другими почтовыми сервисами. В данной статье были протестированы только Яндекс, Gmail и Mail.ru.



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

Почему это нельзя использовать для писем mail.ru, описано в самом конце статьи.

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

Перевод поста Стивена Вольфрама "What Is Spacetime, Really?".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации.

Примечание: данный пост Стивена Вольфрама неразрывно связан с теорией клеточных автоматов и других смежных понятий, а также с его книгой A New Kind of Science (Новый вид науки), на которую из этой статьи идёт большое количество ссылок. Пост хорошо иллюстрирует применение программирования в научной сфере, в частности, Стивен показывает (код приводится в книге) множество примеров программирования на языке Wolfram Language в области физики, математики, теории вычислимости, дискретных систем и др.

---

Содержание

Простая теория всего?
Структура данных Вселенной
Пространство как граф
Может быть, нет ничего, кроме пространства
Что есть время?
Формирование сети
Вывод СТО
Вывод ОТО (Общей теории относительности)
Частицы, квантовая механика и прочее
В поисках вселенной
Ок, покажите мне Вселенную
Заниматься физикой или нет — вот в чем вопрос
Что требуется?
Но пришло ли время?

---

Сто лет назад Альберт Эйнштейн опубликовал общую теорию относительности — блестящую, элегантную теорию, которая пережила целый век и открыла единственный успешный путь к описанию пространства-времени (пространственно-временного континуума).

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

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

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

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

Во-первых, такой подход казался не слишком перспективным — хотя бы потому, что модели, которые я изучал (клеточные автоматы), казалось, работали так, что это полностью противоречило всему тому, что я знал из физики. Но где-то в 88-м году — в то время, когда вышла первая версия Mathematica, я начал понимать, что если бы я изменил свои представления о пространстве и времени, возможно, это к чему то бы меня привело.

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

Несколько вещей гарантированно будут увеличиваться со временем: расстояния между звёздами, энтропия вселенной и бизнес-требования к ПО. Многие статьи пишут «Не усложняйте!», но не пишут почему или как это сделать. Вот вам 10 ясных примеров.

1. Инженерам виднее

Мы, инженеры, считаем себя умнейшими людьми. Ну, поскольку мы создаём разные штуки. И эта ошибка часто приводит к оверинжинирингу. Если вы спланировали и построили 100 модулей — Бизнес всегда попросит у вас 101-ый, о котором вы никогда не задумывались. Если вы соберётесь с силами и решите 1000 проблем — они придут к вам и выложат на стол 10 000 новых. Вы считаете, что у вас всё под контролем, а на самом деле вы даже не представляете, в каком направлении вас завтра поведёт дорога.



За мои 15 лет работы программистом я ещё ни разу не видел, чтобы Бизнес выдал законченные и стабильные раз и навсегда требования к ПО. Они всегда меняются, расширяются. И это природа бизнеса, а не ошибки людей, управляющих им.

Мораль: Казино (бизнес) всегда побеждает.

Сегодня внутренняя разработка компании Яндекс — аналитическая СУБД ClickHouse, стала доступна каждому. Исходники опубликованы на GitHub под лицензией Apache 2.0.



ClickHouse позволяет выполнять аналитические запросы в интерактивном режиме по данным, обновляемым в реальном времени. Система способна масштабироваться до десятков триллионов записей и петабайт хранимых данных. Использование ClickHouse открывает возможности, которые раньше было даже трудно представить: вы можете сохранять весь поток данных без предварительной агрегации и быстро получать отчёты в любых разрезах. ClickHouse разработан в Яндексе для задач Яндекс.Метрики — второй по величине системы веб-аналитики в мире.

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

Прошлую свою статью я посветил описанию «велосипеда» (загрузчика и шаблонизатора в рамках «легкого» framework’а). Волею судеб, для пары проектов я был вынужден выделить шаблонизатор и сделать его standalone версию, обогатив при этом рядом новых возможностей. Именно об front-end шаблонизаторе и пойдет речь.

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

• Вы front-end разработчик, и вам интересно использование шаблонов.
• Вы back-end разработчик, и вам интересно использование шаблонов на front-end’е.
• Вы давно ищете какой-нибудь инструмент для систематизации своей коллекции UI-control'ов, накопившуюся за несколько лет.
• Вы интересуетесь разработкой web-компонентов.
• Вам хочется высказать критические замечания и порекомендовать angularJS.
• У вас есть свободное время и вам интересно почитать об очередном велосипеде.
• У вас нет свободного времени, но вам интересно.
• Вы хороший и любознательный человек.

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

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



А затем мы провели атаку через сеть SS7 на один из тестовых номеров (подробнее о самих атаках мы писали ранее). И вот что у нас получилось: