Pull to refresh

Comments 73

UFO just landed and posted this here

Забавно, но если подумать, то это почти с чем угодно так работает.

Вот я из вторых. Не то чтобы я его хоронил, но за последние несколько лет не видел чтобы его использовали, хотя и работал в нескольких компаниях

А что там было вместо?

Да чего только не было) и джава и шарп и (вот сейчас) нода.

Сайты на джаве и шарпе?
Зачем?

UFO just landed and posted this here

Почему о фронтендерах все говорят, а о бэкендерах нет?

Так вот, смысл в том, что бэкенд-разработчиков ровно настолько же много

Кажется что их не на столько же много. По опыту почти 80% трудоёмкости разработки это пользовательский интерфейс. В результате чтобы "рисовать" все эти красивые кнопочки и формочки просто нужно больше рук. Да и видит пользователь в основном то что нарисовано на фронте. А то что где-то есть бэкенд многие не догадываются.

Это да, но поэтому и вопросы возникают — а что за бэкенд, а где, а как. Ну и работа-то от этого менее важной не становится, кажется.

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

И в догонку автору:
Laravel, Yii 2

Вы серьёзно? Yii2 упомянули, а Symfony даже не в списке?

ну использовать чистый Symfony это почти как чистый PHP. Symfony много в какие фреймворки утащили

ну использовать чистый Symfony это почти как чистый PHP

Что? Даже лет 5-7 назад это был универсальный комбайн, покрывающий всё на свете. А уж Symfony в виде зависимости к другому фреймворку я вообще ни разу не видел.

Тот же хайповый Laravel имеет под капотом многие пакеты Симфы.

Ну, вы не путайте Symfony как фреймворк и Symfony Components, которые можно юзать по отдельности где угодно.

не просто упомянули, а ссылку поставили на свой курс по нему :)

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

Это мои наблюдения как фулстека. Просто на фронте необходимо реализовать взаимодействие между человеком и программой, а человек в этой паре жутко "непредсказуемый". И под него бывает сложно подстроится, а на бэке этого человека нет, интерфейсы взаимодействия сервисов между собой гораздо проще.

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

Все стесняюсь спросить, про вот эти айтишные зарплаты.
Это вместе с премиальными или только белая зарплата, к которой идут еще и премиальные?

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

ПС: у меня, например,премий нет, только часовая ставка. Но на оливки к гречке пока хватает.

У вас минимальный код на PHP неправильный. Минимальный будет:

<?= 'Hello, world!';

Ого, теперь можно не закрывать справа?

Более того, нужно не закрывать - согласно стандарту psr-12

Можно, но если и дальше будет идти php код и не планируется вставка например html, как-то так.

Не теперь, а всегда так было..

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

<?= не является шорт тэгом

Ну да, блин, вот вам исключение) Спасибо, не знал.

short_open_tag       bool     

Замечание:

Эта директива не влияет на сокращение <?=, которое всегда доступно.

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

Это не шорт тег. Вот шорт тег:
<? echo 'hello, world!'; ?>
и именно это отключено на серверах по умолчанию, а не <?=

Накинулись, как коршуны) Я понял, это сокращение.

Их уже нет вроде бы, или только задепрекейтили. Это если говорить именно про шорт-теги.

Упс, в php 8 такое не работает. Шорты убрали

Почему все варианты языки, но для c# указан фреймворк, а не язык?

А node.js когда стал языком))

Лично для меня умер. Мне он больше не нужен.
Перешел на nodeJS - и фронт, и тыл на одном языке ;)

Поделитесь ощущениями от такого рода фулстек-работы?)

UFO just landed and posted this here

оттуда и пишу, по пятницам нас на хабр пускают.

UFO just landed and posted this here

Прости меня, Пыхо-Бог! Не ведал я, что творил. Подбросил мне в наказание 3 часа половых утех с Gateway Intents. А ошибку кидал, что порт занят, я аж все пакеты пообновлял, потом вообще ноду с нпм обновил.
Пока волшебные слова {intents: [Intents.FLAGS.GUILDS, Intents.FLAGS.GUILD_MESSAGES]} не написал, даже соединяться не хотел...

Лучший способ отдохнуть — сменить на время род деятельности.
Когда я заканчиваю задачу по беку на пхп, с удовольствием беру задачу по фронту. К ее концу, (когда ненависть к JS чаще всего уже зашкаливает), снова возвращаюсь к беку и так по кругу.

Как разработчик на пхп - не рекомендую связываться, особенно после выхода 8.0, а затем и 8.1

Как разработчик пхп разработчику пхп, можете аргументировать?

Миграция приложения 7.4 на 8.1, где теперь кидаются депрекетйами на нулы. Это не типизированый язык для модников, а какая-то странная хрень, которую теперь надо раздувать проверками на null, перед тем как вызывать что-то из встроенных функций.

Этого я вообще не понял. Раньше в пхп null был допустимым значением, а теперь использовать его неправильно, мы ругаемся. Что дальше? В 8.2 будем фаталить приложение из-за того, что кто-то на другом конце положил в базу NULL вместо ''?

Доверия языку нет. Как писать на нём сложные приложения, зная о том, что в следующем релизе может прийти фича, которая просто не позволит коду запуститься, требующая больших ресурсов на адаптацию. Обратную совместимость начали подламывать где-то в 7.2 на 7.3 с countable.

Я мигрировал приложения с 5.6 вплоть до 8.0 от малых до крупных.

Изменения в коде для совместимости у меня занимали не более полу-дня.

Возможно изначально в коде использовались сомнительные решения? На которые потом изменения в пхп начинали ругаться.

Возможно у нас разные представления о большом проекте. В моем случае это 6Мб исходного кода.

Небольшие и средние приложения, особенно если с зависимостями композера, это просто - обновил библиотеки, подкрутил их использование и всё, такое да, совсем ничего не стоит обновиться.

9мб и пара по полтора, ощущения как у Djeux. С композером как раз основные задержки - всякие немейнстримные библиотеки обновляются довольно медленно, даже если им пулл реквесты слать

Старым пхпшникам не привыкать. Я помню, как долго и болезненно избавлялись от register_globals.

Миграции в PHP вполне мягкие, если код изначально написан нормально, использует фреймворк и композер, то процесс хорошо задокументирован и даже мега крупные проекты можно мигрировать за один день 1 человеку.

Если хотите боли, посмотрите на питон, как все сломали между 2 и 3. Даже если код идеальный, его неслабо так надо было переписывать чуть ли не заново. До сих пор, в куче компаний есть легаси на python 2, ибо трогать себе дороже.

Ни разу на работах не встречал ПХП, только Java/C#/Python на бэкенде. Но это скорее всего обусловлено спецификой - в энтерпрайзе ПХП непопулярен. Только в одном проекте из тех, в разработке которых я учавствовал, случайному человеку можно было попасть дальше страницы авторизации. И то там в основном справочная информация/статистика/форма обратной связи.

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

А в других языка "функций" нет? :)

Ассоциативные массивы только на первых порах кажутся удобными, в большом и сложном проекте это в ад может привратиться.

А чем плохи ассоциативные массивы в больших проектах?

Можете примеры привести?

ассоциативные массивы это замечательно, а на 8.1 с jit местами даже быстрее SplFixedArray и, внезапно, ds (ну или у меня специфика приложения такая попалась).

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

в случае с объектом класса у вас есть гарантия, что объет обладает некоторыми свойствами и т.д.

в случае, если на этом месте массив, у вас есть только честное слово и надежда.

А порой еще и не понимание, что в нем вообще за поля.

Ассоциативные массивы в php, сильно удобнее, чем в c# - именно удобнее, а не сложнее. Ими проще управлять и вообще делать, что угодно. В с# это тоже все не сложно делается, но писанины больше.

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

А можно уметь и все равно проблем с ними огребать. Я даже про чей-нибудь легаси не говорю, в новых проектах намудрят с этими массивами такого что хоть стой, хоть падай. Вот буквально сегодня была статья где гражданин использовал массивы в качестве DTO и еще с описанием полей через phpdoc. Суют их везде, и куда надо и куда не надо.

А в php, простите, завезли уже поддержку UTF8 нативную?

Да, вроде, под капотом все строковые функции это то что раньше было mb_*

Шикарно! И как я только пропустил эту версию? )

А если серьезно, просто другой подход работы с utf8 и вопрос вкуса и привычки какой удобнее - вводить разные типы строк для utf8 и bytes, или же все строки это bytes + разный набор функций.

Может я чего-то не понимаю, но почему никто не говорит о том, что фреймворки для использования на Node.js, не только модные, их содержание очень дорого обходится (если не забивать не SEO). Простые сайты и блоги могут спокойно функционировать на простом хостинге, а "модные" фреймворки почти бесполезны без SSR. Думаю PHP будет жить, пока Node.js не будет на большинстве российских хостинг-платформ и по более доступной цене.

Ребят, куда умирает? На HH 7000+ вакансий на PHP! Я когда начинал карьеру было едва тысяча.

Пишу на PHP с 2010го, до этого, будучи школьником изучал PHP и он уже тогда умирал. Что в итоге? С каждым годом язык все лучше и лучше. Просто посмотрите на PHP и окружение 10 лет назад и сейчас. PHP (как и Java с .Net Core) занял свою нишу и пока никто ее не подвинет.

В 10х быструю смерть предрекали PHP из-за RoR, что из этого вышло, я думаю все знают.

Те, кто говорит, что "ну нет строгой типизации же", включите строгий режим и все. С 7.4 вполне можно все в режиме строгой типизации писать.

Кто говорит, что нет асинхронщины... Не знаю, я ещё в 16м году писал асинхронный код.

Те, кто говорит, что там с UTF8... Ладно, это вообще смешно. Куча библиотек для работы со строками, в которых mb_ функции хорошо завернуты.

Казалось бы, в 2022м году с выходом 8.1 все точки над i должны быть расставлены, но нет. Те, кто любит этот язык, читает про "очередное умирание" с лёгкой улыбкой.

Сейчас как фронт, так и бек устаканились, есть проверенные инструменты, используя которые, вы гарантированно решите бизнес задачи. И это радует.

Это утверждение о "смерти" может быть справедливо разве что для каких-то отдельных регионов в мире. С RoR в пределах РФ не часто сталкивался, в отличии от PHP. А вот на проектах далеко за пределами РФ напротив RoR попадался чаще и появляются такие диковинки, как проекты на Elixir, которых в российской среде ни разу не видел вживую.

Читал статью и ловил себя на мысли "для кого она?". Потом поперзнулся на списке фреймворков и начал задаваться вопросом "из какого года автор её вытащил?". А в конце не мог избавится от ощущения "зачем все это?". Объяснение роли бжкенда для новичков? Ну такое, шутка с письмом не зашла. Сравнение языков с их областями, плюсами и минусами? Ну нет тут сравнения, тут обрывки какие то в пару фраз приправленные хэлло-ворлдом зачем то. Анализ "где денег больше"? Да и так все в курсе что не от технологии зависит а от уровня и страны. Да и выбирать стэк только по деньгам это дорога на дно. Юмор? Так нет тут его, несмотря на попытки. Может как и написано в заголовке, анализ жива ли пыха, не устарела ли морально и функционально, успевает за аналогами в своей области, не вы родились ли ещё программисты на ней? А вот фик вам, другие темы отвлекли автора от этого вопроса, ограничился как обычно "много сайтов на ней ещё". Поэтому самый главный вопрос: а что собственно хотел сказать автор? На кроме рекламы академии, с этим понятно.

// PHP <?php echo 'Hello, world'; ?>

Не пишу на РНР уже лет 10 (не потому что перешел, просто это не мой основной ЯП). Но читаю статьи. Так вот, мне кажется (судя по этим статьям) , что hello world на РНР выглядит теперь как-то так:

<?php
require 'vendor/autoload.php';
use \Hello\World;
use \Start\programming\php;

interface IhelloWorld {
//100500 строк поскипано для краткости
}
class myHelloWorld implements IhelloWorld
{
//поскипано
$hello = new myHelloWorld(trait и прочий синтаксический сахар)
$hello->print_hello_world(DEFAULT_STR...);

есть ли еще РНР без фреймворков и ООП? Или всё, JAVA номер 2 ?

Sign up to leave a comment.