В четверг вышел PHP 8.1, а я, как работник кровавого энтерпрайза, все еще на 7.4.

Мне кажется, идут в ногу с релизами зачастую или молодые компании, или те, кто выжимает из языка максимум скорости. За ними тянутся компании, где тех лиды могут пропихнуть рефакторинг менеджерам.

А вот особняком стоят CMSки и аутсорсинг проекты которые уже прошли стадию активной разработки.
Например, Magento с поддержкой PHP 8.1 выйдет только весной.


Ну а почитать про новинки языка можно тут https://www.php.net/releases/8.1/ru.php

Напишите в комментарии, как в вашей компании обстоят дела с обновлением версии языка.

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

Держите одну из них, там про Magento, однако большинство ошибок, подпаливших пятые точки девелоперов на Black Friday - вполне себе могут произойти и с вашим кодом.

P.S. Скорее всего люди с опытом highload не найдут для себя ничего сильно полезного, ребята в статье попались на ошибки новичков.


https://dou.ua/forums/topic/35426/

История о том, как парень написал свой elasticsearch на php и что из этого вышло.

А какие нестандартные решения писали вы? Расскажите в комментариях

https://habr.com/ru/post/595765/

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

Найди 5 минут, чтобы подвести итоги своего PHP-года:

https://phpsurvey.typeform.com/to/FeIOkDIP

Тут завезли немного здравого смысла, правда сильно смешали его с личными предпочтениями автора, и отсутствием хороших примеров использования NoSQL.

Почему SQL в решении большинства задач лучше, чем NoSQL базы данных, и когда все-таки брать NoSQL?

https://habr.com/ru/post/596969/

Вдогонку к посту про БД: тут недавно обнаружили старый баг MySQL и MariaDB, который позволяет писать выражения, пропускаемые большинством firewalls и прочих костылей для обнаружения SQL-injection в запросе.

Поэтому пишите безопасный код с обязательным экранированием всех параметров прямо на PHP, не нужно писать говнокод в надежде на какой-то плагин для nginx!


https://habr.com/ru/news/t/585346/

Сейчас из каждого утюга можно услышать: ML, нейросети, обучение.

А вы знали, что для того, чтобы потрогать нейросети и даже запустить свою не обязательно учить Python или R? Попробовать можно даже на PHP.

Вот есть парочка библиотек https://habr.com/ru/company/otus/blog/599985/

А вот еще расширение для PHP, оно устарело и больше не поддерживается, но для того чтоб потрогать и понять - нравится/не нравится - этого достаточно


Для реального проекта все-таки стоит выбрать другой язык, но потрогать можно уже здесь и сейчас!

P.S. Знаете, откуда выражение «из каждого утюга»? Если советский утюг старой модели воткнуть в розетку радиоточки, можно услышать радио, тихо правда.

Вот тут можно найти пачку полезных функций/команд/шорткатов для phpstorm https://masteringphpstorm.com/tips-and-tricks

Хорошая статья о том, как ребята внедряли статический анализ и что из этого вышло https://habr.com/ru/company/rusprofile/blog/649257/

А вы когда-нибудь задумывались о том, нравится ли вам PHP, и насколько вы представляете себя серьезным программистом?

Не стоит стыдиться PHP.

Если вы живете в СНГ, или имеете хороший багаж в какой-нибудь популярной CMS - то, скорее всего вы будете довольны своей работой на PHP, и все будет хорошо. Нет, я не говорю, что язык плохой - очень даже хороший, и ООП можно красивое построить, и в целом код выглядит отлично и понятно, учитывая то, что у нас нет тонн синтаксического сахара.
Но если вдруг вам захочется в FAANG, придется переучиваться.

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

Статья меня не убедила, но может убедит вас:

https://habr.com/ru/post/652545/

Отличная статья о некоторых тонкостях настройки nginx, нашел даже на своем сервере пару промахов https://habr.com/ru/company/nixys/blog/661233/

Не используйте получение защищенных куками json данных через GET запрос!

Если вы:
1. Используете AJAX GET чтобы получить данные пользователя
2. Для авторизации на этом эндпоинте используете куки
3. Возвращаемые данные в формате JSON

То поздравляю, вы уязвимы для json hijacking! Пора поменять хотяб один из этих трех пунктов.

Подробности тут: https://habr.com/ru/post/63176/

Большую часть жизни пишу код под Magento и Symfony, и, знаете, я настолько привык использовать геттеры и сеттеры, что нововведения PHP 8 в виде объявления свойств в конструкторе с последующим использованием публичных или readonly свойств мне как будто режет глаз.


С одной стороны код получается короче и пишется быстрее, но уже давно существуют кодогенераторы, которые делают все за тебя.

А вы используете публичные свойства?

Вот вам еще одна статейка по безопастности веб приложений, на этот раз о SSRF


https://habr.com/ru/company/solarsecurity/blog/590673/

Всем привет!

Заметил, что в большинстве компаний на постсоветском пространстве собеседования, обычно, сводятся к тому, насколько человек знает отличия класса, от интерфейса, может ответить, что выведет код

$a = “a1” + “1a”;

Пары каких-нибудь вопросов с подвохом, ну и сопутствующие технологии, будь то джоины в MySQL, композеры, докеры etc.

Часто завершается такое собеседование соревнованиями вида «чье ооп круче», паттернами и SOLIDом.

Приученный к такому, довольно простому ходу собеседований я окунулся в мир FAANG, где твое ООП ничего не значит, а подробное знание настроек elasticsearch - лишь приобретаемый навык, который вообще никого не волнует.

И в этот момент уверенные в себе Senior PHP/FullStack/etc девелоперы часто становятся в один ряд с обычными зелеными джунами, только что вставшими на путь истинный.


В общем, я хочу вам поведать, как же все-таки стать тем самым Senior Software Engineer по мнению крупных компаний, из чего состоят собеседования, и почему попасть в FAANG (уже MAANG) гораздо проще чем вы думаете.

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

Итак, приступим.


Собеседование в топ компании обычно состоит из многих этапов, начиная с созвона с HR, и заканчивая многочасовым собеседованием, где матерые разработчики по очереди будут приходить и показывать вам, какое вы ничтожество, нет, на самом деле все дружелюбны, максимально вежливы, и всегда готовы помочь.

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

Обычно основные этапы делятся на два типа - алгоритмы и архитектура.

Я начну не по порядку, и поделюсь с вами, на мой взгляд, одной из самых точных статей по этому поводу.

Но прежде чем начать читать, я хочу еще раз подчеркнуть, что System Design - это НЕ проверка ваших знаний!! Вам нужно показать не свои знания и опыт, а как вы думаете, ошибаетесь, предполагаете, и что будете делать в той или иной ситуации. Главный совет - забудь весь свой опыт и начни думать «с нуля»!

https://habr.com/ru/amp/post/516718/

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

https://youtube.com/playlist?list=PLBRXq5LaddfzDBjg6soIwJJA2klXXs6ni

Алгоритмы.

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

Для подготовки требуется понять что такое сложность алгоритма по времени и по памяти

https://tproger.ru/articles/computational-complexity-explained/

ну и потратить от 100 часов на leetcode.com на решение разнообразных задач. А так как все мы любим решать сложные, никому не нужные проблемы методами, которые никому не известны (отсылка к анекдоту, если кто не понял), то такая подготовка - одно удовольствие.


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

Скорее всего именно поэтому многие стартапы отказываются от такого подхода, и вместо решения задач гоняют по языкам.

Еще одна, не менее важная часть - это так называемое «поведенческое» интервью. Обычно вопросы по этому поводу задают те же интервьюеры сразу после решения задач, но иногда выделают отдельное собеседование по этому поводу.


Простым языком - самый основной вопрос я уже писал в одном из прошлых постов: «какую встретили проблему, как решили, где ошиблись, и какие сделали выводы».

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


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

Например - Амазон имеет 17+ (они все еще пополняются) так называемых принципов лидерства, к каждому из которых необходимо подготовить историю из личного опыта.

Вот тут можно почитать про них подробнее:

https://habr.com/ru/amp/post/645045/

Меня тут недавно попросили рассказать про гит для ребят, только начинающих свой путь в разработке ПО, и я понял, что мне очень нравится рассказывать что-то, что я знаю. А потом посыпались вопросы по каким-то нюансам, и вдруг оказалось, что рассказывать то, что я не знаю - еще более увлекательно 🤣

И тут я подумал - а не заняться ли мне инфоциганством в мире IT?

Было ли бы интересно кому-то из вас узнать что-то новое/старое но более подробно на паре-тройке небольших видеомитингов в формате «первый бесплатно, а потом, как пойдет»? Ставь лайк, если да, и какаху, если инфоцигане задолбали.

Навскидку приходят разные темы, от инструментов вроде git, ngrok, сервисов типа elasticsearch, nginx, varnish и до каких-то вещей внутри языка вроде алгоритмов, ООП. А может даже что-то про серверы, bash scripting etc. Ну и конечно - можно поговорить о Magento, ведь разрабов там постоянно не хватает, зарплаты х2 от обычного ларавельщика, ООП не хуже чем в симфони, интересных задач хватает (вроде каталога на 2 млн продуктов, которые нужно синхронизировать каждые два часа) а сама мажента таки в ближайшие лет 5 точно не умрет (а потом можно будет свалить куда-то в смежную область)

Заодно прикрепляю опрос, чтоб узнать, какого уровня кунг-фу у большинства из подписчиков.