Приветствую уважаемые.

«Ехали регулярные выражения, через регулярные выражения, видят регулярные выражения, в регулярных выражениях, регулярные выражения — регулярные выражения, регулярные выражения, регулярные выражения...»

Нет. Это не бред сумасшедшего. Именно так я хотел назвать мой небольшой обзор на тему поиска регулярных выражений с помощью регулярных выражений. Что по сути тоже не меньший бред. Даже не знаю может ли вам такое в жизни пригодиться. Лучше конечно избегать таких ситуаций когда надо искать непонятно что, непонятно где. Ведь что такое регулярное выражение? Да почти всё что угодно!

Вам может показаться странным, но:

.это, например, вполне себе регулярное выражение:.
(Или это тоже может быть (можете даже проверить))
~это~
<script src="И это - регулярка, вполне рабочая и может быть даже кому нибудь очень необходимая.js">

Но давайте без паники, попробуем приступить, может что и выйдет приличное.

Хабр уже насыщен статьями на тему «нового» формата изображений WebP (описание, сравнение с JPEG2000, сравнение с BPG, использование, подключение на сайте). К сожалению, открытыми остаются вопросы: как правильно подключить WebP на сайте, чтобы «все работало», и насколько он лучше (меньше) PNG/JPEG. В этой заметке я буду отвечать на оба вопроса.

Предполагаю, что вы уже в курсе оптимизации изображений, умеете конвертировать изображения в WebP, понимаете разницу между использованием JPEG и PNG на сайте, знаете инструменты ExifTool, jpegtran, mozjpeg, JPEGrescan, optipng, pngcrush, pngwolf, zopflipng и TruePNG, а также различаете пастеризацию молока и постеризацию изображений.

Если все так — то переходим к сути.

Долго искал внятное объяснение как заставить локальный sendmail, установленный на компьютере во внутренней сети, отправлять почту во внешний мир. В качестве relay был выбран smtp.gmail.com.

Перекопал и испробовал кучу описаний в сети как это должно делаться. Результат оказался пшиком.

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

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

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Псевдоэлементы :before и :after позволяют добавлять содержимое (стили) до и после элемента, к которому были применены.

Ненавижу статьи про продвижение мобильных приложений. Потому что в 99% процентах из них будет одна вода, избитые, всем известные инструменты, без живых цифр и примеров. Не для этого я захожу на Хабр.

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

Запасайтесь чаем и добро пожаловать под кат

Одним из самых значительных событий, произошедших в мире PHP в 2015 году, стал выпуск PHP 7. Целых 10 лет отделяют его от выпуска первого релиза PHP с номером 5. С увеличением первой цифры в номере версии, в PHP 7 появилась масса новшеств, увеличилась и скорость работы.
Однако в седьмой версии была убрана устаревшая функциональность, что привело к некоторым проблемам с обратной совместимостью, затруднив перевод старых приложений на новую версию. Эта статья может послужить вам кратким руководством, если вы планируете написание новых или перевод своих существующих приложений на PHP 7.

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

В данной статье расскажу, как в течении нескольких лет я пришел к, в моем видении, идеальному решению для реализации Restfull API сервиса на PHP. Конечно, я в курсе, что существует бесчисленное множество фреймворков, которые позволяют за пару минут развернуть своё API. Но, меня всегда одолевали сомнения на их счет. Лично я – никогда не любил использовать чужой код. Сначала: из-за того, что не было уверенности 100% понимания всех происходящих процессов. Позднее: из за сомнений в том, что данный фреймворк – лучшее, что может быть написано для моего проекта.

Если Вы – ярый сторонник фреймворков и не понимаете мой выбор: нашел статью на хабре затрагивающую эту тему.

Итак, если Вы еще не определились какой подход использовать в реализации RestAPI для Вашего сервиса или просто хотите сравнить свой подход с моим – давайте смотреть код!

Предлагаю вашему вниманию вольный перевод статьи "Styling Broken Images" с сайта bitsofco.de.

«Битые» картинки выглядят ужасно.



Но они не всегда должны так выглядеть. Мы легко можем применить CSS к элементу (тегу) img, чтобы улучшить его внешний вид — сделать его куда более привлекательнее, чем как он выглядит по умолчанию.

Если вам наскучили дефолтные уведомления о «битых» картинках, милости прошу под кат.

Примечание переводчика: визит под кат этого поста означает большие объёмы потреблённого трафика. И это иронично, если учесть поднятую тему. Но всё сразу встаёт на свои места, если помнить, что в оригинале это было выступление в прошлом ноябре в Сиднее длиной почти в час. Чтение поста занимает куда меньше времени. В форме видеозаписи (1280×720) речь занимает два гигабайта. Пост же занимает всего лишь 12 МиБ. Рекомендуется просмотр на широких мониторах.



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

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

8 марта 2016 года в 9:04 GMT центр сертификации Let's Encrypt выдал миллионный TLS-сертификат.

Let's Encrypt – некоммерческая инициатива организации Mozilla и Фонда электронных рубежей (EFF), созданная на благо сообщества. Владелец любого домена может получить здесь сертификат TLS совершенно бесплатно и очень просто его установить (пошаговая инструкция на Хабре). Закрытое бета-тестирование началось 12 сентября 2015 года, а с 3 декабря сертификаты выдают всем желающим без предварительной регистрации и инвайтов.

Это потрясающий успех проекта: для выдачи миллиона сертификатов понадобилось всего 3 месяца и 5 дней.

Вышел новый релиз персональной облачной платформы ownCloud 9.0.

Я уже писал про ownCloud раньше. Я очень люблю этот комбайн из хранилища данных с синхронизацией, версионированием, галереей, календарем, хранением контактов и прочими плюшками. Серверная часть написана на PHP, поддерживаются протоколы WebDAV, CardDAV, CalDAV. Клиентский софт есть под Linux, OS-X, Windows, мобильных платформы и через web интерфейс. В теории может работать с петабайтными объемами данных.

Сервис может работать в федеративном режиме — есть возможность объединять и линковать независимые ownCloud-инстансы, делиться каталогами и другими данными. В качестве файловой системы можно использовать GPFS, GlusterFS и другие распределенные варианты. Хорошо допилена интеграция в инфраструктуру Amazon.

Changelog:

1. Возможность добавлять комментарии и теги к файлам
2. Новая система уведомлений
3. (Федеративный режим) Автодополнение имен пользователей
4. (Федеративный режим) Списки доверенных серверов
5. Код для дополненией и основных файлов наконец подписан
6. Добавили новую систему обновления
7. Улучшения производительности при совместном доступе к каталогам
8. Новое API для External Storage
9. Различные улучшения системы безопасности

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

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

В прошлом году в мире сетевых технологий произошло очень важное событие: была утверждена и стандартизирована новая версия протокола HTTP — HTTP/2. HTTP/2 уже поддерживается в популярных веб-серверах: Apache и Nginx. Идёт работа по внедрению HTTP/2 в IIS. Реализована поддержка и в большинстве современных браузеров.

Использование HTTP/2 за последнее время существенно расширилось.

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

CPU: 1 x 2GHz
HDD: 10Gb
RAM: 512Mb
OS: Debian 8 x64

Схема работы системы выглядит следующим образом:

После открытия проекта HTTPS.menu я решил сделать небольшое сравнение сертификатов разных сертифицирующих центров с верификацией только по доменному имени.



Верификация по домену выглядит довольно просто — на один из адресов электронной почты вида admin@domain.zone, administrator@domain.zone, hostmaster@domain.zone, postmaster@domain.zone, webmaster@domain.zone или e-mail адрес из whois приходит письмо с кодом верификации, а пользователь должен подтвердить владение доменом, кликнув по ссылке и указав секретный ключ, полученный в письме. После этого на почту приходит сам сертификат.

Сегодня в обзоре речь пойдет о 5 различных сертификатах от 3 удостоверяющих центров:
Comodo PositiveSSL
RapidSSL
Comodo EssentialSSL
Thawte SSL123
GeoTrust QuickSSL premium

Уже 3 с лишним года занимаюсь дизайном и версткой почтовых рассылок, которые ориентированы на англоязычных пользователей. За время работы перелопатили огромную кучу информации, перепробовали много вариантов верстки, набили достаточное количество шишек. Были найдены и исправлены типичные баги, которые в той или иной мере повторялись во всех почтовых клиентах. Также нашлись проблемы с некоторыми CSS свойствами — различные почтовые клиенты интерпретировали их по разному. Каждое письмо тестировалось на самых популярных почтовых клиентах: Gmail, Outlook, Yahoo, Android, iOS, MozillaThunderbird, Microsoft Outlook, The Bat. Рассылки ходят на сотни миллионов пользователей и приносят очень хорошие результаты. Итак, приступим к изучению.

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

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

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

Сайт проекта:https://sprut.io
Демо доступно по ссылке: https://demo.sprut.io:9443
Исходный код: https://github.com/LTD-Beget/sprutio