Про core папку несогласен. Те же стандартные библиотеки и внешние библиотеки для вычислений - не вижу ничего плохого в том, чтобы использовать их в core. Core скорее должен быть абстрагирован от бл, но требовать, чтобы он не зависел от внешних библиотек - изобретать велосипеды на каждый чих. Ровно как и DI - не вижу ничего плохого сам DI не писать, а использовать готовый, а в core добавить для него абстракции, чтобы в бл было меньше связей на внешнее и больше на core. Не инициализация, а именно сам сервис DI.
Проблема в терминологии =) В данном случае под фичами я имел ввиду не фичи из fsd, а фичи как полноценные модули. Они же слайсы из fsd.
Если мы берём fsd: У нас получается два слайса: Чат и Урок. Фичи это аналог usecase (mutation/action). Виджеты это полноценная рабочая единица. И вот у нас есть два виджеты: Урок и Чат, которые принимают в качестве параметра ИдУрока и ИдЧата соответственно. Внутри себя они реализуют логику.
Именно для болшей изолированности у меня было принято решение раздеить каждую фичу на слои и чтобы у каждой был свой доменный слой
Да, Я привел похожее что у меня получилось, потом дополнил про nx как способ для очистки shared. Ну дефолтный fsd совсем не годится уже на средних проектах, т.к. папки быстро разрастаются и нужно инвертировать фичи и слои для того, чтобы был порядок в доменах.
По поводу контроля импортов - есть плагин для eslint, но я им не пользовался. Но он легко гуглится =)
Вот тут бы хотелось сразу получить наглядный пример. Потому что с одной стороны для кроссимпортов есть ясных механизм. А с другой стороны импорты между фичами в принципе конфликтуют с идеей, что фичи это код объединенный общей целью и не связный с другими фичами.
Я буду говорить про мобильное приложение (это для того, чтобы было представление о визуале). К примеру: Имеем: Чат, Урок, Плеер. Чат это полноценная фича. Чат может быть типов: Учебный, Поддержка (Консультант), Групповой. Урок это тоже полноценная фича. Плеер это не фича, но имеет большую кодовую базу. Имеет превьюшки и открывается поверх как в Ютубе.
Теперь у нас задача от бизнеса:
В компоненте урока должен быть групповой чат (не на странице, урок переиспользуется на разных страницах).
В учебных чатах (не на странице, не на списке чатов) должен быть список уроков из той же дисциплины, к которой принадлежит урок. Это для того, чтобы быстро навигироваться между чатами и можно было открыть урок. Так же нужно в этом списке отображать статус задания (сдал/отклонено/на проверке).
Когда видео открывается на весь экран, оставшуюся часть экрана должен занимать чат по уроку.
И вот если с 3 проблем особых нет и решается через рендер функцию, то в 1-2 появляется цикличная зависимость. И вот тут начинаются пляски с тем, как сделать лучше, кого куда вынести, где что создать, как меньше написать бойлерплейта =)
Т.е. в shared попадали переиспользуемые компоненты, которые дополнялись абстракциями, чтобы не зависеть от фич. Появился бойлерплейт и бриджи, но связанность уменьшилась, абстракция увеличилась.
Папка shared начала разрастаться. Я стал использовать nx и у меня многое из shared переехало как отдельные пакеты в папку libs. Тем самым уже на уровне кода я абстрагировал полноценные блоки (Плееры, UI библиотеку, сторы - не фичи, а именно надстройки над сторами для хранения, и т.д.)
Поэтому нет особого смысла об этом говорить(если мы о хороших практиках, разумеется).
Почему нет смысла говорить, если доставка ключа это тоже важно? Один из факторов популярности асимметричных как раз в том, что публичный ключ можно передавать по незащищенному каналу. И я бы не сказал, что использование асимметричных это плохая практика.
Всё упирается в нужды, чем мы готовы пожертвовать ради чего-то другого, что получим.
И как это противоречит моему изначальному комментарию, что нужно иметь достаточный датасет?
Если будет достаточно зашифрованных сообщений, то его можно будет расшифровать, что вы и подтвердили в своем комментарии, идя от обратного, что если не использовать достаточно много шифрованный сообщений (каждый раз менять ключ), то его сложно расшифровать частотным. Шифр Вернама хорош как раз из-за того, что один и тот же ключ не переиспользуется, но если мы будем иметь N сообщений зашифрованных одним ключом, то его с лёгкостью удасться взломать.
Так что ваш коммент никак не противоречит моему изначальному комменту, а только его подтверждает. Что сколь угодно случайный ключ можно будет расшифровать при достаточном кол-ве зашифрованных данных...
И тут главная фишка вообще не в случайном ключе, а в том, что этот ключ одноразовый.
Некоторые новые форматы да, но в основе монотонные. Но мне кажется, не проблем разбить на части и нарисовать несколько поверх друг друга. Ну а совсем многоцветные - тогда растр.
Но у меня не было такой необходимости для иконок. Максимум разный цвет у иконок, но не разноцветные =)
Svg и шрифты - векторные. Svg сложнее рендерить, чем шрифты для устройства. Рендер шрифтов есть везде.
Icomoon просто создаёт файл шрифта из предоставленных ему svg картинок, а затем нужно подключить этот шрифт, внутри приложения написать символ, соответствующий вашей иконке. Маппинг "символ -> иконка" так же предоставляется icomoon.
Всё всегда будет упираться во время. Даже если условно каждой букве будет назначен случайный символ (книжный шифр/Виженера), то частотным анализом можно будет взломать. Т.е. просто имея что-то зашифрованное - рано или поздно при достаточном датасете оно "взломается".
Поэтому единственный вариант - чтобы ничего не было известно посторонним. Но тогда легче просто лично шепнуть на ухо без шифровки, нежели полагаться на доставку пакетов.
"Извиняюсь, что зря потратился временем" Извиняюсь, потратился - возвратные глаголы. Подлежащее тут "Я", поэтому без употребления притяжательных местоимений всё будет указывать на себя. Себя можно простить за потраченное своё время, но других не обязательно =)
Есть ещё подход для иконок - шрифты. Сервисы по типу Icomoon позволяют конвертировать svg в шрифт. А уже этот шрифт можно использовать где угодно. Хоть в играх, хоть в мобилке, хоть в десктоп приложениях. Лично я его использую для мобильных приложений и десктоп. А шрифты это тот же вектор.
Что же надо использовать? А я не знаю, какие у вас данные, надо на распределение глянуть.
Ну тогда стоило привести примеры. Когда медиана уместна, а когда другие более показательны. А так это больше похоже на наброс, а не на конструктив.
Кажется, что в этих примерах даже среднее скажет нам больше о том, как на самом деле выглядят зарплаты.
"Когда кажется, креститься надо", ну или хотя бы самому разобраться, прежде чем писать. Что вам среднее показывает того, что не показывает медиана в ваших данных? Что вы хотели увидеть? Какая цель?
А в чём сложности? Какой именно способ оплаты? Туда можно прикрутить любой способ оплаты, который ничем не будет отличаться от обычного сайта, ведь это обычный "сайт".
Про core папку несогласен.
Те же стандартные библиотеки и внешние библиотеки для вычислений - не вижу ничего плохого в том, чтобы использовать их в core.
Core скорее должен быть абстрагирован от бл, но требовать, чтобы он не зависел от внешних библиотек - изобретать велосипеды на каждый чих.
Ровно как и DI - не вижу ничего плохого сам DI не писать, а использовать готовый, а в core добавить для него абстракции, чтобы в бл было меньше связей на внешнее и больше на core. Не инициализация, а именно сам сервис DI.
Проблема в терминологии =)
В данном случае под фичами я имел ввиду не фичи из fsd, а фичи как полноценные модули. Они же слайсы из fsd.
Если мы берём fsd:
У нас получается два слайса: Чат и Урок.
Фичи это аналог usecase (mutation/action).
Виджеты это полноценная рабочая единица.
И вот у нас есть два виджеты: Урок и Чат, которые принимают в качестве параметра ИдУрока и ИдЧата соответственно.
Внутри себя они реализуют логику.
Да, Я привел похожее что у меня получилось, потом дополнил про nx как способ для очистки shared.
Ну дефолтный fsd совсем не годится уже на средних проектах, т.к. папки быстро разрастаются и нужно инвертировать фичи и слои для того, чтобы был порядок в доменах.
По поводу контроля импортов - есть плагин для eslint, но я им не пользовался. Но он легко гуглится =)
Я буду говорить про мобильное приложение (это для того, чтобы было представление о визуале).
К примеру:
Имеем: Чат, Урок, Плеер.
Чат это полноценная фича. Чат может быть типов: Учебный, Поддержка (Консультант), Групповой.
Урок это тоже полноценная фича.
Плеер это не фича, но имеет большую кодовую базу. Имеет превьюшки и открывается поверх как в Ютубе.
Теперь у нас задача от бизнеса:
В компоненте урока должен быть групповой чат (не на странице, урок переиспользуется на разных страницах).
В учебных чатах (не на странице, не на списке чатов) должен быть список уроков из той же дисциплины, к которой принадлежит урок. Это для того, чтобы быстро навигироваться между чатами и можно было открыть урок. Так же нужно в этом списке отображать статус задания (сдал/отклонено/на проверке).
Когда видео открывается на весь экран, оставшуюся часть экрана должен занимать чат по уроку.
И вот если с 3 проблем особых нет и решается через рендер функцию, то в 1-2 появляется цикличная зависимость.
И вот тут начинаются пляски с тем, как сделать лучше, кого куда вынести, где что создать, как меньше написать бойлерплейта =)
У меня эволюция проекта происходила так:
Взял за основу FSD и CA, но перед этим всем я изучал и другие архитектуры на другом стэке (тот же BLoC, HA, VIPER). Получилось что-то типо:
Т.е. в shared попадали переиспользуемые компоненты, которые дополнялись абстракциями, чтобы не зависеть от фич.
Появился бойлерплейт и бриджи, но связанность уменьшилась, абстракция увеличилась.
Папка shared начала разрастаться. Я стал использовать nx и у меня многое из shared переехало как отдельные пакеты в папку libs. Тем самым уже на уровне кода я абстрагировал полноценные блоки (Плееры, UI библиотеку, сторы - не фичи, а именно надстройки над сторами для хранения, и т.д.)
Почему нет смысла говорить, если доставка ключа это тоже важно?
Один из факторов популярности асимметричных как раз в том, что публичный ключ можно передавать по незащищенному каналу.
И я бы не сказал, что использование асимметричных это плохая практика.
Всё упирается в нужды, чем мы готовы пожертвовать ради чего-то другого, что получим.
И как это противоречит моему изначальному комментарию, что нужно иметь достаточный датасет?
Если будет достаточно зашифрованных сообщений, то его можно будет расшифровать, что вы и подтвердили в своем комментарии, идя от обратного, что если не использовать достаточно много шифрованный сообщений (каждый раз менять ключ), то его сложно расшифровать частотным.
Шифр Вернама хорош как раз из-за того, что один и тот же ключ не переиспользуется, но если мы будем иметь N сообщений зашифрованных одним ключом, то его с лёгкостью удасться взломать.
Так что ваш коммент никак не противоречит моему изначальному комменту, а только его подтверждает.
Что сколь угодно случайный ключ можно будет расшифровать при достаточном кол-ве зашифрованных данных...
И тут главная фишка вообще не в случайном ключе, а в том, что этот ключ одноразовый.
Это форварды клиентский сообщений, что видно на каждом сообщении.
Верстка таблиц указывает всё же не на тг бот.
С чего бы?)
Частотный анализ как раз и применяется когда у нас есть зашифрованный текст, где мы не знаем на что были заменены изначальные символы.
Некоторые новые форматы да, но в основе монотонные.
Но мне кажется, не проблем разбить на части и нарисовать несколько поверх друг друга.
Ну а совсем многоцветные - тогда растр.
Но у меня не было такой необходимости для иконок. Максимум разный цвет у иконок, но не разноцветные =)
Svg и шрифты - векторные.
Svg сложнее рендерить, чем шрифты для устройства.
Рендер шрифтов есть везде.
Icomoon просто создаёт файл шрифта из предоставленных ему svg картинок, а затем нужно подключить этот шрифт, внутри приложения написать символ, соответствующий вашей иконке. Маппинг "символ -> иконка" так же предоставляется icomoon.
Ну тут два варианта:
LLM вызывает определенную функцию с параметрами. Нужно функцию заранее готовить.
LLM выдаёт текстом что-то, и это "что-то" должна понимать ваша программа. Нужно заранее готовить сервис, который понимает ответы LLM.
Из этих двух вариантов легче и надёжнее первый вариант.
Всё всегда будет упираться во время.
Даже если условно каждой букве будет назначен случайный символ (книжный шифр/Виженера), то частотным анализом можно будет взломать.
Т.е. просто имея что-то зашифрованное - рано или поздно при достаточном датасете оно "взломается".
Поэтому единственный вариант - чтобы ничего не было известно посторонним.
Но тогда легче просто лично шепнуть на ухо без шифровки, нежели полагаться на доставку пакетов.
"Извиняюсь, что зря потратился временем"
Извиняюсь, потратился - возвратные глаголы.
Подлежащее тут "Я", поэтому без употребления притяжательных местоимений всё будет указывать на себя.
Себя можно простить за потраченное своё время, но других не обязательно =)
https://rosstat.gov.ru/labor_market_employment_salaries
Там есть и по субъектам, и по типам предприятий, и гпх.
Есть ещё подход для иконок - шрифты.
Сервисы по типу Icomoon позволяют конвертировать svg в шрифт.
А уже этот шрифт можно использовать где угодно. Хоть в играх, хоть в мобилке, хоть в десктоп приложениях.
Лично я его использую для мобильных приложений и десктоп. А шрифты это тот же вектор.
Сейчас в РФ медиана 75к, средняя 90к.
Разница в 20% относительно большая, но не критичная.
Если взять 2021 год, то там 40к и 60к, что даёт разницу в 50%.
Т.е. прогресс в сторону выравнивания есть.
(Средняя-Медиана)/Медиана
PS. Зарплаты немного округлил, т.к. это комментарий, а не статья.
Ну тогда стоило привести примеры.
Когда медиана уместна, а когда другие более показательны.
А так это больше похоже на наброс, а не на конструктив.
"Когда кажется, креститься надо", ну или хотя бы самому разобраться, прежде чем писать.
Что вам среднее показывает того, что не показывает медиана в ваших данных?
Что вы хотели увидеть? Какая цель?
А что нужно?
А в чём сложности?
Какой именно способ оплаты?
Туда можно прикрутить любой способ оплаты, который ничем не будет отличаться от обычного сайта, ведь это обычный "сайт".