Потому что первые два определяют размер регистра процессора который надо использовать для вычислений. А последний это диапазон значений при которой будет отрабатывать бизнес логика.
А где мораль? Во первых царь изначально ставил некорректные ТЗ, потому что типизацией нельзя пользоваться для валидации данных на этапе компиляции. Надо четко разделять типизацию и валидацию. Время года - это типизация, ограничения по времени года - это валидация. В остальных задачах так же. Во вторых царь зачем то лез реализацию стороннего продукта. Если бы кузнец был сотрудником это допустимо, но по условиям сказки кузнец все же был подрядчиком. Как результат царь занимался микроменеджментом у подрядчика Кузнеца.
Во общем молодец кузнец что не стал заключать контракт с таким заказчиком.
Насчет должности не знаю, но так то это и системный аналитик может делать. Освоить базу языка это просто. Этот человек должен описать в коде контракт и документацию к нему, но не реализовывать логику. Далее из этого контракта сгенерируется документация в необходимые места, а разработчик напишет логику. Тем самым вы сильно сократите объем работы и жизнь разработчику. И это еще не трогая таких моментов что СА не ванга, и не может со 100% точностью описать контракт заранее, что бы его не пришлось править разработчику.
А не логичнее будет заносить эту информацию в код и уже из кода генерировать документацию для конфлюенса, свагера и др? Это же гораздо проще чем синхронизировать код с конфлюенсом.
Я заметил такую большую проблему в мире, не только в россии, что нехватку хороших специалистов закрывают набором низкоквалифицированных специлиастов. В первую очередь во фронте и девопсе. У бекендером дела получше, но тоже такое есть.
В частности девопсов набирают не из девов, а из опсов, т.е. системных администраторов. Отсюдого и описанные вами проблемы. Сисадминов привыкших работать в концепции "работает не трожь" и "зачем развиваться если и так работает" внедряют в айти где они и продолжают работать в этих концепциях. В то время как айти требует подхода Continius Evolution, т.е. непрерывного развития и прогресса. Не зря в профессии девопс первым идет дев, в первую необходимо уметь собирать софт, его разворачивать, настраивать мониторинг, знать чего собирать в этом мониторинге, настраивать логирование и следить за логами. Всем этим 99% девопсов не занимается. Вместо этого они ставят npm зависимости в проде в контейнер во время запуска и запускают исходники в режиме dev и считают это потрясающе выполненной работой.
GitOps на самом деле хорошая концепция, но вы от нее слишком много хотите.
Есть вариант хранить конфиги окружений на машинах, но тогда появляется проблема как их версионировать, как их поддерживать нескольким девопсам, как синхронизировать окружения, как обновить не лазя лишний раз в продуктовый контур. На все эти вопросы отвечает GitOps. Вы храните конфиге в гите и раскатываете из гита так же как вы раскатываете софт.
Да конфиг использует внешние артефакты для своей работы, но это так же плюс. Ибо если в этот конфиг каждый раз вносить хеш сборки ручками то можно замучаться. А так новая версия сервиса накатывается автоматом с ее релизом.
Атака на __proto__ и другие не эксплуатируема. Аналогичная уязвимость в Кибане так же закрыта. При попытке эксплуатации мы увидим код атаки и IP атакующего.
В связи с тем что логи собираются в т.ч. с неавторизованных клиентов авторизацию прикрутить невозможно. Любая авторизация для анонимных клиентов невозможна ввиду того что весь код в вебе является опенсурсом и авторизация элементарно копируется. Единственный способ защиты это антиспам системы и другие системы защиты применяемые для обычного апи.
Чисто технически да. Но мы используем другой подход. Если у клиента случается ошибка то на экране всплывает оранжевый тоаст с кодом ошибки. Код представляет из себя последние четыре цифры хеша ошибки.
Клиенту или тестировщику достаточно сообщить эти четыре цифры что бы их легко найти в логах.
Это демонстрационная версия логгера, она упрощена для наглядности. В реальном логгере можно докручивать необходимый вам функционал, например обогащение информацией, обработку отсутствия сети, использование sendBeacon вместо fetch и т.п.
Сервер всегда работал хорошо и мгновенно. Дело в устройстве. Например хабру оно 5 секунд грузит html и сразу его рисует, потом еще 5 секунд работают скрипты, только потом оно шевелится. Статичный сайт сразу показал лоадер, через 5 секунд начал рисовать, к 10 секунде закончил и сразу стал юзабельным. SSR с регидрацией 20 секунд рисовал белый экран, потом сразу высветилась картинка и сайт был юзабельным.
Я к своим системам прикрутил систему веб мониторинга. Теперь могу в графане видеть клиентские метрики WebVitals в реалтайме. Сравнил системы написанные на nextjs + ssr и через CRA. SSR победил на мощных компьютерах, CRA на слабых телефонах.
Ближе к лету будет статья на хабре с цифрами и графиками.
Получается это не тест стейт менеджеров, а тест систем мемоизации?
В частности делается допущение что результат работы функции всегда зависит от входных параметров? Хотя в реальной жизни функция постоянно берет данные из вне, например из сетевого запроса или банальный Mtah.random() сломает всю мемоизацию?
Статья построенная на стереотипах и собственных ошибках без единого аргумента и доказательства. С полным игнорированием выигрышных моментов в тестах.
Начиная с баннерной анимации где автор сделал баг и думает что виноват SC и заканчивая тонной ошибочных стереотипов. А еще этот странный пример с евентбасом. Видимо попытка использовать эффект чубаки. Кстати в npm полно пакетов с евентабсом.
createGlobalStyles - используется для стилизации внешних компонентов. Например для сброса стилей html и body, не писать же на них компонент. Или для стилизации внешней библиотеки, например нотификаций.
Так же высосаны из пальца тормоза сборки на SC на тайпскрипте и полное игнорирование того что sass тоже собирать надо еще более медленными инструментами. Сборка SC ускоряется в сотни раз если собираться компиляторов на rust, что встроен в NextJS по умолчанию. Сборку на sass не ускорить ни чем.
И еще десяток ложных не аргументированных утверждений в том же духе.
А в чем смысл такой типизации? При том что x в 99,99% случаев это динамические данные полученные из внешней среды?
Потому что первые два определяют размер регистра процессора который надо использовать для вычислений. А последний это диапазон значений при которой будет отрабатывать бизнес логика.
А где мораль?
Во первых царь изначально ставил некорректные ТЗ, потому что типизацией нельзя пользоваться для валидации данных на этапе компиляции. Надо четко разделять типизацию и валидацию. Время года - это типизация, ограничения по времени года - это валидация. В остальных задачах так же.
Во вторых царь зачем то лез реализацию стороннего продукта. Если бы кузнец был сотрудником это допустимо, но по условиям сказки кузнец все же был подрядчиком. Как результат царь занимался микроменеджментом у подрядчика Кузнеца.
Во общем молодец кузнец что не стал заключать контракт с таким заказчиком.
Насчет должности не знаю, но так то это и системный аналитик может делать. Освоить базу языка это просто. Этот человек должен описать в коде контракт и документацию к нему, но не реализовывать логику. Далее из этого контракта сгенерируется документация в необходимые места, а разработчик напишет логику. Тем самым вы сильно сократите объем работы и жизнь разработчику. И это еще не трогая таких моментов что СА не ванга, и не может со 100% точностью описать контракт заранее, что бы его не пришлось править разработчику.
А не логичнее будет заносить эту информацию в код и уже из кода генерировать документацию для конфлюенса, свагера и др? Это же гораздо проще чем синхронизировать код с конфлюенсом.
Разработчица согласилась написать статью.
У нас стек ELK. Loki в названии для примера потому что таким способом можно собирать логи с любой системы серверной логирования.
А можете рассказать почему понадобилось выбрать именно кракен, а не nginx/ingress или другую попсу?
Я заметил такую большую проблему в мире, не только в россии, что нехватку хороших специалистов закрывают набором низкоквалифицированных специлиастов. В первую очередь во фронте и девопсе. У бекендером дела получше, но тоже такое есть.
В частности девопсов набирают не из девов, а из опсов, т.е. системных администраторов. Отсюдого и описанные вами проблемы. Сисадминов привыкших работать в концепции "работает не трожь" и "зачем развиваться если и так работает" внедряют в айти где они и продолжают работать в этих концепциях. В то время как айти требует подхода Continius Evolution, т.е. непрерывного развития и прогресса. Не зря в профессии девопс первым идет дев, в первую необходимо уметь собирать софт, его разворачивать, настраивать мониторинг, знать чего собирать в этом мониторинге, настраивать логирование и следить за логами. Всем этим 99% девопсов не занимается. Вместо этого они ставят npm зависимости в проде в контейнер во время запуска и запускают исходники в режиме dev и считают это потрясающе выполненной работой.
GitOps на самом деле хорошая концепция, но вы от нее слишком много хотите.
Есть вариант хранить конфиги окружений на машинах, но тогда появляется проблема как их версионировать, как их поддерживать нескольким девопсам, как синхронизировать окружения, как обновить не лазя лишний раз в продуктовый контур. На все эти вопросы отвечает GitOps. Вы храните конфиге в гите и раскатываете из гита так же как вы раскатываете софт.
Да конфиг использует внешние артефакты для своей работы, но это так же плюс. Ибо если в этот конфиг каждый раз вносить хеш сборки ручками то можно замучаться. А так новая версия сервиса накатывается автоматом с ее релизом.
Атака на __proto__ и другие не эксплуатируема. Аналогичная уязвимость в Кибане так же закрыта. При попытке эксплуатации мы увидим код атаки и IP атакующего.
В связи с тем что логи собираются в т.ч. с неавторизованных клиентов авторизацию прикрутить невозможно. Любая авторизация для анонимных клиентов невозможна ввиду того что весь код в вебе является опенсурсом и авторизация элементарно копируется. Единственный способ защиты это антиспам системы и другие системы защиты применяемые для обычного апи.
Чисто технически да. Но мы используем другой подход. Если у клиента случается ошибка то на экране всплывает оранжевый тоаст с кодом ошибки. Код представляет из себя последние четыре цифры хеша ошибки.
Клиенту или тестировщику достаточно сообщить эти четыре цифры что бы их легко найти в логах.
Это демонстрационная версия логгера, она упрощена для наглядности. В реальном логгере можно докручивать необходимый вам функционал, например обогащение информацией, обработку отсутствия сети, использование sendBeacon вместо fetch и т.п.
Сервер всегда работал хорошо и мгновенно. Дело в устройстве. Например хабру оно 5 секунд грузит html и сразу его рисует, потом еще 5 секунд работают скрипты, только потом оно шевелится. Статичный сайт сразу показал лоадер, через 5 секунд начал рисовать, к 10 секунде закончил и сразу стал юзабельным. SSR с регидрацией 20 секунд рисовал белый экран, потом сразу высветилась картинка и сайт был юзабельным.
Я к своим системам прикрутил систему веб мониторинга. Теперь могу в графане видеть клиентские метрики WebVitals в реалтайме. Сравнил системы написанные на nextjs + ssr и через CRA. SSR победил на мощных компьютерах, CRA на слабых телефонах.
Ближе к лету будет статья на хабре с цифрами и графиками.
Получается это не тест стейт менеджеров, а тест систем мемоизации?
В частности делается допущение что результат работы функции всегда зависит от входных параметров? Хотя в реальной жизни функция постоянно берет данные из вне, например из сетевого запроса или банальный Mtah.random() сломает всю мемоизацию?
Сделал копию с mol_wire_solo. Цифры не сходятся. Там как то кеш должен отработать?
А подскажи как добавить мой стейт менеджер https://github.com/LabEG/reca в тест?
Получается мне нужно просто класс написать отнаследовав от автостора, со свойствами и методами и все?
Статья построенная на стереотипах и собственных ошибках без единого аргумента и доказательства. С полным игнорированием выигрышных моментов в тестах.
Начиная с баннерной анимации где автор сделал баг и думает что виноват SC и заканчивая тонной ошибочных стереотипов. А еще этот странный пример с евентбасом. Видимо попытка использовать эффект чубаки. Кстати в npm полно пакетов с евентабсом.
createGlobalStyles - используется для стилизации внешних компонентов. Например для сброса стилей html и body, не писать же на них компонент. Или для стилизации внешней библиотеки, например нотификаций.
Так же высосаны из пальца тормоза сборки на SC на тайпскрипте и полное игнорирование того что sass тоже собирать надо еще более медленными инструментами. Сборка SC ускоряется в сотни раз если собираться компиляторов на rust, что встроен в NextJS по умолчанию. Сборку на sass не ускорить ни чем.
И еще десяток ложных не аргументированных утверждений в том же духе.