4 года назад в МСК арендовал квартиру за 70, сейчас такая стоит около 100...
Такое чувство, что подобными статьями с ЗП разработчикам работодатели хотят демпинговать, а у меня как была ЗП 4 года назад около $5к, так и сейчас около $6к, хотя в рублях почти в два раза больше! Только вот купить в два раза больше я не могу)
Хабр давно засрал сам себя. Уже и на свои правила плюет, статьи не блокирует, если они набрали просмотры и активность, хотя ничего кроме нытья в статьях нет. А на жалобу отвечают что нет нарушений (Я не про текущую статью)
У моей знакомый был случай на парковке. Один пьяный тип снёс ей бампер, фары, крыло. Страховки у него нет, прав уже был лишён за пьяное вождение. Присудили компенсировать ремонт. Он нигде не работал, так ещё это существо через несколько месяцев после суда в ящик сыграло...
И?) Человек спрашивал чем опасно исследовать без договора. Я скинул документ, где написано чем это грозит. Собственно этот проект и был подготовлен для того, чтобы обезопасить исследователей, если бы его приняли, то как раз наоборот, этих бы последствий и не было.
Пока что самое напрягающее для меня место в typescript это обработка ошибок. Некоторые либы вообще не наследуют ошибки от Error, а просто выбрасывают кастомный объект с описанием ошибки. Но проблема в том, что об этом нельзя никак узнать кроме чтения кода полностью, ну или пока в рантайме не появится какая-то белиберда вместо ошибки...
Эмм, а зачем расставаться с typescript? Чтобы как раньше открывать 100500 доков для разных либ и узнавать какие есть функции, что они принимают и что отдают? Мне как-то легче описание функций смотреть в IDE, а не тратить время на то, чтобы найти доку по определенной либе. PS. Я не имею ввиду начальное знакомство с либой, это именно про этап взаимодействия с либой.
Уже на скрине с клауди видно чем нейронки отличается от интеллекта. Чтобы скинуть 5 кг нужен дефицит почти в 40.000 ккал, итого если за 30 дней, то ежедневный дефицит должен быть 1300, а это очень большой дефицит для неподготовленного человека. С таким дефицитом можно где-то упасть и головой удариться... Во вторых, зачем скидывать 5кг? Нужно красивое тело - это и дефицит и тренировки, но при таком варианте не обязательно цифры на весах покажут меньше. Т.е. вначале впринципе нужно понять цель.
А вообще, если серьёзно необходимо изменить тело, то проконсультируйтесь с тренером и врачом (ну или хотя бы с нутрициологом, у которого мед образование или студентом, а не просто рандомный сертификат). Потому что дефицит (более 500 в день) может сильно на весь организм повлиять. И к тому же, есть вероятность, что проблема лишнего веса это заболевание.
5 млрд карточек вроде, а не запросов. Но все равно непонятно что это за единица карточка/сутки. Может на тот момент у них требования были 300.000, а сейчас выросли больше...
Я и написал об этом, чтобы был мост между моим комментом и дальнейшим обсуждением. В дальнейшем используется терминология fsd.
Entities - это компоненты, которые используются для отображения, а не для взаимодействия. Features - это компоненты действий. Widgets - это полноценные компоненты.
Что чат, что уроки - полноценные компоненты, в которые достаточно передать только ид для дальнейшей полноценной работы, будут располагаться в widgets. Конкретные задачи были описаны в комменте выше:
Теперь у нас задача от бизнеса:
В компоненте урока должен быть групповой чат (не на странице, урок переиспользуется на разных страницах).
В учебных чатах (не на странице, не на списке чатов) должен быть список уроков из той же дисциплины, к которой принадлежит урок. Это для того, чтобы быстро навигироваться между чатами и можно было открыть урок. Так же нужно в этом списке отображать статус задания (сдал/отклонено/на проверке).
Про 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 библиотеку, сторы - не фичи, а именно надстройки над сторами для хранения, и т.д.)
Если чисто кнопка для push to talk, то почему не xbuttons?
Вот да, цены на аренду улетели в космос...
4 года назад в МСК арендовал квартиру за 70, сейчас такая стоит около 100...
Такое чувство, что подобными статьями с ЗП разработчикам работодатели хотят демпинговать, а у меня как была ЗП 4 года назад около $5к, так и сейчас около $6к, хотя в рублях почти в два раза больше! Только вот купить в два раза больше я не могу)
2019 год, ВУЗ, разработчик php+vue 140, тимлид 180.
В коммерции соответственно больше было.
Я в 2021 ушёл в коммерцию на мида+, 300+
Либо продлеваем срок до 31 мая =)
Скрытый текст
В уведомлении нажимаем "Подробнее", внизу страницы будет запросить доп время.
Хабр давно засрал сам себя.
Уже и на свои правила плюет, статьи не блокирует, если они набрали просмотры и активность, хотя ничего кроме нытья в статьях нет. А на жалобу отвечают что нет нарушений (Я не про текущую статью)
https://habr.com/ru/articles/934240/
Чисто нытье и эмоциональная статья, но хабр считает, что она не нарушает правил...
У моей знакомый был случай на парковке.
Один пьяный тип снёс ей бампер, фары, крыло.
Страховки у него нет, прав уже был лишён за пьяное вождение.
Присудили компенсировать ремонт. Он нигде не работал, так ещё это существо через несколько месяцев после суда в ящик сыграло...
И?)
Человек спрашивал чем опасно исследовать без договора.
Я скинул документ, где написано чем это грозит.
Собственно этот проект и был подготовлен для того, чтобы обезопасить исследователей, если бы его приняли, то как раз наоборот, этих бы последствий и не было.
Пока что самое напрягающее для меня место в typescript это обработка ошибок.
Некоторые либы вообще не наследуют ошибки от Error, а просто выбрасывают кастомный объект с описанием ошибки. Но проблема в том, что об этом нельзя никак узнать кроме чтения кода полностью, ну или пока в рантайме не появится какая-то белиберда вместо ошибки...
Эмм, а зачем расставаться с typescript?
Чтобы как раньше открывать 100500 доков для разных либ и узнавать какие есть функции, что они принимают и что отдают?
Мне как-то легче описание функций смотреть в IDE, а не тратить время на то, чтобы найти доку по определенной либе.
PS. Я не имею ввиду начальное знакомство с либой, это именно про этап взаимодействия с либой.
У Макса же есть и так веб версия...
https://web.max.ru/
Если вам действительно интересно, то спросите у автора)
Смысл вам писать мне вопросы?)
Уже на скрине с клауди видно чем нейронки отличается от интеллекта.
Чтобы скинуть 5 кг нужен дефицит почти в 40.000 ккал, итого если за 30 дней, то ежедневный дефицит должен быть 1300, а это очень большой дефицит для неподготовленного человека. С таким дефицитом можно где-то упасть и головой удариться...
Во вторых, зачем скидывать 5кг? Нужно красивое тело - это и дефицит и тренировки, но при таком варианте не обязательно цифры на весах покажут меньше. Т.е. вначале впринципе нужно понять цель.
А вообще, если серьёзно необходимо изменить тело, то проконсультируйтесь с тренером и врачом (ну или хотя бы с нутрициологом, у которого мед образование или студентом, а не просто рандомный сертификат).
Потому что дефицит (более 500 в день) может сильно на весь организм повлиять. И к тому же, есть вероятность, что проблема лишнего веса это заболевание.
5 млрд карточек вроде, а не запросов.
Но все равно непонятно что это за единица карточка/сутки.
Может на тот момент у них требования были 300.000, а сейчас выросли больше...
Вообщем никаких ответов, только предположения.
Это не для вас, и не для таких как вы =)
Понятно что и мне было бы интереснее прочитать про итераторы, про разные структуры, про лучшие практики, про генераторы...
Но это не означает, что повторение азов бессмысленно)
Не нужно восхвалять за перепечатывания, ровно как и не нужно принижать =)
Я и написал об этом, чтобы был мост между моим комментом и дальнейшим обсуждением. В дальнейшем используется терминология fsd.
Entities - это компоненты, которые используются для отображения, а не для взаимодействия.
Features - это компоненты действий.
Widgets - это полноценные компоненты.
Что чат, что уроки - полноценные компоненты, в которые достаточно передать только ид для дальнейшей полноценной работы, будут располагаться в widgets.
Конкретные задачи были описаны в комменте выше:
Про 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 библиотеку, сторы - не фичи, а именно надстройки над сторами для хранения, и т.д.)