Подкаст о PHP, DBA, архитектуре, DevOps. Авторское мнение о современных трендах в веб-разработке и интересные беседы с гостями. Помимо PHP поднимаем темы про инфраструктуру, администрирование Linux и DevOps подходы, сравниваем PHP с другими языками программирования, например с Go, Rust и даже Erlang.
В этом выпуске Юлия Беймлина, продуктовый методист курса «Английский для разработчиков» от Яндекс Практикума, рассказывает, как эффективно заниматься изучением английского языка, и в чём особенности преподавания для конкретных профессий, например, для разработчиков.
В чём отличие преподавания английского языка для различных профессий (программисты, юристы, ученые…)?
«Можно говорить грамотно, но неуместно»
Английский для разработчика — отличается ли подход к обучению чисто программистов (кодеров) и тимлидов?
Какие бывают уровни знания английского? A1, A2, B1, B2, C1, C2 — что всё это значит?
Какого уровня достаточно для разработчика?
А для тимлида или IT-менеджера?
Сколько времени и усилий нужно для достижения этого уровня?
Что такое Intermediate-плато и как его пройти?
Культурный код и его значение уже на этапе собеседования
Что не важно при обучении английскому языку?
Как тренировать произношение?
Насколько русский акцент понятен на слух?
Грамматические ошибки: критичные и нет
Самостоятельное обучение до уровня B2 — это реально?
Рецептивные и продуктивные навыки
Полезные инструменты и программы для изучения английского языка (в том числе внутри PhpStorm!)
Пополнение словарного запаса по карточкам — насколько это эффективно?
Этот выпуск выходит при поддержке Яндекс Практикума.
Удивительно, насколько разные бывают подкасты, казалось бы, с одной темой и одним гостем! В «Запуске завтра» были раскрыты совершенно другие вопросы, очень интересно получилось, рекомендую.
Недавно втянулся в использование SQL синтаксиса LEFT JOIN LATERAL – ключевое слово LATERAL. Буквально по-другому стал смотреть на решение некоторых задач!
Проверил по документации, погугил, в популярных PHP ORM – нигде нет поддержки LATERAL, ни в Doctrine, ни в Laravel Query Builder, ни в Yii Query Builder, ни в Cycle ORM
И тут хочу дать пояснение, моё отношение к различным Query Builder и обёрткам над SQL синтаксисом. Вот какой подход я применяю при выборе между написанием простого SQL и использованием Query Builder / ORM:
• Если мне нужно поработать с конкретной сущностью в ООП стиле, скорее всего у меня уже есть описание модели реализованное для той или иной ORM, соответственно использую модель, использую ООП, под капотом все запросы за меня строит и выполняет ORM;
• Зачастую базовый фреймворк / админка / CRM предоставляют некую точку расширения, где нужно вписать небольшую функцию или переопределить метод и в этой точке расширения фреймворк нам в явном виде передаёт заготовку Query Builder – использую эту заготовку, навешивая свои дополнения к запросу. Обычно в этот Query Builder я добавляю условия отбора или атрибуты;
• Если я сам пишу некий фреймворк и подготавливаю эти точки расширения для будущих программистов, то создаю заготовку Query Builder;
• Во всех остальных случаях, когда надо сделать выборку из базы и, скорее всего, это выборка из двух или более таблиц, да ещё с подзапросами или EXISTS – тогда предпочитаю чистый SQL! Обычный SQL хорошо читается глазами, хорошо подсвечивается в PhpStorm и отлаживать его гораздо проще, чем Query Builder с миксом из анонимных функций.
По моей схеме выше кажется, что чистый SQL занимает всего один пункт из четырёх, но на практике это не так уж мало!
Ещё одно возражение против написания SQL – я ухожу от высокоуровневых абстракций работы с сущностями и их связями и проваливаюсь на более низкий уровень хранения данных. Может лучше обернуть всю низкоуровневую работу как минимум в некий репозитории или использовать языки типа DQL? Может и лучше. Надо смотреть по ситуации.
Когда по проекту раскидано много уникальных и не тривиальных запросов на чистом SQL и, допустим, мы решили сделать рефакторинг реляционной схемы БД, в этом случае придётся перелопатить все вручную написанные SQL запросы, раскиданные по разным файлам и модулям – проблемка. Кажется, используя паттерн репозиторий, т. е. некие классы прослойки, инкапсулирующие конкретные SQL запросы, большой рефакторинг схемы данных был бы проще.
С другой стороны, подобные классы репозитории со временем накапливают в себе совершенно разношерстные SQL запросы, множество частных случаев и в итоге превращаются некие GOD репозитории (по аналогии с GOD Object или Helper или Utils классами). Либо, если делить классы репозитории по модулям и подсистемам их становится так много, мы возвращаемся к тому, с чего начали – SQL запросы размазаны по коду всего проекта, сложно рефакторить схему.
Как всегда то или иное решение – это компромисс или tradeoff. Мой опыт и мой выбор таков, что я не стесняюсь писать запросы на чистом SQL по месту их применения, не вынося всю работу с базой в некие репозитории. А когда придёт время рефакторинга PhpStorm мне поможет. Да, PhpStorm умеет рефакторить и SQL запросы тоже! Я могу переименовать таблицу или атрибут во вкладке Database и этот переименование произойдёт и в кодовой базе, но только в тех местах, где PhpStorm разспознал SQL язык, сделал так называемый language injection. Конечно, переименование и Find Usages в PhpStorm не покрывают всех сценариев рефакторинга схемы данных, но как это часто бывает по правилу Парето – в 80% случаев достаточно.
ORM, QueryBuilder’ы и прочие абстракции связывают руки при попытке использовать БД на полную катушку. Какой смысл выбирать между PostgreSQL, MySQL и Oracle, если ваша библиотека всё равно не умеет в upsert, lateral join, returning, json path и оконные функции?
В докладе я расскажу, как мы в Happy Inc. прошли путь от Doctrine ORM через DBAL и кастомный QueryBuilder до нативных запросов в чистом виде, и объясню, почему это во всех смыслах выгодное архитектурное решение.
Поговорим на несколько разных тем: подкаст и конференция YaTalks, первые впечатления от Yii3, PHP 8.1 уже близко, Tinkerwell, Mac mini на M1, механические клавиатуры и коврик для мыши с JSON API.
Второй подкаст в серии про Битрикс. Иван Поддубный из компании Вебпрактик рассказывает про свой опыт разработки крупных проектов на Битрикс и сравнивает с другими фреймворками и стеками технологий.
Что используется в Вебпрактик: Битрикс, Laravel, NodeJS
Почему 80% проектов на Битрикс, почему?
Кто типовой заказчик?
Как Битрикс выиграл рынок заказной разработки крупных проектов?
Почему страдают крупные заказчики поставившие на .NET и Ruby?
Есть ли у Битрикс преимущество по скорости разработки и в удобсте поддержки?
На сколько велика разница в подходах к кодированию между Битрикс и Laravel? Роутер? Контроллеры? Модели? ORM? API?
Подход по скрещиванию Laravel с Битрикс в одном проекте, в одной кодовой базе
Почему от этого подхода решили отказаться?
Какие готовые решения по бизенс-логике даёт Битрикс?
Админка Битрикс — хороша или нет?
В админке так много функций, что есть целые обучающие видеокурсы для администратора, для контент-менеджера и проч.
Инициатива в Drupal по переписыванию админки на React
Ограничения, которые накладывает Битрикс. Часто ли упираешься в архитектуру Битрикса?
Производительность Битрикса
Что делать с номенклатурой в несколько сотенд тысяч позиций и таким же количеством свойств?
Микросервисы на NodeJS вокруг Битрикс монолита
Отказ от PHP шаблонов в пользу React и SPA
Кадровый вопрос поиска фронтенд разработчика
Тренд на SPA?
Битрикс управление сайтом vs Битрикс24
Процесс деплоя Битрикс
Поставка Битрикс проектов с помощью Docker в Kubernetes
Реверс-инженеринг миграций ядра
Поддержка со стороны компании 1С-Битрикс
Темпы развития ядра
Взгляд на развитие Битрикса со стороны внедрения
Важность обратной совместимости, антипримеры перехода с Magento 1 на Magento 2, переписывание Drupal, ModX Evolution vs Revolution, Python 2 vs Python 3.
Top 3 проблем Битрикс: дистрибьюция (composer?), встроенный механизм миграций, полноценный DI по всему ядру
Для этого выпуска подкаста я пригласил двух разработчиков ядра Битрикс: Дмитрия Медведева и Ивана Челищева. Обсудили историю развития Битрикс, что такое ядро и Bitrix Framework, что такое D7, как выглядит разработка под Битрикс сейчас и какие планы на будущее.
Темы выпуска:
Краткая справка про компанию 1С-Битрикс
Какие версии PHP поддерживаются?
Обратная совместимость
На сколько Bitrix Framework похож на другие PHP фреймворки?
Переписывание фреймворка «с нуля» в начале 2010-х
Гибридное ядро для поддержания обратной совместимости
Битрикс Управление Сайтом vs Битрикс24 — общее ядро внутри?
Кто заказчик для команды разработки ядра?
Секретный чат тимлидов разработчиков на Битрикс
Можно ли использовать Bitrix Framework отдельно от продуктов 1С-Битрикс?
Про технологии в актуальной версии D7:
Используются суперглобальные массивы $_GET, $_POST?
ORM, QueryBuilder и работа с базой
Active Record или Data Mapper?
Почему не Doctrine?
Миграции и система обновлений
Поддержка различных СУБД?
Почему нет PostgreSQL?
Роутинг и точки входа
Шаблонизация, защита от XSS, подключение внешних шаблонов
Работа с очередями, агенты
IoC контейнер или Service Locator?
Autowiring в контроллере
Консольные команды на основе symfony/console
Другие внешние библиотеки
Используется ли composer?
Код в публичной директории?
Сборка PHP кода
Сборка фронтенд кода: инструмент Bitrix CLI на основе Rollup
На сколько код в целом выглядит современно?
PhpStorm и плагины
Что планируется в будущем Bitrix Framework 3?
концептуальный прототип
переработанный жизненный цикл
Twig с CMS-ориентированными плагинами
пока не публично
сбор обратной связи от разработчиков
переход должен быть плавным
почему бы не взять Symfony или Laravel и писать поверх?
ориентация на PSR
сложность по интеграции со старым API и поддержки совместимости
сколько ресурсов выделено на разработку Bitrix Framework 3?
как организована командная разработка внутри компании 1С-Битрикс?
В завершение:
На Битрикс24 используется не только PHP, но и Node.js и другие технологии
