Обновить
19

Пользователь

10
Подписчики
Отправить сообщение

Дополню по Zitadel: имперсонализации нет, а значит и GDPR комплаенса, события и логи копятся безразмерно, OTP только вторым шагом, из passwordless только passkey. И это только по краю причин, почему его не стоит брать.

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

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

Verdaccio — это огрызок в сравнении с Nexus, но есть нюансы:
1. В Nexus OSS нельзя получить токен через интерфейс, а его генерация через логин / пароль такое себе... да и работает через раз.
2. Вы пробовали восстановить рута в Nexus? Иногда он слетает без причин.
3. У Nexus есть LDAP, а у Verdaccio гитхабовский токен.
4. Разница в памяти тоже существенная. Nexus на легком старте готов сожрать 4-8 Gb памяти, Verdaccio 70 мб.

У меня без квантизации тесты показали ± тот же результат.

Вас не смущает, что в файловой системе у вас лежат .ts, а импортируется .js?
Это решает проблему при экспорте, но при разработке IDEA справедливо будет подставлять *.ts.

// Код сервера
function loader() {
    const {title, id, authorId} = await loadArticle();

    return {
        header: <Header title={title}/>,
        article: {
            id,
            title,
            _links: {
                self: {
                    href: `/articles/${id}`
                },
                edit: {
                    href: `/articles/${id}/edit`
                },
                delete: {
                    href: `/articles/${id}`,
                    method: 'DELETE'
                },
                author: {
                    href: `/users/${authorId}`
                }
            }
        }
    };
}

// Код клиента
function Component() {
    const {header, article} = useLoaderData();
    const {title, _links} = article;

    return (
        <main>
            {header}

            <p>{title}</p>

            <Link to={_links.edit.href}>Редактировать</Link>

            <fetcher.Form method={_links.delete.method} action={_links.delete.href}>
                <button type="submit">Удалить</button>
            </fetcher.Form>

            <Link to={_links.author.href}>Читать</Link>

        </main>
    );
}

export default Component;

Почему бы и нет?

console.error или даже весь поток process.stderr.write можно перехватить, разобрать и вывести на экраны. Вероятно, автор сохранил интригу для следующей статьи. Один retry чего стоит =)

// Код сервера
function loader() {
  const {title} = await loadArticle();

  return {
    header: <Header title={title} />
  };
}

// Код клиента
function Component() {
  const {header} = useLoaderData();

  return (
    <main>
      {header}
    </main>
  );
}

export default Component;

Пример приложения: https://rsc-movies.fly.dev

Подробности: https://remix.run/blog/rsc-preview

Изменение состояния и рендер — разные вещи

Как бы вы не меняли местами названия файлов проблему нагрузки на ЦП и версионирования это не решает. Фигма отличный инструмент, но очень непродуманный для больших и закрытых проектов.
Cookie и localStorage в контексте заголовка отличаются лишь степенью доступности.
Если куки прочитать нельзя (выставив флаг HttpOnly), то зачем их сравнивать?

Содержимое статьи можно уложить в три предложения — храним сессию в куках с флагами secure, HttpOnly и SameSite. Выставляем заголовки X-Content-Type-Options, Strict-Transport-Security, X-XSS-Protection, X-Frame-Options, Referrer-Policy, Content-Security-Policy, Expect-CT, Feature-Policy и Cache-Control. Ну и не забываем про токен.
я с 2015 года вообще ни разу не работал с теми кто может в момент написания кода нагенерировать кучи ошибок, даже если ошибки появляются, их тут же видит разработчик

У вас искаженное восприятие о своих коллегах, и о себе в том числе.
За прошедшие полгода я провел свыше 160 технических интервью, из которых взял каждого 4-го и лишь единицы отправили на первое ревью код, который не ломал обратной совместимости или не вызывал ошибок.
Если вы не видите своих ошибок — это не значит, что их нет.

А какие есть настоящие аргументы в пользу unit тестов против тестировщиков на проекте?

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

писать авто тесты, то это опять же идиотизм ничем не обоснованый в реальной жизни и программист становится тестировщиком ручным в том числе, потому что только ручное тестирование выявляет 99% багов и 1% выявят автотесты

Начните писать тесты, чтобы было наоборот.

У меня было 2 крупных проекта на TS и того: профита 0, оверхед по временным затратам ощутимый, неоправданная головная боль и вынужденные костыли с типами для всех компонентов которые претендуют хоть на какую-то универсальность…

Если вы не справились с описанием типов для собственных же интерфейсов, то сложно представить, что вы там написали.
Первый раз в своей жизни воспользовался Почтой России… и не могу сказать, что 22 сортировки в московских отделениях меня порадовало. Что касается медицины, то средства, которые идут в ОФМС могут мне покрыть два ДМС!
Моя посылка путешествовала 22 дня по московским отделениям, но радует, что дошла :)
Можно еще короче:

new Intl.DateTimeFormat('ru').format(new Date());
let date = new Date();

date.toLocaleString('ru-RU', { day: 'numeric', month: 'numeric', year: 'numeric' });
Для работы с датами есть Intl.DateTimeFormat и Date.prototype.toLocaleString. Базовые потребности они удовлетворяют более чем.
Это когда есть уже готовый набор компонентов, которым можно задать различные значения и затем результирующий JSON вставить верстку:

<Block name="header" options={ header_json }>
     <Block name="menu" options={ menu_json }></Block>
</Block>


Тут все довольно примитивно и что-то еще упрощать смысла особого пока не вижу.
Пусть твой API поддерживает только один формат возвращаемых данных

JSON это, конечно, круто и его точно нужно поддерживать с самого начала. Но с развитием системы должна быть возможность выбора формата выходных данных, например, AtomPub.

Какое-то противоречие.

Причем, формат вывода должен определяться нативно, через заголовок HTTP Accept, а не через лишние конструкции вида ?format=xml.

Ну и какой профит это дает?
1
23 ...

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность