Транслитерация — это запись кириллических слов латиницей (Анна → Anna, Самара → Samara). Её используют в загранпаспортах, водительских удостоверениях, трансграничной доставке, библиотечных каталогах и множестве других международных процессов.

Так вышло, что я недавно окунулся в эту тему, а в Википедии она раскрыта слабо. Поэтому расскажу, что к чему (спойлер — если вы думаете, что с транслитерацией всё плохо, то на самом деле всё ещё хуже).

И конечно, поскольку это Хабр — предложу open-source библиотеки для решения проблемы.

Всем привет, сегодня поговорим о том, как подружить Symfony 4, JSON RPC и OpenAPI 3.

Данная статья рассчитана не на новичков, вы уже должны понимать как работать с Symfony, Depedency Injection и другими «страшными» вещами.

Сегодня рассмотрим одну конкретную реализацию JSON RPC.

Свежая подборка со ссылками на новости и материалы. В выпуске: расписание релиза PHP 8, анализ эргономики объектов в PHP и 5 свежих RFC из PHP Internals, немного полезных инструментов, видео, подкасты и многое другое.

Приятного чтения!

ansistrano.deploy и ansistrano.rollback — роли Ansible, предназначенные для управления процессом развертывания приложений, созданных на скриптовых языках программирования (например, PHP, Python и Ruby). По сути это реализация Capistrano в Ansible.

Использование Ansistrano дает следующие преимущества:

• откат за секунды (с ролью ansistrano.rollback);
• настройка процедуры развертывания с использованием методов-обработчиков событий «до» и «после» критически важных шагов;
• оптимизация использования дискового пространства за счет хранения ограниченного количества релизов;
• выбор между SCP, RSYNC, GIT, SVN, HTTP Download или S3 GET-стратегиями развертывания (в дополнение возможно использование unarchive).

Представьте ситуацию – живете вы спокойно, ничего не болит и не краснеет, носите очки или линзы, или ничем не пользуетесь и видите отлично – и случайно попадаете на прием к офтальмологу. Скажем, из-за призыва в армию, из-за беременности или просто на диспансерный осмотр. И вдруг узнаете, что сетчатка у вас «дырявая» или натянутая и вот-вот порвется.

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

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

Или «забьёте» на все и продолжите жить как раньше – не беспокоит же ничего. В чем же риск?

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

Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования тоже проблемы. «И что же теперь, не использовать наследование вообще?» – спросите Вы.

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

Проблема хрупкого базового класса

За четыре года в стенах нашего офиса двадцать человек начинали учить английский, и только двое дошли до уровня advanced. За тысячу академических часов они перепробовали занятия в группе, индивидуальные консультации, оксфордские учебники, подкасты, статьи на Medium, даже смотрели «Кремниевую Долину» в оригинале. Стоило ли это таких усилий? Всё очень неоднозначно. Здесь я приведу мысли о том, какой уровень полезно освоить программисту, и когда стоит прекратить целенаправленное изучение.

Введение

Эта статья расшифровка видеодоклада Алексея Вахова из Учи.ру «Облака в облаках»

Учи.ру — онлайн-платформа для школьного образования, более 2 миллионов школьников, регулярно решают у нас интерактивные занятия. Все наши проекты хостятся полностью в публичных облаках, 100% приложений работают в контейнерах, начиная от самых маленьких, для внутреннего пользования, и заканчивая крупными продакшенами на 1k+ запросов в секунду. Так получилось, что у нас 15 изолированных докер-кластеров (не Kubernetes, sic!) в пяти облачных провайдерах. Полторы сотни пользовательских приложений, количество которых постоянно растет.

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

В процессе доклада мы обсудим:

• Мотивацию выбора технологий и особенности бизнеса
• Инструменты: Ansible, Terraform, Docker, Github Flow, Consul, Nomad, Prometheus, Shaman — web-интерфейс для Nomad.
• Использовании федерации кластеров для управления распределенной инфраструктурой
• NoOps выкатки, тестовые окружения, схемы приложения (практически все изменения девелоперы делают самостоятельно)
• Занимательные истории из практики

Кому интересно, прошу под кат.

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