Мне довольно часто встречаются разработчики, которые не слышали о принципах SOLID (мы подробно рассказывали о них здесь. — Пер.) или объектно-ориентированного программирования (ООП), или слышали, но не используют их на практике. В этой статье описываются преимущества принципов ООП, которые помогают разработчику в его ежедневном труде. Некоторые из них хорошо известны, другие — не очень, так что статья будет полезна и новичкам, и уже опытным программистам.

Данный текст представляет собой адаптацию части руководства фрэймворка Hanami под фрэймфорк Laravel. Чем вызван интерес именно к этому материалу? В нём даётся пошаговое описание с демонстрацией таких общих для языков программирования и фрэймворков вещей как:

• Использование паттерна "Интеракторы".
• Демонстрация TDD\BDD.

Сразу стоит отметить, что это не только разные фрэймворки с разной идеологией (в частности, что касается ORM), но и разные языки программирования, каждый из которых имеет свою специфическую культуру и сложившиеся "bests practics" в силу исторических причин. Разные языки программирования и фрэймворки тяготеют к заимствованию друг у друга наиболее удачных решений, поэтому несмотря на различия в деталях, фундаментальные вещи не различаются, если мы конечно не берём ЯП с изначально разной парадигмой. Достаточно интересно сравнить, как одну и туже задачу решают в разных экосистемах.

Итак, исходно мы имеем фрэймворк Hanami (ruby) — достаточно новый фрэймворк, идеологически больше тяготеющий к Symfony, с ORM "на репозиториях". И целевой фрэймворк Laravel\Lumen (php) с Active Record.

Привет! Грядут новогодние каникулы, а с ними и некоторое количество свободного времени Собрали подборку популярых статей из нашего блога. Внутри деление → бекенд, фронтенд, команда, мобильная разработка.

Приглядитесь, даже если почитываете наш блог время от времени.

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

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

Пролог

На Хабре частенько проскакивают статьи на тему «из таксистов в программисты за 9 месяцев»… А что если я только собираюсь преодолеть этот путь? И вдруг не получится? В любом случае, я хочу немного рассказать о себе, чего хочу и почему решил пойти таким путем. Это не очередная success story и, возможно, никогда таковой не станет, но думаю найдутся люди, которые увидят в этих строках себя, свои страхи и отговорки и решат что-то изменить. Хочется рассказать о том, что уже было сделано, а что только планируется, и получить обратную связь от бывалых специалистов области. Итак, пройдемся по порядку.

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

В данной статье я расскажу о своём опыте "заворачивания" Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов.

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

• "Использую докер для локальной разработки. Ставлю laradock и беды не знаю". Круто, но как обстоят дела с автоматизацией и запуском на production?
• "Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри". Тоже отлично, прост в запуске, но как на счёт идеологии "один контейнер — один процесс"? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа?
• "Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь". Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться?

Для нетерпеливых — ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно "слинковав" контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

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

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

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

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

Как с этим жить?

Преамбула

У нас на поддержке есть небольшой фотобанк. Не будем называть имя и страну, только некоторые технические данные:
50 Тб данных для хранения, ежемесячно обновляется порядка 100 Гб, «горячие данные» (к ним идет 95% запросов) — 200 Гб.
Средний трафик — 50 Тб/мес.

Для размещения фотографий несколько лет назад выбрали несколько серверов SX серии от Hetzner с большими дисками (для хранения ПД пришлось придумывать более сложное решение, но об этом в другой раз).

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

Плюс для такого проекта использование CDN окажется на порядок дороже, чем раздача статики с серверов в недорогом датацентре.

В октябре моему проекту Поиск VPS исполнится 5 лет. В 2013 году я представил его общественности, и он был воспринят пользователями и хостерами крайне положительно. В течение следующего года я активно развивал сайт и добавлял различные функции, однако с 2015 года на сайте не происходило практически никаких изменений. Мое мнение практически во всем — если что-то хорошо работает, то лучше это не трогать. Сайт работает достаточно хорошо, нужно только обновлять тарифы, но мне всегда хотелось большего. Поэтому не так давно я решил сделать небольшое ответвление этого проекта, и в результате получился новый сайт для поиска виртуальных серверов — VPS.today, о котором я сегодня хочу рассказать.



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

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

Этот список, ретранслируемый американским сайтом Quartz, включает в себя как крупных технических гигантов, таких как: Google, Apple или IBM, но и многонациональные компании, такие как аудиторская компания «Ernst & Young» или Starbucks. Диплом Стэнфорда или Политехнической школы (École Polytechnique) не потерял своей ценности, тем более для ответственных и руководящих должностей.

«Академическая подготовка всегда принимается во внимание, и она останется важным критерием в процессе найма, но не станет препятствием»,- заявляет компаньон Ernst & Young, Мэгги Стилвелл, американской газете Huffington Post.

Здравствуй Хабр и Ruby-сообщество! Спешим сообщить, что уже совсем скоро, 10 июня 2018 года, во второй раз состоится конференция для разработчиков на Ruby и Ruby on Rails — Saint P Rubyconf 2018. Слоган конференции — «Ruby: the best parts». Место проведения — Санкт-Петербург, Корпус ИТМО на ул. Ломоносова, 9.

Хватит тратить время на скучные академические фолианты! Изучение Computer Science может быть веселым и увлекательным занятием.

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

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

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

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

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

Однако с подобным подходом возникает ряд проблем:

• Сейф можно вскрыть болгаркой или иным силовым методом
• Производитель сейфов может оставить обходную лазейку и получить доступ к содержимому