Ошибка копирайтера после сокращения текста :) Я имел в виду, что JIT позволяет оптимизировать участок PHP кода, использующий fgetcsv(). Потому что не придется её интерпретировать заново на каждой итерации.
Нет, пока таких кейсов не было. Потому что были буквально единичные обращения людей с возрастом 40+. Но дальше этапа собеседования мы не продвинулись. Т.е. это не было никак связанно с возрастом.
Но если смотреть в общем, какая основная проблема смены профессии в зрелом возрасте — деньги. Одно дело получать ставку джуна после университета, а другое, когда у вас семья, дети, ипотека.. Поэтому, все-таки 99% заявок на стажировку - это студенты.
Вспомнилось, как-то много лет назад, когда я был молодой и зеленый, был у меня суровый, подвыгоревший тимлид-руководитель. Стоит он у окна и смотрит, как рабочие асфальт укладывают. Глаза стали такими грустными.. И он говорит, что вот же есть же нормальная работа! На свежем воздухе, физическая, всё понятно, никаких проблем и тяжелых митингов! Не то что это гребаное АйТи! И уволился. Уж не знаю куда он пошёл работать.
Я считаю, что не каждый может вынести эту ношу обязанностей и ответственности, которые возлагаются на тимлида. Потому что это сложно и нервно.
Но если уж кто-то решился быть ТЛ, то давайте поможем ему с этим! А поскольку работа больше менеджерская и процессная, то без азов таймменеджмента, планирования, процессов разработки - ничего не получится, будет снова выгоревший ТЛ, который уйдет из профессии. А хороших ТЛ итак мало :(
А вы уверены, что Symfony является тем самым единственным фреймворком, на котором стоит всё разрабатывать? Я вот не уверен. При всём моём уважении к Symfony, на котором я разрабатывал несколько лет, пока не ушёл в управление.
Я никогда сам не был разработчиком на Laravel, но текущуя коньюктура рынка, в частности заказной разработки, это миграция массового сегмента с Битрикса на Laravel. Потому что быстро, даёт хороший буст и нет проблемы со специалистами.
Это также сказываестя на количестве специалистов, срез по habr карьере https://career.habr.com/ :
При всей правильности подходов в Symfony, это не быстрая рабочая лошадка для запуска проектов. У нас есть проекты на симфони, но это крупный ecom рапиленный на SOA.
Да и тут, если честно, уже вырисовывается крепкий конкурент на ларе: https://ensi.tech/
Хорошо. Вам нужно разработать контентный сайт, основной стек Laravel. Контента много, куча свойств разных типов, тегов и всё это необходимо редактировать быстро и удобно. Предложите адекватный административный интерфейс. При этом сроки/бюджеты не позволяют разрабатывать админку с 0, в том числе и её дизайн/маркап.
Мы его попробовали, т.к. гибкость и скорость настройки интерфейса идеально подходила под ТЗ. Успешно реализовали проект и поделились своим мнением с сообществом. Честно пишем про плюсы и минусы данного решения. В том числе про требовательность к ресурсам. Мы же не агитируем на него всем переходить!
Filament это административный интерфейс на Laravel с набором гуев и понятной структурой. Он нужен исключительно для того, чтобы самому не собирать админку для сайта с 0. Это не CMS типа Битрикса.
А дальше, пользовательский фронт и бек - это разные репы и контейнеры, которые разрабатываются разными командами и взаимодействуют по API, всё по канонам :)
Рассказываешь про опыт на Битрикс - отвечают, что хорошие решения только на Laravel
Рассказываешь про новую админку на Laravel - отвечают, что хорошие решения только на Symfony
Была статья про проект на Symfony - ответили, что нужен Python
В статье про монолит на Python - комменты, что почему не микросервисы?
А в статье про решение на микросервисах - угадайте... комментируют, что надо наворачивать ecom на Битрикс, потому что там многое уже есть из коробки!
Круг замкнулся!
А дело в том, что решения можно делать, на чём угодно, хоть на паскале. Всё зависит от кривизны рук конечного исполнителя.
Спор Битрикс/Laravel/Symfony/Yii априори бессмысленный. У каждого фреймворка свой круг задач.
ИМХО Laravel с не сложным порогом входа и лёгок в эксплуатации. А на Symfony делать контентные сайты - как из пушки по воробьям. В статье как раз разбирается Laravel админка для быстрых решений.
Вообще, исторически, мы использовали Laravel только для создания BFF либо мидлваров. Основную разработку на PHP ведём на Symfony и Битриксе. Карьерный сайт, это должно быть лёгкое решение, которое не должно тащить за собой ограничений по лицензии, кучу пакетов и порог входа для доработки. Поэтому мы выбрали более лёгкий Laravel. Тут можно разводить холивар про Symfony и Laravel... мы больше отталкивались от того, что сферическому PHP разработчику в вакууме в разы проще освоить и разобраться в ларе, чем в симфони. А коробка должна быть доступна для доработки каждому, в этом и смысл гибкости.
Сравнивали несколько админок с точки зрения, где проще дорабатывать и адаптировать под клиента, а главное с наличием визивиг редактора. Сначала выбрали Twill, именно больше из-за редактора, на котором быстро реализовали конструктор лендингов.
Затем познакомились со сравнительно новым решением FilamentPHP, которое даёт ещё больше возможностей удобно кастомить интерфейс админки. Пример:
Конечно. Например, имеет смысл горизонтального масштабирования консумеров, читающих партиции из одного топика, когда порядок считывания сообщений не важен.
Если это какие-то статистические данные, которые можно считать из N партиций в N потоков и всё смешать в системе потребителя. Считывать заказы из нескольких партиций, уже не вариант, иначе может нарушиться хронология статусов.
Разрабатываемое и поддерживаемое нами web-приложение является небольшим звеном большой IT инфраструктуры заказчика, в которую входят другие приложения, физические магазины, склады и тд. Поддержкой и развитием Apache Kafka в данном случае мы не занимались, поэтому я не могу сообщить объём данных, проходящий через брокера.
Я понимаю Ваш вопрос, насколько сильно нужно «разогнаться», чтобы не хватило кролика. Когда начинаются высоконагруженные BigData системы и сотни тысяч сообщений в секунду и горизонтально масштабировать RabbitMQ становится уже затратно. Думаю, что роль Kafka также будет правильно рассматривать, как часть ESB, когда Kafka дополняет её своими плюшками и отказоустойчивостью.
Видел материал, как искусственно сравнивали скорость работы на больших данных кафки и кролика:
Я ответил в комментарии ниже за что и когда выдаются баны. Мы не вводим пользователя в заблуждение и не отдаём разный контент меняющий смысл страницы. Контент и внешний вид страницы для поисковика и контент страницы для неавторизованного пользователя отличается только наличием тегов <script>.
Неавторизованный пользователь видит страницу с контентом. Для него отдаётся такая же отренедеренная версия, что и для поисковика, но со всем JS. И запускается механизм регидратации, чтобы актуализировать DOM, события и тд.
Первая проблема: после отдачи уже отрендеренной страницы пользователю, отрабатывают события загрузки страницы и JS начинает заново пересоздавать блоки, начинается мигание, происходит двойная загрузка страницы...
Здесь нужно научит клиентский код понимать, что текущая страница уже готова, на ней уже есть необходимые DOM объекты и загружать ничего не нужно.
Вторая проблема это актуализация страницы. Контент-менеджер обновил описание элемента в админке. Кеш в битриксе сбросится автоматически, а вот отрендеренная страница об этом ничего не знает и поисковик/неавторизованный пользователь видит старый контент, а авторизованный пользователь новый.
И тут нужно подписываться на обновления кеша либо апдейты контентных таблиц и прокидывать из битры триггер на перегенерацию страницы.
Только авторизованный пользователь - видит скелет. И это сознательное допущение, чтобы не перерисовывать на лету контент, который видоизменяется для авторизованного. Не могу сказать, как это реализуется при использовании других технологий пререндеринга, возможно имеются какие-то изящные решения для авторизованных.
Боты поисковых систем видят только облегченный вариант (с высокой скоростью загрузки)?
Да, при прямом заходе бота (с заголовками, UA бота), PageSpeed Insights выдаёт 90+. И вы правы, когда гугл "притворяется" пользователем, то он увидит уже отрендеренную версию страницы, но уже плюс JS, аналитика и тд. и оценка будет 80+.
А на закрытые для определённых групп пользователей страницы, страницы в авторизованном режиме, в общем на не отрендеренные страницы - гугл уже не попадёт.
И как тут не будет бана за подмену страниц?
Да, у нас тоже были переживания по этому поводу. Помимо описанного вами случая, поисковики ещё собирают информацию из реального сеанса пользователя, в том числе когда он авторизован.
Консультировались по поводу случаев когда происходит бан страниц. Поисковые системы, когда обнаруживают существенные разницы в страницах, помечают их как подозрительные и отдают на верификацию человеку. Производится сверка страницы и бан выдаётся "если подменённый контент вводит пользователя в заблуждение".
Т.е. если для гугла сайт отдаёт страницу с ромашками и в поисковом индексе ромашки. Пользователь переходя из поисковой выдачи думает, что попадает на сайт про ромашки, а в реальности подменяется контент и пользователю отдаётся страница с покупкой Чебурашек - будет бан. Такой разницы у нас конечно нет.
Также добавлю, что проект категории "не для всех". При заходе на сайт пользователь попадает на страницу верификации. Это отдельная страница выдающаяся по любому адресу сайта. Т.е. в исходном состоянии поисковая система видит только страницу верификации и не индексирует контент.
У нас уже несколько лет, ещё до внедрения Vue.js, используется механизм определения поискового бота, я немного рассказал про него в статье. Когда на сайт заходит поисковик, то он не уходит на страницу верификации, а сразу видит весь контент и может его индексировать. И даже при таком условии у нас не возникало проблем с индексацией и банами.
Скажу честно, внушает доверие, что Puppeteer предлагают сами разработчики Lighthouse, как решение для веб-приложений, архитектура которых не предусматривает заложенный изначально SSR.
Есть риск, что гугл в будущем изменит свою политику? Только одному гуглу известно :) Риски есть всегда. Мы сделали пробу пера с реактивным фреймворком, почти не изменяя текущий код бекенда, результат нас устроил. А дальше уже будет по классике: Bitrix + GraphQL + Nuxt.js ))
Ошибка копирайтера после сокращения текста :) Я имел в виду, что JIT позволяет оптимизировать участок PHP кода, использующий fgetcsv(). Потому что не придется её интерпретировать заново на каждой итерации.
Нет, пока таких кейсов не было. Потому что были буквально единичные обращения людей с возрастом 40+. Но дальше этапа собеседования мы не продвинулись. Т.е. это не было никак связанно с возрастом.
Но если смотреть в общем, какая основная проблема смены профессии в зрелом возрасте — деньги. Одно дело получать ставку джуна после университета, а другое, когда у вас семья, дети, ипотека.. Поэтому, все-таки 99% заявок на стажировку - это студенты.
Вспомнилось, как-то много лет назад, когда я был молодой и зеленый, был у меня суровый, подвыгоревший тимлид-руководитель. Стоит он у окна и смотрит, как рабочие асфальт укладывают. Глаза стали такими грустными.. И он говорит, что вот же есть же нормальная работа! На свежем воздухе, физическая, всё понятно, никаких проблем и тяжелых митингов! Не то что это гребаное АйТи! И уволился. Уж не знаю куда он пошёл работать.
Я считаю, что не каждый может вынести эту ношу обязанностей и ответственности, которые возлагаются на тимлида. Потому что это сложно и нервно.
Но если уж кто-то решился быть ТЛ, то давайте поможем ему с этим! А поскольку работа больше менеджерская и процессная, то без азов таймменеджмента, планирования, процессов разработки - ничего не получится, будет снова выгоревший ТЛ, который уйдет из профессии. А хороших ТЛ итак мало :(
Еее, давай!
А вы уверены, что Symfony является тем самым единственным фреймворком, на котором стоит всё разрабатывать? Я вот не уверен. При всём моём уважении к Symfony, на котором я разрабатывал несколько лет, пока не ушёл в управление.
Я никогда сам не был разработчиком на Laravel, но текущуя коньюктура рынка, в частности заказной разработки, это миграция массового сегмента с Битрикса на Laravel. Потому что быстро, даёт хороший буст и нет проблемы со специалистами.
Это также сказываестя на количестве специалистов, срез по habr карьере https://career.habr.com/ :
По запросу Laravel Найдено 55 вакансий, Symfony Найдено 39 вакансий, Bitrix Найдено 38 вакансий, Yii Найдено 17 вакансий.
При всей правильности подходов в Symfony, это не быстрая рабочая лошадка для запуска проектов. У нас есть проекты на симфони, но это крупный ecom рапиленный на SOA.
Да и тут, если честно, уже вырисовывается крепкий конкурент на ларе: https://ensi.tech/
Хорошо. Вам нужно разработать контентный сайт, основной стек Laravel. Контента много, куча свойств разных типов, тегов и всё это необходимо редактировать быстро и удобно. Предложите адекватный административный интерфейс. При этом сроки/бюджеты не позволяют разрабатывать админку с 0, в том числе и её дизайн/маркап.
У нас есть опыт разработки проектов на готовых админках для Laravel: https://twillcms.com/ https://orchid.software/ru/ https://delphinpro.gitbook.io/voyager-ru и https://octobercms.com/
Нельзя сказать, что какое-то решение идеальное и отвечает всем запросам.
В сообществе Laravel зарелизили новое решение https://filamentphp.com/ Между прочим 14к звёзд https://github.com/filamentphp/filament Не сказать, что какой-то ноунейм.
Мы его попробовали, т.к. гибкость и скорость настройки интерфейса идеально подходила под ТЗ. Успешно реализовали проект и поделились своим мнением с сообществом. Честно пишем про плюсы и минусы данного решения. В том числе про требовательность к ресурсам. Мы же не агитируем на него всем переходить!
Не понимаю критики, честно.
Laravel не популярный стек?)
Filament это административный интерфейс на Laravel с набором гуев и понятной структурой. Он нужен исключительно для того, чтобы самому не собирать админку для сайта с 0. Это не CMS типа Битрикса.
А дальше, пользовательский фронт и бек - это разные репы и контейнеры, которые разрабатываются разными командами и взаимодействуют по API, всё по канонам :)
Рассказываешь про опыт на Битрикс - отвечают, что хорошие решения только на Laravel
Рассказываешь про новую админку на Laravel - отвечают, что хорошие решения только на Symfony
Была статья про проект на Symfony - ответили, что нужен Python
В статье про монолит на Python - комменты, что почему не микросервисы?
А в статье про решение на микросервисах - угадайте... комментируют, что надо наворачивать ecom на Битрикс, потому что там многое уже есть из коробки!
Круг замкнулся!
А дело в том, что решения можно делать, на чём угодно, хоть на паскале. Всё зависит от кривизны рук конечного исполнителя.
Спор Битрикс/Laravel/Symfony/Yii априори бессмысленный. У каждого фреймворка свой круг задач.
ИМХО Laravel с не сложным порогом входа и лёгок в эксплуатации. А на Symfony делать контентные сайты - как из пушки по воробьям. В статье как раз разбирается Laravel админка для быстрых решений.
Вообще, исторически, мы использовали Laravel только для создания BFF либо мидлваров. Основную разработку на PHP ведём на Symfony и Битриксе. Карьерный сайт, это должно быть лёгкое решение, которое не должно тащить за собой ограничений по лицензии, кучу пакетов и порог входа для доработки. Поэтому мы выбрали более лёгкий Laravel. Тут можно разводить холивар про Symfony и Laravel... мы больше отталкивались от того, что сферическому PHP разработчику в вакууме в разы проще освоить и разобраться в ларе, чем в симфони. А коробка должна быть доступна для доработки каждому, в этом и смысл гибкости.
Сравнивали несколько админок с точки зрения, где проще дорабатывать и адаптировать под клиента, а главное с наличием визивиг редактора. Сначала выбрали Twill, именно больше из-за редактора, на котором быстро реализовали конструктор лендингов.
Затем познакомились со сравнительно новым решением FilamentPHP, которое даёт ещё больше возможностей удобно кастомить интерфейс админки.
Пример:
Получается так:
Красота же!
У нас PHP отдел один из самых больших по количеству сотрудников, видимо, хорошо работаем с их мотивацией :)
Конечно. Например, имеет смысл горизонтального масштабирования консумеров, читающих партиции из одного топика, когда порядок считывания сообщений не важен.
Если это какие-то статистические данные, которые можно считать из N партиций в N потоков и всё смешать в системе потребителя. Считывать заказы из нескольких партиций, уже не вариант, иначе может нарушиться хронология статусов.
Разрабатываемое и поддерживаемое нами web-приложение является небольшим звеном большой IT инфраструктуры заказчика, в которую входят другие приложения, физические магазины, склады и тд. Поддержкой и развитием Apache Kafka в данном случае мы не занимались, поэтому я не могу сообщить объём данных, проходящий через брокера.
Я понимаю Ваш вопрос, насколько сильно нужно «разогнаться», чтобы не хватило кролика. Когда начинаются высоконагруженные BigData системы и сотни тысяч сообщений в секунду и горизонтально масштабировать RabbitMQ становится уже затратно. Думаю, что роль Kafka также будет правильно рассматривать, как часть ESB, когда Kafka дополняет её своими плюшками и отказоустойчивостью.
Видел материал, как искусственно сравнивали скорость работы на больших данных кафки и кролика:
https://medium.com/@vozerov/kafka-vs-rabbitmq-38e221cf511b
Я ответил в комментарии ниже за что и когда выдаются баны. Мы не вводим пользователя в заблуждение и не отдаём разный контент меняющий смысл страницы. Контент и внешний вид страницы для поисковика и контент страницы для неавторизованного пользователя отличается только наличием тегов <script>.
Неавторизованный пользователь видит страницу с контентом. Для него отдаётся такая же отренедеренная версия, что и для поисковика, но со всем JS. И запускается механизм регидратации, чтобы актуализировать DOM, события и тд.
Первая проблема: после отдачи уже отрендеренной страницы пользователю, отрабатывают события загрузки страницы и JS начинает заново пересоздавать блоки, начинается мигание, происходит двойная загрузка страницы...
Здесь нужно научит клиентский код понимать, что текущая страница уже готова, на ней уже есть необходимые DOM объекты и загружать ничего не нужно.
Вторая проблема это актуализация страницы. Контент-менеджер обновил описание элемента в админке. Кеш в битриксе сбросится автоматически, а вот отрендеренная страница об этом ничего не знает и поисковик/неавторизованный пользователь видит старый контент, а авторизованный пользователь новый.
И тут нужно подписываться на обновления кеша либо апдейты контентных таблиц и прокидывать из битры триггер на перегенерацию страницы.
Только авторизованный пользователь - видит скелет. И это сознательное допущение, чтобы не перерисовывать на лету контент, который видоизменяется для авторизованного. Не могу сказать, как это реализуется при использовании других технологий пререндеринга, возможно имеются какие-то изящные решения для авторизованных.
Да, при прямом заходе бота (с заголовками, UA бота), PageSpeed Insights выдаёт 90+. И вы правы, когда гугл "притворяется" пользователем, то он увидит уже отрендеренную версию страницы, но уже плюс JS, аналитика и тд. и оценка будет 80+.
А на закрытые для определённых групп пользователей страницы, страницы в авторизованном режиме, в общем на не отрендеренные страницы - гугл уже не попадёт.
Да, у нас тоже были переживания по этому поводу. Помимо описанного вами случая, поисковики ещё собирают информацию из реального сеанса пользователя, в том числе когда он авторизован.
Консультировались по поводу случаев когда происходит бан страниц. Поисковые системы, когда обнаруживают существенные разницы в страницах, помечают их как подозрительные и отдают на верификацию человеку. Производится сверка страницы и бан выдаётся "если подменённый контент вводит пользователя в заблуждение".
Т.е. если для гугла сайт отдаёт страницу с ромашками и в поисковом индексе ромашки. Пользователь переходя из поисковой выдачи думает, что попадает на сайт про ромашки, а в реальности подменяется контент и пользователю отдаётся страница с покупкой Чебурашек - будет бан. Такой разницы у нас конечно нет.
Также добавлю, что проект категории "не для всех". При заходе на сайт пользователь попадает на страницу верификации. Это отдельная страница выдающаяся по любому адресу сайта. Т.е. в исходном состоянии поисковая система видит только страницу верификации и не индексирует контент.
У нас уже несколько лет, ещё до внедрения Vue.js, используется механизм определения поискового бота, я немного рассказал про него в статье. Когда на сайт заходит поисковик, то он не уходит на страницу верификации, а сразу видит весь контент и может его индексировать. И даже при таком условии у нас не возникало проблем с индексацией и банами.
Скажу честно, внушает доверие, что Puppeteer предлагают сами разработчики Lighthouse, как решение для веб-приложений, архитектура которых не предусматривает заложенный изначально SSR.
Есть риск, что гугл в будущем изменит свою политику? Только одному гуглу известно :) Риски есть всегда. Мы сделали пробу пера с реактивным фреймворком, почти не изменяя текущий код бекенда, результат нас устроил. А дальше уже будет по классике: Bitrix + GraphQL + Nuxt.js ))