Комментарии 139
Ситуация в СНГ-сообществе усугубляется его токсичностью.
Не считаете ли вы свою статью токсичной?
p.s.: kotlin понимает
Тип переменой в Java можно не указывать начиная ещё с 10 версии.
С другой стороны, это иногда не костыль, а нужная информация. К тому же, тип переменой может отличаться от названия класса экземпляр которого мы этой переменой присваиваем.
Тип переменой в Java можно не указывать начиная ещё с 10 версии.Насколько мы помним — только в локальных переменных, при чем при условии что они сразу инициализируются.
Переменные классов, типы возвращаемых значений, объявление переменных с поздней инициализацией, параметры функций и т.д. и т.п. — вездеж надо указывать практически.
типы указывать надо и понимание типа сильно облегчает чтение кодаДля понимания типа достаточно подсказок IDE, не обязательно руками набирать, показывается вычислимый тип и всё.
Особенно когда тип не просто Int, а что-нибудь посложнее.
И главное прописывать приходится в нескольких местах (определение функции, определение переменной куда идет возврат функции, определение переменной в функции для хранения возвращаемого значения до возврата… и т.д.)… а если надо сменить — снова бегай по всем местам и меняй.
java до сих пор тип переменной не понимает без специального костыля перед ее именем в объявлении:)
var в джаве уже года 3 как есть.
и мой вопрос: язык научился понимать что перед ним переменная без знака $ в ее имени?
Это не недоработка языка, а элемент его индивидуальности: Р
А какой в этом смысл?
Научить понимать не очень сложно. Гораздо сложнее разобраться с легаси.
К тому же, к этому привыкаешь и это становится удобным. Видишь доллар — сразу мозг на подкорке детектит переменную. На Golang из-за этого я иногда ломался =).
И последнее — неужели это настолько важно? Ребята вкручивают jit, оптимизируют выполнение, добавляют вагон различного жирка — на фоне этого символ перед именем переменной вообще не является проблемой.
Я когда выбирал между PHP и Perl лет 20 назад, то открыл два аналогичных скрипта, в одном увидел $, в другом $,%,@ и выбрал первый )
В ваших цитатах моего текста я противоречия не нашел. И независимо от того, кто из нас дурак, сомневаюсь что мы друг другу что-то докажем.
на мой взгляд это одна из сильных сторон -изолированность возведённая в абсолют. замечу что стоимость этой операции обычно низкая, по сравнению с временем запроса к базе. Я когда запускаю джава или руби продукт и сижу жду пока он загрузится всегда грущу — вот оно сейчас будет жрать гигабайт памяти просто чтобы загрузиться, если там что-нибудь солидно крякнет то упадет все разом, поменять код на лету не просто, а зачем все это — непонятно, когда типичная установка такого продукта имеет минимальную нагрузку, а оставшиеся 0.5% настоящего хайлоада бешенно шардируют по все тем же причинам.
Ну сейчас вроде нужно специально постараться на продакшене, чтобы каждый раз с нуля загружать структуру классов. Кэши опкодов, прелоадинг, JIT вон завезли, даже явную компиляцию в бинарники (файлы с опкодами), для запуска которых не нужны исходники, активно продвигают.
Сейчас можно говорить, что на каждый запрос только переменные очищаются, декларации загружаются один раз технически.
Я сейчас не буду даже про RabbitMQ \ Elk, у меня с PHP ситуация куда проще. Крохотный корпоративный сайт, часто используемый движок. Задача — слегка допилить корзину, чтобы там по почте движение заказа уходило.
Так вот уже четвертый (!) подрядчик подряд пытается решить эту задачу просто впиливанием send.php на submit(), а чтобы заполнить шаблон — они даже ORM не подключают, а просто mysql_connect к базе и селектят оттуда всякое. И это за 35 баксов в час.
Видя такую ситуацию — заказчики начинают избегать языка. Сокращается количество исполнителей, пропасть между «обычными» исполнителями и «квалифицированными» — растёт. Ну вот в итоге и имеем строго то, о чем Вы написали.
А сам язык ни в чем не виноват, да. Трейты там, тайпхинтинг. Мне иногда кажется, что Delphi каким-то похожим образом умирал.
Фриланс он такой — бессмысленный и беспощадный.
Но это справедливо не только для пхп, но для многих других языков и направлений. Например, js (фронт и бек), верстка, диз.
И тем бессмысленнее и беспощаднее чем больше ориентированность на мелкий и средний бизнес (различные мелкие онлайн магазы или сайты визитки на популярных cms и т.п.)
Если исполнитель прямо фрилансер-прифрилансер, ему проще за минимально возможное время сделать то, что гарантированно будет работать.
Ну и, скорее всего, «даже ORM подключать» никто и не просил.
И это за 35 баксов в час.А точно в час?
Может скорее просто за 35 баксов, пусть даже в формулировке «рейт 35 в час, у вас есть только час»
Потому что так-то нет обычно проблем у подрядчика на часовой основе сделать всё по канонам заказчика.
Вот только это будет не «тыгыдык и в продакшен за час», а «3 часа изучения что бы ничего не поломать, 2 часа написания тестов, 2 часа написание кода, 1 час тестирование и 2 часа на документацию» выливающиеся уже в 10 часов ака 350 баксов.
p.s.: И да, 35 баксов в час оплаты это достаточно скромно, т.к. после всех накладных расходов (15-25% бирже, 10% комиссий на вывод, 15% налоги) — от них останется баксов 20 в лучшем случае уходящих работнику, а это оплата даже не джуниора, а «просто с улицы зашел».
Порядка 3200 в месяц, почти 40 000 в год — это «просто с улицы зашел»?! Для меня это где-то на грани между сильным миддлом и новоиспеченным сеньором на фуллтайме в наших широтах. А по ощущениям российские удалённые работодатели столько вообще на PHP не предлагают (в марте-апреле, когда я менял работу). Украинские могут.
Эк вы лихо наумножали.
Никогда не были целиком на фрилансе хотя бы полгодика? )
Порядка 3200 в месяцПерефразируем старый анекдот:)
"Роды у женщин идут в среднем 12 часов, значит за 30 дней женщина родит 60 детей."
А выносить ребенка 9 месяцев, не?:)
Или вот еще классика
фотомодель для эротической съемки. Оплата наличкой на месте. За час работы
— 20 тысяч баксов».
Набежала куча длинноногих, отобрали одну, весь вечер снимали во всех
позах. Приходит новый русский:
— Ну что, фотограф, сколько наснимал?
— Сто двадцать кадров.
— А выдержку ставил какую?
— 1/500 секунды.
— Ну ты, девка, в натуре и на полсекунды не наработала:
При 20 баксах в час и полной занятости в месяц будет в районе 800 у джуна, т.к. 50% времени он будет искать заказы и 25% их обсуждать и сдавать.
Мы нередко берем заказы у москвоских студий (работаем неграми), так вот стандартно они себе берут 50-80% от заказов и нам это всё равно получается выгоднее чем прямой поиск заказчиков, т.к. мы получаем на руки готовое ТЗ и сразу начинаем работать, а не тратим время на всю ерунду.
А по ощущениям российские удалённые работодатели столько вообще на PHP не предлагают (в марте-апреле, когда я менял работу).Предлагают.
Просто в российском сегменте нюанс в том, что соотношение дешевый проект/дорогой проект 95/5, а на западе 50/50. Поэтому когда ищешь в россии заказы — постоянно предлагают копейки и складывается ощущение низких цен, но так собственно и работа по сложности как правило больше не стоит.
А вот на дорогие заказы платят и по 50 евро в час, но там надо не просто знаниями solid потрясать и юнит тесты впаривать, а реально решать задачи… не брезгуя в том числе и методом (говна и палок) описанным в статье, если это вызвано производственной необходимостью. А такой скилл куда большая редкость, чем вот эти все «чистые архитектуры».
Я понимаю разницу между фрилансом и фуллтаймом. Просто последний абзац мой мозг распарсил как:
- на фриланс-бирже — 35 в час
- на руки чистыми — 20 в час
- 20 — это даже не джун
На последней стадии мой парсер сломался, типа 35 — это достаточно скромно, а 20 — это даже нее джун, хотя это одна и та же сумма для меня по тексту, просто грязными и чистыми. Какое-то новое качество появилось, наверное работа фуллтайм…
Третий будет апеллировать к тому что следование SOLID повысит тестируемость. Но гораздо больше повышает тестируемость наличие времени, денег и желания у заказчика видеть тесты на проекте.
Золотые слова.
Слишком много ответственности для заказчика в ответе на вопрос «а надо ли тесты писать?». С чего бы ему вообще этим интересоваться, а мне — это (у заказчика!) спрашивать?
Если длинно — да, не обязательно заказчик должен приходить с такой инициативой, но менеджер может ему это пояснить и заказчик согласиться. И объяснить не конкретно про тесты, а про смысл правильного подхода к разработке — с регулярным подчищением тех.долга, с автоматизацией, с девопс методологией.
Результатом будет гораздо более предсказуемые сроки внедрения новых фич, практически отсутствие зависимости от конкретного специалиста, который «проработал на проекте 3 года и единственный понимает как тут все работает», простой вход в разработку новых людей
А если не объяснять? Заказчику нужны фичи — мы их поставляем, а техническая кухня — наша компетенция, для этого он нас и нанял, нет?
На мой взглядл, среди всех препон, мешающих писать тесты, плохое качество кода находится на последнем месте.
То есть добавление технических задач прозрачно для всех — это удобно.
Слишком много ответственности для заказчика в ответе на вопрос «а надо ли тесты писать?». С чего бы ему вообще этим интересоваться, а мне — это (у заказчика!) спрашивать?Даже написание ТЗ для проекта можно отдать на аутсорс. Компетентным людям/организации. И, по опыту, часто так делают. От заказчика — только деньги. Остальное все сделают за вас. Главная ответственность заказчика (кроме, конечно, оплаты) — правильно выбрать исполнителей.
В Ruby сообществе последнее время еще модно пилить все на микросервисы, переписывать все на монады, сервис-объекты, 12factorapp и т.д. Архитектура ради архитектуры, программирование ради программирования.
Спасибо за
Программирование — это в первую очередь процесс формализации требований, вы же пытаетесь формализовать сам процесс формализации, без всякой оглядки на какие-либо ограничения.
Просто рубисты- это бета-тестеры от мира программирования.
Если что-то не зайдет — откинут, а если что-то очень зайдет — примут на вооружение.
В руби, например, невозможно без классов, и ещё все классы в глобальном пространстве имен, и там просто приходится выкручиваться чем только можно, даже фреймворк над фреймворком есть. В java и c# не знаю, вполне возможно что то же самое, паттерны это вынужденная мера и тот кто не прочитал кучу книг рискует сильно испортить проект.
И как в ноде: самый популярный фреймворк express, роутинг + пара утилит = фреймворк по версии javascript. И абсолютно все, каждую мелочь, решает разработчик: как ему параметры валидировать, как с базой работать, как организовать, и главное — мудрить или не мудрить тоже решает сам.
Да, PHP сообщество токсичное. И это факт. И не важно из-за чего эта токсичность — из-за профдеформации или профнепригодности, но она существует.
И это справедливо не только для рунет сообщества, но и для англоязычной его части.
Кстати в англоязычном сообществе токсичность в разы выше — фанатики и сектанты закидают любого не согласного с религией данной секты. Даже если это объективные граничные условия или исключения из данной догмы. Сектанты они такие — догма должна быть только одна и строго по заповедям, без разночтений и иносказаний, а все остальное ересь!
Рунет сообщество PHP не сильно большое и в нем действительно интересно бывает устроить срач. Но да, надо понимать специфику и неподготовленному морально может быть тяжеловато.
И да, статья тоже токсичная и это тоже факт. Хотя токсичность статьи не исключает что большинство проблем из нее определенно присутствуют.
P.S. И да, я пишу на PHP.
А в чём проблема-то? Или проблемы нет?
Как вы сами сказали, целые компании формируется по стилю исполнения PHP. На любой вкус найдётся. Мне вот ближе "SOLID или смерть, статанлиз наше всё", кому-то "PHP3+WordPress решат любую задачу'"
На любой вкус — это аутсорс в непонятный проект.
Вам шашечки или ехать? )
Либо говнокод, либо говнокод адептов SOLID.
Поддерживаю. Часто именно так. Только в зависимости от команды SOLID можно заменить на любую другую аббревиатуру :)
Ситуация в СНГ-сообществе усугубляется его токсичностью.
И это прекрасно! Токсичность проф-сообществ пост-СССР это прям как первозданный бульон, это как тот самый свободный интернет где можно высказать свою мысль не смотря на все эти штуки с опасностью кого-то обидеть.
Я когда переписываюсь или общаюсь с иностранными коллегами — мне становится жутко не комфортно. Мне некомфортно оттого что я не могу сказать идиоту что он идиот и что ему хорошо-бы сделать трепанацию и в получившиеся отверстие вставить скрученный листочек со стандартами принятыми в компании или прочесть 100-страничный мануал где подробнейшим образом описаны все ньюансы сложной системы.
И нет, я не быдло и я много раз сталкивался с неприятной токсичносью в свою сторону (не только в рунете), особенно когда задавал вопросы на профильных форумах, но я считаю что это необходимая часть жизни разработчика который хочет расти. Это определенный порог вхождения помогающий отстаивать свою точку зрения.
— Ребята, а давайте забьем гвоздь в сервак! Я слышал, что это стильно-модно-молодежно!
— Ты шо, йокнулся?
Новичку устраивают тёмную в профилактических целях.
Запад:
— Ребята, а давайте забьем гвоздь в сервак!
— Этого не стоит делать.
…
— Тщ. менеджер, команда не позволяет мне забить гвоздь в сервак!
— Почему?
— Ну они все отсталые динозавры, а гвоздь в серваке — это стильно-модно-молодежно и ускорит сервак в 100500 раз! Вот статья из СпидИнфо за авторством Гоши Куценко, подтверждающая мои слова. Ну так я забью?
— Забивай!
Команда косится на новичка, но молчит, потому что назвать его идиотом — это токсик и грозит увольнением, а отрицательное влияние внедрения гвоздя в сервер можно будет наглядно показать менеджеру только через полгода и объяснить, что Куценко — не авторитет в подобных вопросах.
Мне видится:
— мне команда не даёт забить гвоздь
— ты молодец и очень умный, забиванием гвоздей занимается отдел забивания гвоздей. если хочешь, мы обсудим твой перевод туда (или вообще отсюда) /эмоджи/
Мне видится:
— мне команда не даёт забить гвоздь
— ты молодец и очень умный, прояви деятельную проактивность, проведи спайк, А/Б тесты, бенчмарки, убеди команду фактами, они тоже не идиоты и факты отрицать не будут.
Ну и я ни в коем случае не утверждаю, что в СНГ все настолько белые и пушистые, что идиотами называют только идиотов и самодуров не существует.
Я просто к тому, что если критика в любом ее проявлении считается токсичной, а повлиять на ситуацию можно только пост-фактум строча доклады непосредственному начальнику, то такая картина выглядит удручающе.
UPD: Ну и вот наглядный пример токсичности в моем понимании — некто поставил минус в карму и минус комментарию (воспользовался административными методами), но при этом даже не потрудился написать с чем именно в моем шарже он не согласен (никакого конструктива).
Мы не будем пользоваться автоформаттерами, потому что Махеш запустил C++-форматтер на питонокоде с флагом --force, отчего питонокод сломался, поэтому форматтеры — это опасно.Ну я тоже такое припоминаю, но есть серебрянная пуля без автоформатирования — не пускать на сервер неправильно отформатированный код.
Сообщество и советских программистов, и фидошников 90-х годов близко не было таким токсичным — скорее узким кружком посвященных братьев.
Это культура последних двадцати лет, выросшая, похоже из тюремной субкультуры с ее строгой иерархичностью.
Черт знает как вы сюда это г. притянули...
Сообщество и советских программистов, и фидошников 90-х годов близко не было таким токсичным — скорее узким кружком посвященных братьев.
Да что вы! У меня тут целый институт математики вспоминает как они прилюдно друг-друга смешивали на конференциях всесоюзных, по приколу. Или как они аспиранта заставляли перечитывать тонну литературы, вместо ответа на вопрос. Или как на защите аспиранта доводили до слез...
Правда теперь про таких аспирантов, уже давно докторов наук и ученых мирового уровня, говорят только в позитивном тоне, а х руководителей, даже сами они, вспоминают как людей воспитывающих характер. Прям типичное "вырос вопреки"...
Нет, я конечно против того чтоб аспиранта доводить до слез прилюдно, но как-то это работает...
и фидошников 90-х
Да потому что модерация нормально велась.
За одно неудачное сообщение могли сразу забанить навсегда. Поэтому все токсики крутились в лучшем случае в TBH, а то и просто в ридонли.
но я считаю что это необходимая часть жизни разработчика который хочет расти.
Одни и те же знания, навыки можно передать человеку и не смешивая его с говном, чтоб он потом если и не боялся, то подсознательно избегал задавания вопросов, демонстрации осознанной некомпетентности…
P.S.
Когда я вижу слово "ньюансы"...
И то чаще всего человеку отвечают — иди учи основы языка, потом учи фреймворк, потом сможешь сделать всё сам.
Если это теперь считается токсичностью — дайте мне другой глобус.
А я встречал… В последнее время больше по вопросам процессов разработки и эксплуатации PHP приложений, типа каждый PHP-разработчик должен уметь разворачивать своё приложение в k8s и/или AWS, а кто не умеет — вон из профессии.
типа каждый PHP-разработчик должен уметь разворачивать своё приложение в k8s и/или AWS, а кто не умеет — вон из профессии
Так как раз насчет этого статья тоже делает акцент. Это и есть один из вариантов архитектурных астронавтов. Очень частое требование применение модных технологий не по назначению.
Потому куча "специалистов" которые умеют развернуть докер (даже там где не надо), но вообще не знают как это все работает. И если такому "профессионалу" сказать настроить то же самое на чистой системе (на собственный выбор) — не сможет. Я не говорю что пхп разработчик должен быть сисадмином, а к тому что если и использует технологии типа докера и k8s, то должен понимать как это работает внутри и когда применять. Это тоже самое что если разработчик использует сторонние библиотеки, то должен понимать как они работают. Например, стандартные жалобы на джунов и мидлов, которые типа умеют только в ORM, но не могут в SQL
Я больше про разделение обязанностей: обоснованно или нет, но решили перевести проект на docker, k8s и/или aws. И теперь разработчик должен писать докерфайлы, манифесты, чарты, конфиги терраформ и т. п. как раз на уровне сисадмина, да ещё отвечать за баланс.
Ну когда есть k8s, то тут явно должен отвечать не просто сисадмин, а модный сейчас девопс.
Я больше против переусложнения когда не надо. Докер для лендинга на вордпрессе и т.п. В таких случаях это доказывает не компетентность принявшего решение использовать это, а обратное.
Если таких лендингов десятки, да с разными версиями PHP, то докер облегчает жизнь, на самом деле
это да, но все зависит от сферы. Если это собственный лендинг на поддержке — да, без проблем (хотя все равно вкусовщина). Но тот же паппет, ансибл или банальный инсталл скрипт может быть лучше докера.
А если это разовый заказ на фрилансе, то тем более в докере нет смысла. И что потом клиенту с этим докером делать?
К тому же повторюсь, я ничего не имею против докера и когда им пользуются специалисты. Но вот например бывает что в публичном докер репе, не только система, но и весь код, со всеми доступами и паролями. Это разве нормально? Это как раз пример, использования технологии заучиванием определенного набора действий без малейшего ее понимания.
Но тот же паппет, ансибл или банальный инсталл скрипт может быть лучше докера.
Ансиблом я ставлю докер ))
А если это разовый заказ на фрилансе
Как раз на фрилансе мне его не хватало, когда сайтов десятки надо держать поднятыми локально да с разными версиями рантайма
Но вот например бывает что в публичном докер репе, не только система, но и весь код, со всеми доступами и паролями. Это разве
нормально?
Это и в гите может быть, и просто на сайте. Большей частью по-моему из-за халатности а не незнания
Здесь именно незнание. Когда все, включая гит репу залито в докер — это явно незнание и непонимание инструмента. Не удивлюсь, что те пароли и в гит репе тоже были. Самое печальное что там были апи ключи для работы с кошельками. Учитывая это паблик репо докера наверное клондайк для любителей податамайнить пароли и доступы.
Токсичность рунет сообщества сильно отличатся от токсичности сообщества англоязычного.
У нас все-таки в разы адекватнее в профессиональном плане и не так распространены секты.
Пост, конечно, очень токсичный вышел, да и зачем хотеть чего-то сильно сложного от инструмента, название которого расшифровывается Personal Home Page? Для сложных задач есть другие инструменты.
Но в одном вы правы: у СНГ-шного сообщества карма испорчена, отягощена такой поделкой, как Битрикс. Думаю, не ошибусь, если скажу, что у очень большой части малого бизнеса сайты на нём, родимом. А это значит, что всегда будут люди, готовые задешево возиться с этой лапшой, где вместо KISS, DRY и SOLID используются принципы "сдал и забыл" и "ну так — и в подакшен". Жить-то хочется, порог вхождения низкий..
И сообщество хочешь-не хочешь будет в большой степени состоять из тех, кто увяз в этом тухляке и никогда даже про Laravel не слышал — или наоборот, наворачивает Svelte вокруг Битрикса.
Но зачем их пинать? Пишите на Go или на Kotlin, зачем переживать за фронтенд — у нормального программиста столько разных путей и возможностей развития, что на две жизни хватит.
Ну а разве Laravel это что-то неописуемо прекрасное?
Странный продукт. При желании можно писать по SOLID, даже псалм к илокенту люди прикручивают полноценно, если верить. Но в реальной жизни не встречал такого.
Вот именно. Самое главное здесь — в реальной жизни. Как то в пхпклубе устроил срач насчет того покажите хоть один готовый проект, а не либу сделанные по фен-шую. И тут сразу закрытые исходники, NDA и т.п. Даже НИ ОДНОГО качественного опенсорс проекта никто не смог назвать. По факту абсолютно везде срезание углов и компромиссы из разряда жесточайший говнокод.
Так что проблема действительно есть. Очень много действительно профессиональных программистов очень сильно оторваны от реальности. А новичкам и говнокодерам некогда учиться — им рубить надо. В результате имеем, то что имеем в данный момент — или говнокод или астронавты архитектуры. Исключения есть, но часто они только подтверждают правило.
https://github.com/oroinc/crm — не чистый феншуй, но гораздо лучше большинства "закрытые исходники, NDA и т.п."
(deleted)
Высокая нетерпимость к чужому мнению вкупе со схемой «я начальник — ты дурак» порождает целые компании, где люди отбираются строго по религиозному признаку.
По большому счету, нельзя сказать что такой метод подбора сотрудников является неправильным. Если человек исповедует явно другую религию чем в компании — то зачем такого брать и потом бодаться с ним?
В компании, или в проекте, принята какая-то методика. Если каждый из программистов принесет свою методику и каждый будут пилить в своем стиле — получится зоопарк. Если все пилят в одном стиле — то тут хотя бы разнообразие в этом зоопарке будет меньше, и для того что бы разобраться в проекте не придется осваивать стили каждого из программистов.
Нет единственно верного пути, у каждого какие-то недостатки. Если компании/проекте выбрали какой-то конкретный путь — его нужно придерживаться, даже если у вас есть особое мнение. Станете руководителем проекта — будете продвигать свое видение.
Вы так говорите, как будто это что-то плохое.
Моя практика показывает, что команды индивидуалистов, разделяющих общую точку зрения, заметно эффективнее команд тех же индивидуалистов, согласившихся с чьей-то точкой зрения. Буквально тех же: приходит CTO новый и вводит, например, такую мелочь как новые код-стайлы. Старые были приняты всей командой в процессе обсуждения, а тут директивно. Эффективность упала, хотя казалось бы...
Вы думаете что в мире есть места где все сделано и работает правильно. А под правильно вы видите какой-то конкретный вариант. Это не так. Мозг человека работает иначе. И обычно нет единственно правильного пути.
Подбор персонала — весьма субъективная штука, вероятно этот ваш оппонент уже обжигался при подборе, ему попадался любитель Symfony который постоянно тянул одеяло в сторону Symfony которым в проекте и не пахло, и всех этим задолбал.
Теперь они ищут чела без таких недостатков :)
После слов про то, что сложности в проектах на язык-нейм нету в сухом остатке, сей опус я покинул.
Это скорее связано с несколькими факторами: клиповое мышление, большой объем накопленных в отрасли знании, повышение порога входа, синдромом самозванца и желание скрыть свою неуверенность (а в некоторых случаях и некомпетентность).
Эту тенденцию можно было наблюдать на примере Японии в начале этого века.
Привыкайте. Это новый мир. Дальше будет хуже. Надо научиться с этим жить.
Где же это токсичное PHP-сообщество, покритикуйте меня :))
Видимо тут в красках представили фразу «в стиле PHP4» :) Не востребованным у меня вряд-ли получится стать, я конечно не обладаю опытом работы в ряде модных фреймворков (их можно освоить, в конце-концов при особой необходимости), но опыт работы с PHP, C#, SQL, адаптивная верстка, JS и т.п. все же имеется.
Дело в том, что я несколько лет немного другим занимался делом и вернулся в веб-программирование в этом году и осознаю, что несколько отстал от трендов, хотя работа при этом находится без проблем, точнее, она сама меня находит. Но нужно бы развиваться, поэтому и написал здесь, чтобы немного подстегнуть себя.
по большей части в рунете есть только пхпклуб и все. Но думаю там будет не очень интересно. Т.к. там обычно срачи как раз насчет всяких архитектур и паттернов. И это именно срачи, между теми кто разбирается. Но с другой стороны они дают понимание насколько различно понимание каждой терминологии у различных программистов.
P.S. Да, Wordpress и Drupal объективно гуано. Но это не отменяет громадных плюсов Wordpress в плане пользовательского опыта
А я начинал ещё с PHP3 и переходил к PHP4...
Статья настолько прекрасна, что перечитал пару раз. Спасибо автору – вспомнил 20+ лет в PHP, как это всё было и к чему привело.
И почему я пришёл к Node.js ;)
Есть отличные коммьюнити, где тусуются пара сотен (не более тысячи) людей, где каждый знает своего и у них уже не коммьюнити из всяк входящих, а своё, которое они построили. Это чаще всего чаты, группы, где модерируется по внутренним правилам.
Да, есть проблема, что язык позволяет делать всё, даже BDSM, и это — одна из причин «всяк входящих», такое же положение и не только в мире PHP.
Проблема в самих людях — PHP позволяет делать всё, от чего они (люди) не смотрят налево и направо.
1) Появился PHP, появилось много разных компаний.
2) Лет через 10 выжившие построили крупные системы на ПХП и столкнулись с тем, что все стало сложно и неповоротливо. Надо что-то делать, иначе будет конец.
3) Одни компании стали переводить свои системы на Java, другие начали пилить костыли (Fb/Vk/Badoo и так далее). А вот последние нанимают лучших разработчиков на ПХП, которые видят проблему и говорят: «А давайте её решим также, как это решили ребята с java/net).
4) Так как лучшие разработчики на PHP имеют вес, опыт и имя в айти-сообществе, они начинают толкать разработку php в сторону Java-like языка. Добавляем сюда финансирование на выступления, доклады, книги и прочее.
5) Как итог, чтобы решить корпоративные проблемы больших компаний на PHP, разработчики тянут php к интерпрайз стандартам.
Естественно, ребята, которые пишут небольшие проекты на CMS и прочих системах начинают говорить, „А зачем это?“, „А зачем так сложно?, “А зачем копировать Java». Но так как деньги и возможности стоят за корпоративными программистами, их игнорят и правильно делают.
Вон обратите внимание на всех говорящих голов по PHP от ру-комьюнити, явно не сайтики на CMS делают.
Каким образом наличие опытных программистов, следующих сложным принципам на сложных проектах, мешает новичкам решать свои задачи просто на простых? У PHP замечательная обратная совместимость, можно при желании по старым книжкам писать, если проект позволяет. А вот отсутствие новых фич и интересного в плане структуры кода, понятного и близкого переходящим из других технологий, ведет к неприятию и тому самому мнению, что PHP не умеет то, что могут современные языки, и негде применить свои скиллы, некуда расти.
Автор с забавным апломбом выдаёт свои комплексы за проблемы миллионов. Редкая статья, в которой не согласен с каждым первым утверждением.
В разработке с 2001 года, поработал админом, фрилансером, в проектных организациях и продуктовых командах. Код писал на двух-трёх десятках языков, если считать всякую экзотику и эксперименты. За деньги: PHP, SQL, JS, Ruby, Groovy…
Всем прочим предпочитаю Symfony, но и Битрикс изучал, и на Drupal сайты делал. Всему своё время.
С большим удовольствием и гордостью отношу себя к PHP-сообществу. Как к русскоязычного, так и к международному. И стараюсь посильно вкладываться в его развитие.
PHP коммьюнити в СНГ. Было плохо — стало хуже