У нас в команде есть пару проектов, для которых есть старые frontend. Написаны все они на разных технологиях, но объединяет их одно: нежелание кого-либо туда лезть и что-то править. Команде там кажется страшно, непонятно и неудобно. Любая доработка превращается в головную боль. В очередном проекте нам хотелось не допустить такого развития событий, и, кажется, у нас получилось.

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

Привет, Хабр!

UPD
На этом ресурсе актульность статьи может оказаться умноженной на ноль одним комментарием. Задача описанная в статье может быть с меньшей болью решена библиотекой mcamara/laravel-localization.
За наводку спасибо DExploN!

Кат приподнят. Умноженное на ноль — снизу.

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

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

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

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

#nginxживи

#ЯМыNginx

#ЯМыСысоевКоновалов

Когда они вводили реестр запрещенных сайтов, я молчал — что мне до педофилов и экстремистов?..

Когда они пришли за Богатовым, я молчал — я ведь не держал выходную ноду Tor.

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

Когда они собирали подписи на GitHub в поддержку Котова, я молчал — я не разделял его взглядов или не интересовался политикой (чего мне бояться, кому я нужен?).

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

… вы находитесь здесь...

Когда они ввели выездные визы для всех с зарплатой выше среднего, я...

Стоп. *звук ускоренной перемотки назад*

Мы, IT-шники, люди интеллектуальные. Сначала, пусть краткий, но логический и этический анализ. Каковы более глубокие причины происходящего, и соответственно, что на самом деле следует делать?

По нашей просьбе Хабр создал хаб Kubernetes и нам приятно разместить первую публикацию в нём. Подписывайтесь!

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

Александр Макаров ( SamDark )