Обновить
18
Oleg Loutchansky@Luchnik22

Developer

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

Кстати, есть ещё неплохой https://mdxjs.com/
Уже со всеми готовыми пакетами для полноценного парсинга markdown

А не думали решить проблему с разрастающимся размером JWT токена через битовую маску? Например
доступ к X - это 1
доступ к Y - это 2
доступ к Z - это 4
доступ к XY - это 1 + 2 = 3
доступ к XYZ - это 1 + 2 + 4 = 7

с помощь битовой маски можно легко будет достать все права доступа. Хранить это можно в виде той же строки "0000010000", тогда при ограничении заголовка в 4кб вы сможете записать права на 512 систем, если нужно больше, то можно хранить в виде целых чисел, тогда вы сможете записать права на 262 144 систем (unsigned big int может поместить в себя 64 системы и занимает 1 байт -> 4096 * 64 = 262 144)

P.S. вспомнил отличный пример реализации у VK: https://dev.vk.com/reference/access-rights

Ещё можно добавить немного анимации, чтобы градиент ожил:

header h1 {
		...
		background-size: 400%;
    animation: color-change 10s ease-in-out infinite;

    @keyframes color-change {
        0% {
            background-position: 0px 50%;
        }
        50% {
            background-position: 100% 50%;
        }
        100% {
            background-position: 0px 50%;
        }
    }
}

Спасибо за статью, отличным примером проблемы служит компонент календаря в ui-kit'ах - иногда он включает в себя более 30 разных свойств, которые так или иначе меняют его поведение. Добавление ещё одного свойства может вызывать боль, потому что легко поломать поведение других свойств.

Одно из классных решений, которые я видел - использовать композицию. В том же самом mui, она как раз применяется или более явный пример можно увидеть при использовании фреймворка для редактирования lexical. Если вдруг для вашего проекта нужно специфичное поведение - вы всегда можете его реализовать из базовых блоков. Но у такого подхода тоже есть минус - при обновлении дизайн системы, может понадобится обновить компонент, который в проекте.

Про Cohesion очень хорошо рассказывают в ролике на JS Conf 2018 года

При обсуждении YDB и теоремы CAP, мне сегодня намекнули, что лучше ей не пользоваться, так как не всё так однозначно (перевод на хабре)

P.S. Моё мнение было, что это CP система, в жертву A

Не совсем про DDoS и не совсем это вам подойдёт (так как у вас игры и UDP), но если вдруг необходимо проверить нагрузку на веб-сервисы (сайт/API), то рекомендую попробовать https://github.com/yandex/yandex-tank (мы его используем) или https://k6.io/ (чуть проще, но есть минусы в виде отсутствия точной настройки)

На самом деле понятие нормы отсуствует, но есть теория, что государство должно поставить цель по уровню инфляции (как это делать, есть отдельные теории), и если уровень инфляции выше, то плавно повышать ставку, чтобы охладить экономику, если ниже, то плавно понижать, чтобы на оборот разогреть, всё это желательно делать в пределах 1%, так как система реагирует инерционно

Вообще там множества параметров и рычагов, с помощью которых можно это дело регулировать

При ставке в 15% - 20% никакой бизнесс не будет развиваться, потому что кредит в 25% никто брать не будет, следовательно экономика начнёт стагнировать в лучшем случае, в худшем, люди начнут экономить - нести все деньги на вклад в банк, следовательно меньше покупать, следовательно у существующего бизнеса начнут падать продажи, что приведёт к банкротству, следовательно к падению экономики.

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

Спасибо за статью - полезно, что думаете если bash скрипты заменять на что - то вроде ansible? И можете пожалуйста подсказать (если это известно), сколько примерно в месяц будет обходиться Google Cloud для такой конфигурации?

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

Возможно стоит составлять не 100 идей из своих возможностей (C++ и микроконтроллеры), а 100 проблем, в решении которых нуждаются люди. Дальше уже будет проще составлять решения этих проблем (идеи). Да и если это насущные проблемы, то за них будут охотнее платить.

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

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

У меня в практике было два случая:
1. Команду полностью устраивал дизайнер, а его уволили по метрике (ревью дизайна редко проходил), в итоге команда почти встала, дизайнера не могли найти месяца два, к слову сейчас этот чувак дизайн директор.
2. Команда сначала пыталась помочь члену (возвращала обратную связь, придумывала план, входило в положение), а потом через некоторое время отказалась от работы с ним (его не уволили - перевели в другую команду), после чего в команде нашли замену, а чувак принял во внимание весь опыт и уже в другой команде показывал хороший перформанс.

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


Есть вариант ещё — часто используемые вещи выносить в отдельную папочку shared или common. В целом эта архитектура не является серебряной пулей. Скорее это некий компромисс (trade off) в сторону более запутанной абстракции, но зато с высокой связанностью логического контекста.

Taiwan Semiconductor писали, что дефицит интегральных схем и электроники продлится до 2022 года, так что да, цены будут стремительно расти. Тоже самое поговаривают в Intel и Nvidia

Это здорово, если вода в чайнике действительно начнёт закипать через 5 минут, ведь очень часто бывает (постфактум взятия задачи в работу), что чайник занят, на техническом обслуживании или во время кипячения свет неожиданно пропадает, а ещё по мимо задачи сделать чай прилетают: сделать бутерброд, накрыть на стол, зажечь свечи и все эти задачи нужно делать параллельно.

Спасибо за статью, можно ещё добавить шифрование через ansible-vault

Посоветуйте пожалуйста сайты для размещения резюме.

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

В книге "Зачем мы спим" нейрофизиолог Мэттью Уолкер, как раз рекомендует поспать днём 40 — 50 минут, главное это сделать до 15:00 часов, тогда не будет чувство разбитости и не сбивается режим. Его исследования показали, что при отмены Сиесты в Греции, число сердечно сосудистых заболеваний резко увеличилось, а когда в Греции снова вернули её, то число на оборот упало. Тот же самый эффект происходит при переходе с зимнего на летнее время и обратно, когда население сначала спит на час больше, а потом на час меньше.


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

Если браузер устройства не поддерживает Service Worker, то эта страница всегда будет отображаться. Ну и при первом открытии пользователи всегда будут видеть 404 страницу.


Эта проблема (context root'а или pathname) исправляется простыми двумя скриптами в 404.html и index.html.


Вообще это не единственная проблема с Service Worker, но у вас вроде отдельный домен, поэтому не должно больше вызывать сложностей.

Понятия сеньора, мидла и джуна — это субъективное мнение каждого, у меня градация такая:


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


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

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность