Введение

Слишком много раз я встречал приложения, о которых говорили, что у них есть модель предметной области и приложение было спроектировано на основе это предметной области. Однако в действительности всё, что я видел, было коллекцией сущностей (я бы даже сказал DTO), имеющих кучу свойств без какой бы то ни было реальной логики, связанной с сущностью. Кроме того, я могу найти много сервисов всех видов, которые содержат красочную смесь бизнес-логики и/или инфраструктуры. Если приложение вдобавок использует шину сообщений (как NServiceBus, Mass Transit Bus или Azure Bus), то конечно же заметно, что некие сообщения передаются от одного модуля к другому или нескольким модулям. К сожалению, сообщения часто имеют очень обобщённые названия, содержащие слова “обновить”, “изменить”, “добавить” или “удалить”, и несут большое количество полезной нагрузки — десятки разнообразных свойств. Часто из названия сообщения совершенно не очевидно, является ли оно командой или событием, и чтобы определить это, приходится глубоко зарыться в реализацию.

Я искренне хотел бы, чтобы все написанное выше было бы преувеличением или же имело смысл только для «старых» приложений, которые разрослись и вышли из-под контроля. Но печальная истина в том, что это относится ко многим новым проектам, даже тем, которым всего несколько месяцев от роду. Почему так происходит? Конечно, есть много разных причин: отсутствие знаний является одной из наиболее важных.

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

1. Видео с доклада
2. Слайды

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

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

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

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

На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.

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

Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?

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

На Хабре уже был перевод с обзором несколько месяцев назад, но недавно вышел первый релиз-кандидат PHP 7.1, а значит никаких существенных изменений больше не будет и можно сказать, какие точно изменения будут в релизе. Я решил немного оживить сухой “changelog” своим вольным переводом изменений, которые принесет нам новая минорная версия 7.х ветки.

Введение

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

Довольно часто наблюдается странная ситуация: при скоростном проводе, с роутера раздаётся совсем узенький wifi-канал, не загружающий и половины провода. При этом, хотя формально Wi-Fi, особенно в его ac-версии поддерживает какие-то огромные скорости, при проверке оказывается, что либо Wi-Fi подключается на меньшей скорости, либо подключается, но не выдаёт скорости на практике, либо теряет пакеты, либо всё вместе.

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

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

Меньше всего говорят о том, что будет после того как ты окончишь лагерь по программированию — когда ты пытаешься занять позицию разработчика с шестизначным окладом.


< 3% заявлений становились предложениями

Я окончил Hack Reactor в июле 2016, и мне потребовалось почти 3 месяца, прежде чем я принял предложение от Radius Intelligence. Я подавал заявления в 291 компанию, прошел 32 собеседования по телефону и 16 обычных, а также выполнил 13 задач по программированию, 11 из них — в офисах. И получил в итоге 8 предложений. Мне предлагали 60-125 тысяч долларов в компаниях США. В общем 2.8% заявок обернулись для меня выгодными предложениями.

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

Известно, что дерево – довольно сложная структура. И если чтение успешно реализуется в том числе рекурсией (которая не лишена своих проблем), то с изменением дела обстоят совсем не хорошо.

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

Классическое концептуальное объяснение зиппера, выглядит как-то так: это взгляд изнутри на древовидную структуру как бы вывернутую наизнанку, вроде вывернутой перчатки.

Это образное объяснение, если поскрипеть мозгами, обычно, конечно же, понимается только отчасти. Далее зипперы откладываются в сторону, потому что «это непонятная какая-то функциональная заморочка, типа монад, потом разберусь».

У автора «потом» уже наступило. Эта статья – попытка дать альтернативное объяснение зипперов (не путать с объяснением для альтернативно одаренных, хотя…) такое, что позволит быстро понять и немедленно начать использовать зипперы в практических задачах.

Доброго времени суток, уважаемые хабравчане! В Elasticweb мы негласно ратуем за Nginx и, наверное, мы одни из немногих хостингов, которые не поддерживают Apache и .htaccess соответственно. В связи с этим, большое количество обращений в тех. поддержку связано с оказанием помощи в написании конфигурационного файла для Nginx. Поэтому мы решили собрать коллекцию полезных сниппетов и коллекцию готовых Nging конфигов для наиболее популярных CMS/CMF/Фреймворков на PHP.

С приближением Web 3.0 все активнее начинают использоваться подходы API first и Linked Data (или что-то вроде Sematic Web). В связи с этим читателям предлагается познакомиться с фреймворком для удобного создания API на базе схем собранных на schema.org с генерацией ответов в виде JSON-LD,

Это укороченная версия туториала Api-platform

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

Факт 1

Под капотом самых критичных программ, которые вы используете на ежедневной основе (Mac OS X или Facebook) содержится ужасное количество хаков и костылей, которые с трудом уживаются друг с другом. Это как если бы вы разобрали боинг 747 и увидели, что топливопровод держится вешалкой для одежды, а шасси смотаны изолентой.

Бен Черри

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

Уже около полугода для разработки веб-проектов используем Symfony 2. Накопился список полезных библиотек и бандлов, не входящих в состав symfony-standard, но значительно экономящих время и избавляющих от изобретения велосипеда.



Обзор больше теоретический и включает следующие разделы:

• Админгенераторы
• Пользователи
• Импорт/экспорт xls
• API и OAuth 2.0
• Меню/навигация
• Мультимедиа
• Формы
• Поиск
• Пагинация
• Файловая система
• HTTP клиент

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

Когда вы приобретаете сервер VPS с 256MB или 512MB оперативной памяти на борту и лишь часть мощности процессора, то использовать для таких сервисов как MySQL/PHP/Apache настройки по умолчанию является очень плохой идеей. В настоящее время у меня запущено 3 сайта на самом дешевом тарифном плане с 512MB RAM/1 CPU. Не уверен полностью, но посещаемость составляет порядка 5-10 тысяч посетителей в день. Далее я хочу поделиться инструкцией как оптимизировать LAMP используя всего лишь 512 MB и при этом не уходя в swap. Обычно при такой настройки используется 256 – 378Mb памяти и все работает довольно быстро.

Определяем доступную память и активность swap.

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

$ free -m

Для того. чтобы посмотреть список запущенных процессов и отсортировать их по использованию памяти, необходимо выполнить вот такую команду:

$ ps -eo pmem,pcpu,rss,vsize,args | sort -k 1 -r | less

Настраиваем LAMP сервер для потребления малого количества оперативной памяти. Останавливаем, отключаем ненужные сервисы

Первый и очевидный вопрос, который необходимо задать — это «какие сервисы мне не нужны в использовании?». Недавно, я обнаружил очень удобную утилиту для управления сервисами. Она называется "sysv-rc-conf" и управляет сервисами при помощи псевдографики и флажками. Выгдялит вот так:

Здесь представлен список сервисов, которые я изменил.

• Postfix. Этот сервис позволяет отправлять и получать почтовые email сообщения для домена. Я использую для этих целей Google Apps для отправки почты и mailchimp для новостных подписчиков. Таким образом я остановил и отключил этот сервис.
• Bind9. Он нужен для управления DNS записями Вашего домена. Его можно отключить, так как все DNS записи хранятся у хостера.
• SSHD. Имеются и другие реализации, которые используют гораздо меньше памяти, но они не поддерживают sftp, поэтому данный сервис я оставил без изменений.

Не запускайте X-сервер, выключите все ненужные сервисы и настройте Apache, MySQL, PHP только с базовой необходимой функциональностью.

Предыстория

Статья Неверное использование паттерна проектирования «Мост» / «Bridge» как то так получилось разделила аудиторию на двое. Далее я подумал, сказав А не сказать Б, будет не правильно. Нет я не отказываюсь от своих слов, но я нашел где и как я использовал паттерн «Мост». Т.к. его еще и неверно понимают, кажется альтернативное название «Описатель/тело» — меньше вводит в заблуждение.

Так где же? Оказалось в моем аналоге использования концепции MVC (Модель/Представление/Контроллер).

Поэтому вначале ознакомлю со своей вариацией «Бизнес-сущность — Визуализация — Контроллер». Я уже ее писал, но думаю мало кто с этим знаком. А затем посмотрим где же там «Правильный мост».

P.S. Мне тут выдали кредит доверия, и я обязался написать еще одну статью о усовершенствовании паттерна Flyweight — отчитываюсь написал.

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

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

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


Изображение Гольфстрима на тепловом снимке со спутника

Нет предела совершенству, и Google PageSpeed тому доказательство. С его помощью меньше чем за минуту можно получить подробный отчет о производительности Web страницы. В подавляющем большинстве случаев PageSpeed подскажет, что нужно оптимизировать графику. Это наиболее частая проблема и наиболее весомая.



Например, даже на стартовой странице Google Developers графику можно сжать на 71%. Чем меньше весят фотки – тем быстрее грузится сайт. Меньше картинки — меньше трафика — все работает быстрее. Посетители тратят меньше времени – все довольны.

В этом материале подобраны основные инструменты для оптимизации графики.