Военные США планируют провести реальный воздушный бой человека против ИИ уже в 2024 году

GPS тоже не сразу гражданским дали

Ой, промазал с ответом товарищу staticmain

Китайцы добывают полезные ископаемые на удалёнке, управляя техникой по интернету

Аватар Кэмерона напомнило.

UPD для пикабушников: Это Farming Simulator с включенным RTX

В Госдуму внесен законопроект, который ограничивает комиссию магазинов приложений и разрешает установку стороннего ПО

2020 как же ты утомил

Проект длиной в 8 лет — знал бы, ни за что не ввязался: свой 2-тактный мотор

Как минимум про «ростовских почанов», как мне кажется, вы предвзяты.

Проект длиной в 8 лет — знал бы, ни за что не ввязался: свой 2-тактный мотор

Тогда уж с Чернегой, хотя у них совсем не про это, или Негодой, который хоть и про двигатели, но не про те :)

Уязвимости PHP-фреймворков

Потому что 7.1 и старше уже официально не поддерживаются, при этом 7.2 хоть и получает патчи безопасности, но в ноябре и она тоже прекратит поддерживаться.

https://www.php.net/supported-versions.php

По этому, можно было бы сказать о том, что «проект дорого переводить на 7+», но в комментариях о проблемах безопасности лучше уточнять, как мне кажется, что если и переезжать, то на актуальные версии. Это то что касается самого языка.

А по поводу эникейщиков это да. Фрэймворк может быть и без уязвимостей. Но это никак не защитит от эникейщика который может целенаправленно, по не знанию, включать что-то что станет той самой дырой, через которую и получится нанести какой либо ущерб.

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

Уязвимости PHP-фреймворков

Наверное речь об этом: <script language="php">, на очень древних проектах, которые дешевле просто «похоронить как есть», чем как-то переностить на 7.2+ версии

Уязвимости PHP-фреймворков

Нигде, эти «секреты» должны передаваться через переменные окружения, а потом конфиг должен быть закеширован в виде огромного массива со статическими значениями https://laravel.com/docs/7.x/configuration#configuration-caching

Насколько помню файлик будет лежать в bootstrap/cache

Мне не нравится то, во что превращается PHP

Мда… Я в более спокойной обстановке прочел и RFC, и код потыкал, сравнивая существующие варианты с новыми. Плюс до меня немного дольше доходило «Потому что в аргументах не дефолтные значения свойств, а дефолтные значения аргументов.» в комментарии Альберта

Пардон, я был не прав, но я разобрался, по этому спасибо вам!

Мне не нравится то, во что превращается PHP

А ssh только на прод бывает, или вы тоже ЧСВ поднимаете?

Системой контроля версий пользуемся, и CI, и CD.

Мне не нравится то, во что превращается PHP

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

Например, IDE может не оказаться под рукой, ушел по SSH на сервер чтобы на горячую произвести изменения «здесь и сейчас» и там у вас vim, или nano.

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

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

Мне не нравится то, во что превращается PHP

Ну не, если «фонит» — значит надо чинить. Уже наловился таки сюрпризов при смене окружения во время переезда с непонятных серверов, на что-то более подконтрольное.

Мне не нравится то, во что превращается PHP

C99, а там как пойдет. Главное же начать.

Но уже имею некоторые плоды. Был удивлен тому что:

if (1) {
    char[] variable = "value";
}

printf("%s", variable);

этот код не скомпилируется. После PHP это была очень сочная оплевуха черенком грабель :)

Мне не нравится то, во что превращается PHP

Да. Вопрос из разряда «на внимательность», но эти знания могут и в практике эти знания могут пригодиться.

Мне не нравится то, во что превращается PHP

Коллега пытался сделать акцент на то, что «дешугаринг» должен нас спасти, но не спас.

Мне не нравится то, во что превращается PHP

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

С вашего позволения отвечу тут и на соседний комментарий.

Разница в том, что в обычных анонимках мы контролируем процесс передачи контекста в область видимости используя `use`, а в случае стрелки нас этого контроля лишили, прокинув в тело стрелки вообще всё. В каких-то моментах это может быть проблемой. И, повторюсь, одна инструкция на стрелку.

Мне не нравится то, во что превращается PHP

Если я правильно понял фразу «Не сломается если свойства родительского класса с дефолтными значениями.» то должно быть так:

<?php

class A {
    public function __construct(
        public int $a = 1
    ) {}
}

class B extends A {
    public function __construct(
        public string $b = 'hello'
    ) {}
}

$b = new B();
var_dump($b->a, $b->b);

Но вот результат получается вовсе не тот о котором вы пишите:

Fatal error: Uncaught Error: Typed property A::$a must not be accessed before initialization in /in/kd90M:16
Stack trace:
#0 {main}
thrown in /in/kd90M on line 16

Process exited with code 255.

Код в песочнице: 3v4l.org/kd90M

Не исключаю что авторы в первых бетах реализовали что-то не так. Посмотрим как оно будет дальше. Но пока имеем, что есть.

Мне не нравится то, во что превращается PHP

почитайте про альтернативный синтаксис управляющих конструкций

Мне не нравится то, во что превращается PHP

Стрелочные функции отличаются от обычных анонимок:

<?php

$var = 'val';

$fn = fn () => $var; // Переменная доступна без дополнительных действий

echo $fn(); // var

в то время как

<?php

$var = 'val';

$fn = function () {
    return $var; // Переменная не будет доступна, ошибка компиляции. Но если ее прокинуть через use - мы получим тоже что и в стрелочной версии
}

echo $fn();

Это не говоря о том что стрелочные функции не могут содержать в себе более одной инструкции.

У меня опыта значительно меньше, но, как мне кажется, разница значительная.

Мне не нравится то, во что превращается PHP

Ошибка компиляции будет, потому как при таком синтаксисе должно быть 'elseif'. Если бы это был простой, без скобочный, синтаксис, то было бы 'three'.