EVGA ввела систему онлайн-очередей для покупки RTX 3080

Согласен, какое-то нездоровое поведение. То же самое происходит у них с билетами — перекупы скупают сотни билетов и перепродают втридорога.
Самое забавное, что у рынка давно есть ответ на такое поведение — аукцион. Если пользователь готов заплатить 1500$ вместо $700 за возможность получить карту первым — дай ему эту возможность. Все эти очереди за новым iPhone, кроссовками или приставками это какая-то дикость.
Думаю, что все дело в пиаре. Видимо суммарный выхлоп от дефицита выше, чем от возможности продать первую партию в двое дороже.

Распределенные Workflow на PHP. Часть 2

Спасибо за ответ, но что такое yield я знаю. Чего я не понимаю - почему в коде результат yield присваивается переменной.

<?php

function gen()
{
    $date = yield new \DateTime();
    var_dump($date); // NULL yield не возращает значение
}

foreach(gen() as $date) {
}

Распределенные Workflow на PHP. Часть 2

Очень интересно. Но ничего не понятно.

Вопрос, который меня беспокоит больше всего - каким образом yield возвращает значение?
Это стандартное поведение в php или это добавляет кто-то из RoadRunner, ReactPHP и Workflow PHP SDK?

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

1. код в результате выглядит так, словно он написан на каком-то совершенно новом языке. Экономии на изучении нового языка не так много

2. Большую часть библиотек, написанных не для конкретного решения (swoolee или ReactPHP) переиспользовать нельзя - они будут либо течь, либо блокировать io, либо сохранять стейт между запросами.

3. Язык не заточен для этих задач и не обладает встроенным инструментарием для облегчения разработки таких решений. Например - сможет ли хоть один статический анализатор для php проверить корректность вызова:
   $saga->addCompensation(fn() => yield $booking->cancelHotel());
   Какой тут тип у параметра метода addCompensation()? Просто callable? Есть ли правило для phpstan которое проверит, что замыкание является генератором?
   

Ошибки, которые не ловит Rust

Про js не к месту в начале только для легитимности сравнения добавил.

Вначале идет речь о асинхронном программировании. Поэтому js обсуждается на равне со golang и Rust. Далее автор переходит к обсуждению многопоточности и связанных с ней проблем, упоминая, что для js это не актуально - потоки там есть, но для таких задач их не используют. Поэтому далее js не рассматривается. Очень лаконичное повествование, всё к месту.

То что тип нуля int, а не выводится - плохо, но чую был бы это rust - это было бы очередное явное лучше неявного.

Тут речь не о неявном преобразовании типов, а о том, что Rust может угадать тип переменной не только в момент ее присваивания, но и по тому, как она далее будет использоваться.

fn print_int(i: i32) {
    println!("Hello, int {}!", i);
}

fn print_uint(u: u32) {
    println!("Hello, uint {}!", u);
}

fn main() {
    let i = 42;
    let u = 42;
    print_int(i);
    print_uint(u);
    //print_int(u); // error
}

"если обезьяне дать две бомбы, какая взорвется быстрее?"

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

Самый неадекватный кандидат за мою карьеру

На прошлой неделе у меня был опыт с HR, после которого я тоже хотел написать много гневных постов. Но мне лень, поэтому расскажу здесь.
HR до собеседования на вакансию full stack senior разработчика предложила мне выполнить неоплачиваемое восьмичасовое тестовое задание. Перечитывая это предложение, я сам не знаю как я мог согласиться.
Само задание было сформулировано не менее интересно — реализовать веб-приложение без использования фреймворков. В задании утверждалось, что оно нацелено на выявление способности организовать взаимодействие между различными компонентами. Очень подробно были описаны требования к коду и даже дважды ссылка на книгу «Совершенный Код». Мне показалось это даже логичным. И целое воскресенье я провел по большей части за изучением api библиотек, которые я в жизни не использовал, т.к. зачем если все эти функции берет на себя фреймворк?
Через три дня после того, как я отправил ссылку на решение, HR ответил мне, что в моей реализации, при сохранении формы нет сообщения «Данные сохранены», поэтому он не может передать мое решение техническому отделу.
В этот момент я завуалированно поинтересовался, не много ли русского национального блюда из рыбы они ели в последнее время? Давать восьмичасовое неоплачиваемое тестовое задание и отказывать на основе одной ошибке не только в собеседовании, но даже в передаче кода на ревью тех-команде?
Хочу отдать должное HR, он согласился со мной, что пожалуй да, многовато, и предложил таки передать задание далее. Но мне уже совсем не хотелось иметь с ними никаких дел.
Раз уж здесь разговор о неадекватных кандидатах — хочу поинтересоваться мнением других — не был ли я одним из них?

Объясните, почему мой рокет-саенс бэкенд билдится пару секунд, а четыре формы на фронте — полгода

Если одновременно нет кеша между сборками и хот релоада, то это уже не архитектура, а Г. и автор правильно негодует.

Объясните, почему мой рокет-саенс бэкенд билдится пару секунд, а четыре формы на фронте — полгода

Я достаточно поверхностно знаком с фронтенд инструментам сборки, но первое, на что я обратил внимание при знакомстве с ними — они полагаются на hot reload и полностью игнорируют файловый кеш между сборками. И именно из-за этого у бекендеров возникает больше всего негодования — «я только что собрал проект, потом изменил одну строчку и теперь он опять полностью пересобирается. WTF?». А ответ прост — ты два раза запускаешь сборку новой командой, вместо того чтобы использовать hot reload. Обычно кеш можно добавить отдельными модулями, но они редко используются.
Может это и неплохой подход — зачем лишний раз писать кеш на диск, если есть память постоянно запущенного процесса. Но это раздражает, когда нужно быстро переключится на проект и исправить одну строчку. Каждый раз ощущение, что люди писавшие это никогда в глаза не видели нормальных компиляторов. Но видимо это такая вот архитектура.
Поправьте, если я не прав.

Разбор худшего в мире куска кода

У меня два варианта почему так:
1. SQL интерфейс поддерживает WHERE, но требует соответствующих интерфейсов от хранилища, на которое мапится конкретная таблица. Т.к. users очень маленькое хранилище, разработчик решил пока не тратить время и не добавлять поддержку WHERE.
2. WHERE для users реализован, вот только поля password и username «магические». Их динамически формирует соответсвующий класс JS и выборку по ним в рамках запроса делать нельзя

Разбор худшего в мире куска кода

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

Начнем с функции authenticateUser:

  var accounts = apiService.sql(
    "SELECT * FROM users"
  );

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

if (account.username === username &&
        account.password === password)
    {

Все мы, как и автор кода, знаем, что пароли в открытом виде хранить небезопасно. Значит account.password это хеш. А значит переменная password то же содержит хеш. Значит у поля ввода $("#password") переопределен метод val() и возвращает сразу хеш пароля. Интересное решение. Возможно, даже сам JS не имеет доступа к паролю в открытом виде. Точно не через стандартное API. Дополнительная защита, чтобы не выстрелить самому себе в ногу.

  if ("true" === "true") {
    return false;
  }

Исходя из того, что я вижу, я могу сделать вывод о том, что она принимает два аргумента типа string и возвращает единственное значение типа boolean.

На самом деле эта функция возвращает либо boolean, либо undefined.
Как мы увидим далее — код обрабатывает поведение для true (ставит куку), false (выводит сообщение об ошибке) и игнорирует undefined.

  if (authenticated === true) {
    $.cookie('loggedin', 'yes', { expires: 1 });
  } else if (authenticated === false) {
    $("error_message").show(LogInFailed);
  }

То есть это не случайно. Это спроектированная особенность. В каких случаях строка «true» может быть не равна такой же строке? Первое что приходит на ум — это какая-то проверка окружения. Похожие куски странного на первый взгляд кода встречались раньше для определения отдельных браузеров. Но в этом случае логично было бы вынести эту проверку в отдельный метод с соответствующим названием.
Обрабатывается редкая и специфическая ситуация при которой не нужно выводить сообщение об ошибке.
Пожалуй первый серьезный минус кода — отсутствие комментария.

$.cookie('loggedin', 'yes', { expires: 1 });

При успешной проверке пароля мы ставим куку. Что же делает эта кука и весь этот код?
Он берет пароль и логин, и сравнивает их со всеми сохраненными локальными учетными записями. После этого ставит куку на один день. При этом не сохраняет информацию о том, под какой именно учетной записью.
Это выглядит как разблокировка локального хранилища. Но очень простая. Ее можно обойти самостоятельно поставив куку в браузере через консоль. Но это может сделать только тот, кто уже имеет доступ к браузеру с сохраненными куками пользователя. К тому же для этого нужно знать что делаешь. И должен быть доступ к консоли. И консоль.
Значит это не обычный компьютер и не обычный браузер. Возможно это какой-то терминал.
Все равно не очень безопасно, но, возможно, таким было требование бизнеса. Захотелось простую защиту от дурака — кнопку «заблокировать экран» с повторным вводом пароля, но сохранением сессий и автоматической блокировкой через сутки.

PHP 8: код «До» и «После» (сравнение с PHP 7.4)

Rust уже пробовал. Rust прекрасен. Язык который сам проверяет больше случаев, чем многие статические анализаторы. Это закономерное и логичное развитие ЯП.
Только вот работы на нем нет. Для меня.

PHP 8: код «До» и «После» (сравнение с PHP 7.4)

Сначала мы не хотим возится с этими типами, потом мы вдруг понимаем, что нам нужна типизация, а уже потом мы в нее не влезаем.
То, что происходит с php меня очень забавляет.
Сам я устал от php. Писал на нем лет восемь и стоило один раз попробовать c++ — и боже мой! Это так прекрасно!
А сейчас php пытается в строгость. Но какой от нее толк, если все эти проверки происходят в момент выполнения кода? Да, конечно, у вас всех умная IDE, которая всё подсвечивает (а чаще не всё), и прикрученный статический анализатор. Но это костыли.

Вырезаем SSR и ускоряем Хабр в 10 раз

Есть. Но работает медленно. Чтобы удалить неиспользуемый css нужен готовый html. И при каждом изменении html нужно заново формировать css.