Сколько можно заработать на курсе по PHP?

Валентин Удальцов (https://t.me/phpyh) раскрывает свои доходы в прямом эфире!

  • Проработал в Happy Inc. 4 года, почему ушел?
  • В компании Вебинар.ру всего 3 месяца — что произошло?
  • Бесплатные консультации голосовыми сообщениями в телеге
  • Платные консультации и собеседования
  • Первый поток авторского курса по PHP для 5 человек
  • Обучающие видео на boosty, почему забросил?
  • На сколько упали доходы после увольнения с full time работы?
  • В чём текущая бизнес-модель и сколько стоит обучение на втором (текущем) потоке курса по PHP?
  • Сколько учеников и какой ежемесячный финансовый поток они генерируют?
  • Зарабатываешь ли ты на рекламе в телеграм канале Пых?
  • Платежи, комиссия кассы и автоматизация своего бизнеса
  • Каковы трудозатраты на ведение собственного дела? Ты сейчас вкалываешь больше или меньше по сравнению с full time работой программистом?

Самописные инфраструктурные компоненты

Тема этого выпуска: самописные инфраструктурные компоненты – зачем они нужны и чем не угодили Open Source аналоги, помимо фатального недостатка?

Отвечает Валентин Удальцов – автор телеграм канала Пых https://t.me/phpyh

  • Пишет ли Валентин собственный фреймворк?
  • Что такое инфраструктурный компонент? Определение
  • Примеры инфраструктурных компонент, написанных в команде Валентина: работа с БД, виладтор+гидратор на типах статанализа, шина сообщений
  • История появления библиотеки для работы с запросами к БД и чем не подошли популярные решения?
  • Учёт нюансов PostgreSQL, нативная работа с JSON в СУДБ
  • Неудобства Doctrine Query Language (DQL)
  • Неудобства Doctrine DBAL
  • Single Responsibility принцип в Doctrine
  • Конвертация типов из PHP в БД и в обратную сторону из БД в PHP
  • Коммит в Open Source библиотеку vs написание своей собственной реализации
  • Стоимость разработки самописных компонент для бизнеса
  • Мотивация команды
  • Распространение знаний внутри компании, документация
  • Тесты как документация
  • Сегодня самописные компоненты, а завтра самописный фреймворк?
  • Безопасность собственного решения
  • Свой фреймворк или свой Open Source как часть HR-бренда
  • Как отличить резонную разработку
  • Кто принимает финальное решение о старте собственной разработки вместо использования готового решения?
  • Подробности про собственную шину сообщений (Message Bus компонент)
  • Вопросы гарантированной доставки сообщений
  • Паттерн Outbox https://habr.com/ru/company/lamoda/blog/678932/
  • Недостатки Symfony Messanger Component
  • Работа с middleware в шине сообщений – разные middleware для разных обработчиков
  • Routing Topology
  • Exchange сообщения – Fanout – Exchange модуля/очереди
  • Поддержка паттерна Saga
  • Отделение класса с состоянием от класса с поведением, но с сохранением инкапсуляции
  • Когда будет опубликована библиотека для работы с запросами к БД Thesis? https://phprussia.ru/moscow/2021/abstracts/7654
  • Перфекционизм vs Тщательность
  • Польза не только от самописного решения, но и от знаний полученных в процессе его написания
  • Цели на 2023 год

Какой английский нужен разработчикам?

В этом выпуске Юлия Беймлина, продуктовый методист курса «Английский для разработчиков» от Яндекс Практикума, рассказывает, как эффективно заниматься изучением английского языка, и в чём особенности преподавания для конкретных профессий, например, для разработчиков.

  • В чём отличие преподавания английского языка для различных профессий (программисты, юристы, ученые…)?
  • «Можно говорить грамотно, но неуместно»
  • Английский для разработчика — отличается ли подход к обучению чисто программистов (кодеров) и тимлидов?
  • Какие бывают уровни знания английского? A1, A2, B1, B2, C1, C2 — что всё это значит?
  • Какого уровня достаточно для разработчика?
  • А для тимлида или IT-менеджера?
  • Сколько времени и усилий нужно для достижения этого уровня?
  • Что такое Intermediate-плато и как его пройти?
  • Культурный код и его значение уже на этапе собеседования
  • Что не важно при обучении английскому языку?
  • Как тренировать произношение?
  • Насколько русский акцент понятен на слух?
  • Грамматические ошибки: критичные и нет
  • Самостоятельное обучение до уровня B2 — это реально?
  • Рецептивные и продуктивные навыки
  • Полезные инструменты и программы для изучения английского языка (в том числе внутри PhpStorm!)
  • Пополнение словарного запаса по карточкам — насколько это эффективно?

Этот выпуск выходит при поддержке Яндекс Практикума.

Узнать больше о курсе «Английский для разработчиков»: https://clck.ru/qzoT9

Приложения, упоминавшиеся в подкасте:

Также рекомендую послушать другой подкаст с участием Юли: «Запуск завтра. Как учить английский»

Удивительно, насколько разные бывают подкасты, казалось бы, с одной темой и одним гостем! В «Запуске завтра» были раскрыты совершенно другие вопросы, очень интересно получилось, рекомендую.

Чистый SQL или ORM и Query Builder?

Небольшая заметка с полей.

Недавно втянулся в использование 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% случаев достаточно.

Под конец дам ссылку на презентацию доклада Валентина Удальцова с PHP Russia 2021. Процитирую основные тезисы:

ORM, QueryBuilder’ы и прочие абстракции связывают руки при попытке использовать БД на полную катушку. Какой смысл выбирать между PostgreSQL, MySQL и Oracle, если ваша библиотека всё равно не умеет в upsert, lateral join, returning, json path и оконные функции?

В докладе я расскажу, как мы в Happy Inc. прошли путь от Doctrine ORM через DBAL и кастомный QueryBuilder до нативных запросов в чистом виде, и объясню, почему это во всех смыслах выгодное архитектурное решение.

https://phprussia.ru/moscow/2021/abstracts/7654

Всем SQL!

Рынок труда в России 2022

Обсуждаем рынок труда с Глебом Кудрявцевым.

  • Кому проще уехать: IT менеджеру, сеньору, мидлу?
  • По каким причинам IT специалисты уезжают из России и будет ли нарастать отток кадров?
  • Чего не хватает IT бизнесу в России?
  • Как изменился рынок труда? Конкуренция за специалистов усилилась или наоборот, стала меньше?
  • Из-за ухода многих компаний стало ли сложнее найти работу? Кому?
  • Какой язык нужно учить? JavaScript vs Английский
  • Будет ли взрывной рост зарплат для дефицитных программистов, обгоняющий инфляцию во много раз?
  • Деньги останутся только у больших и около государственных компаний?
  • Учите языки и культуры заранее, может пригодиться в любой непонятной ситуации!

Оптимизация производительности в Composer 2.2

В декабре 2021 года вышло обновление пакетного менеджера Composer, версия 2.2. Заявлено увеличение производительност в некоторых случаях на 90%.

https://blog.packagist.com/composer-2-2/

Как это возможно и почему Composer раньше был на столько прожорливым? Я изучил изменения в исходном коде и вот что я нашел…

Читать далее Оптимизация производительности в Composer 2.2

Лучшая механическая клавиатура для PHP в 2022?

В обзоре участвовали следующие клавиатуры:
0:00 – Keychrone K3, Blue (оценка 4)
1:04 – Varmilo VA87Mac, Brown (оценка 4)
1:58 – Keychrone K1, Red (оценка 5-)
2:58 – Keychrone K12, Brown (оценка 3)
4:40 – Keychrone K8, Brown (оценка 5)
5:38 – GMMK, Silver (оценка 5)
8:01 – ESPORTS FL680 (оценка 4)
9:18 – Varmilo MA87M Moonlight (оценка 5-)
10:51 – подведение итогов, TOP 3 клавиатуры!

Ежегодный опрос PHP сообщества

В конце прошлого (2020) года прошел первый большой опрос русскоязычного PHP-сообщества в котором приняло участие свыше 1500 человек (результаты прошлого года).

С декабря 2021 по середину ярваря 2022 проходил аналогичный опрос, составленный активными участниками нашего сообщества. Фокус на технологиях и контенте.

Понадобится некоторое время на обработку результатов и в феврале 2022 будут опубликованы результаты в виде интерактивных графиктов и доступного для скачивания архива на сайте phpcommunity.ru. Список лучших видео, статей и инструментов будет опубликован на Хабре.

[Здесь раньше была ссылка «Принять участие в опросе». Опрос уже закрыт, скоро будет ссылка на результаты.]

Как работает OPcache?

Один из основных на сегодняшний день разработчиков PHP Никита Попов рассказал в своём блоге некоторые детали работы OPcache.

OPcahce — это расширение для PHP, которое ускоряет работу за счёт кэширования опкодов.

В этом выпуске подкаста Пятиминутка PHP сделаю краткий пересказ, поробую объяснить своими словами.

https://www.npopov.com/2021/10/13/How-opcache-works.html