Мышление архитектора и разработчика
По поводу вчерашней задачки — интересно, сколько негативной реакции она вызвала. Я порефлексировал на эту тему и понял, что мышление архитектора и разработчика сильно отличается. Разработчик начинает видеть паттерн только когда сталкивается с проблемой напрямую. Но, например, в случае с логированием можно вообще никогда не столкнуться с такой проблемой — и это нормально.
Я бы тоже не обратил на это внимание, если бы не читал книги и не проходил/проводил курсы по архитектуре. Архитектор учится видеть паттерны, предугадывать потенциальные проблемы, влияющие на качества системы. Но при этом он может не знать и не замечать специфических сложностей имплементации с точки зрения конкретного языка или фреймворка.
Эта разница в подходах и приводит к недопониманию. Разработчик оценивает проблему, исходя из своего опыта и практического столкновения с ней, а архитектор — через призму рисков и долгосрочных последствий. Часто это выглядит как «надуманная» проблема, потому что на уровне кода её ещё нет, но на уровне системы последствия могут оказаться критичными.
В итоге хороший архитектор не просто видит потенциальные узкие места, но и умеет донести их значимость до команды. А хороший разработчик, в свою очередь, не просто решает текущие задачи, а способен взглянуть на систему шире, задавая правильные вопросы.
BEARlogin dev — подпишись!
#рефлексия #архитектура
По поводу вчерашней задачки — интересно, сколько негативной реакции она вызвала. Я порефлексировал на эту тему и понял, что мышление архитектора и разработчика сильно отличается. Разработчик начинает видеть паттерн только когда сталкивается с проблемой напрямую. Но, например, в случае с логированием можно вообще никогда не столкнуться с такой проблемой — и это нормально.
Я бы тоже не обратил на это внимание, если бы не читал книги и не проходил/проводил курсы по архитектуре. Архитектор учится видеть паттерны, предугадывать потенциальные проблемы, влияющие на качества системы. Но при этом он может не знать и не замечать специфических сложностей имплементации с точки зрения конкретного языка или фреймворка.
Эта разница в подходах и приводит к недопониманию. Разработчик оценивает проблему, исходя из своего опыта и практического столкновения с ней, а архитектор — через призму рисков и долгосрочных последствий. Часто это выглядит как «надуманная» проблема, потому что на уровне кода её ещё нет, но на уровне системы последствия могут оказаться критичными.
В итоге хороший архитектор не просто видит потенциальные узкие места, но и умеет донести их значимость до команды. А хороший разработчик, в свою очередь, не просто решает текущие задачи, а способен взглянуть на систему шире, задавая правильные вопросы.
BEARlogin dev — подпишись!
#рефлексия #архитектура
👍6👎5🔥3🗿3💯1
Подписчик попросил разместить вакансию.
Вакансия:
https://hh.ru/vacancy/116796914?from=share_android
Как я понял, надо пилить плагины под Jetbrains IDEхи
Попросил для вас прямой контакт HR - вот он @max_toky
Что это значит? Значит можете резюмехи свои кидать прям ему. (и не только на джаву :))
P.S. Только не волки, волки идут сразу нахуй.
Вакансия:
https://hh.ru/vacancy/116796914?from=share_android
Как я понял, надо пилить плагины под Jetbrains IDEхи
Попросил для вас прямой контакт HR - вот он @max_toky
Что это значит? Значит можете резюмехи свои кидать прям ему. (и не только на джаву :))
P.S. Только не волки, волки идут сразу нахуй.
hh.ru
Вакансия Java разработчик в Москве, работа в компании Т1 Иннотех (вакансия в архиве c 6 марта 2025)
Зарплата: не указана. Москва. Требуемый опыт: 3–6 лет. Полная. Дата публикации: 05.02.2025.
💯3🔥2
Кароче, само видео еще смешней, чем его описание https://www.youtube.com/watch?v=x6x2h4kWx2c
"Это абстракция"(с)
"Это абстракция"(с)
YouTube
Принципы ООП в React.
В этом видео разберем основные принципы ООП — инкапсуляцию, наследование, полиморфизм и абстракцию — и покажем, как они работают в React. Узнаем, что такое Render Props, Component Injection, композиция и декомпозиция, и применим их в функциональных компонентах…
😁2😱1
Этот IT-найм сломался, несите следующий!
У нас большая проблема. Быстрый рост зарплат в IT, который явно не соответствует уровню других профессий, привёл к буму курсов, обещающих за пару месяцев подготовить джуна, а иногда даже миддла. Были даже программы с гарантированным трудоустройством.
Но рынок настолько насытился новичками, которые по факту не джуны, а максимум стажёры, неспособные приносить пользу сразу, а только после длительного обучения и адаптации внутри компании, что HR начали резко ужесточать фильтры. Компании закрыли институт найма молодых специалистов и повысили требования. И всё это усугубилось тем, что денег во всем мире стало меньше – мы увидели масштабные сокращения IT-специалистов. На рынок выплеснулось столько крутых специалистов, что даже небольшие компании теперь могут позволить себе нанимать синьоров и миддлов, а джуны и, тем более, стажёры стали практически не нужны.
В итоге новички поняли, что им не рады, и возник спрос на менторов и сообщества, которые помогают выдавать себя за опытных специалистов. За деньги стали подделывать резюме, накручивать опыт, готовить к прохождению собеседований, а в некоторых случаях даже помогать кандидатам во время интервью через голосовые подсказки. При этом после трудоустройства такие специалисты не оказывают поддержки, а система ужесточает проверки ещё больше – тысячи резюме сразу отправляются в мусор. Реальному честному трудяге пробиться стало практически невозможно.
Пострадали даже миддл+ и синьоры, потому что теперь их тоже подозревают, а их резюме тонут в потоке заявок от новичков, выдающих себя за опытных специалистов.
Это как играть в MMORPG, честно выполняя квесты, повышая уровень и зарабатывая золото, когда вокруг все покупают за реальные деньги «паровозы» – когда высокоуровневый персонаж помогает проходить низкоуровневые подземелья, снаряжение и игровую валюту. И вот что происходит: после того как новичок выполнил 1001-е тестовое задание, которое осталось без ответа, он тупо идёт к таким дельцам и проходит этот квест.
Кто виноват? Что делать? Как сломать систему?
Если коротко, никак не сломать. Рынок уже порешал. HR просто ставят фильтры 3+ года опыта, автоматические ассесменты, потому что иначе невозможно обработать 1000 резюме, из которых 90% с накрученным опытом и отправлены автоматически. Через ATS-системы просто не пройти
Выбор небольшой: либо читерить, либо менять стратегию.
1. Заходить не через HR – ищите CTO, разрабов, менеджеров в LinkedIn, Telegram, Discord комьюнити.
2. Участвовать в хакатонах, OpenSource (Awesome GitHub Projects, Open Source Friday, Good First Issues).
3. Pet-проекты, но осмысленные. Автоматизируй что-то полезное: бот, сервис, парсер, мониторинг, дашборд. Заведи портфолио, где проект задеплоен и им можно пользоваться.
4. Фриланс и волонтёрство. Делать не ради денег, а ради опыта. Стартапы, малый бизнес, НКО – им нужны сайты, боты, CRM, API. Варианты поиска: фриланс-биржи, комьюнити фаундеров.
На одной чаше весов — быстрое выгорание, синдром реального самозванца, страх, что тайное станет явным, а на другой — долгий путь, требующий терпения, но дающий уверенность в своих знаниях и реальную ценность как специалиста.
BEARlogin dev — подпишись!
#hr #найм
У нас большая проблема. Быстрый рост зарплат в IT, который явно не соответствует уровню других профессий, привёл к буму курсов, обещающих за пару месяцев подготовить джуна, а иногда даже миддла. Были даже программы с гарантированным трудоустройством.
Но рынок настолько насытился новичками, которые по факту не джуны, а максимум стажёры, неспособные приносить пользу сразу, а только после длительного обучения и адаптации внутри компании, что HR начали резко ужесточать фильтры. Компании закрыли институт найма молодых специалистов и повысили требования. И всё это усугубилось тем, что денег во всем мире стало меньше – мы увидели масштабные сокращения IT-специалистов. На рынок выплеснулось столько крутых специалистов, что даже небольшие компании теперь могут позволить себе нанимать синьоров и миддлов, а джуны и, тем более, стажёры стали практически не нужны.
В итоге новички поняли, что им не рады, и возник спрос на менторов и сообщества, которые помогают выдавать себя за опытных специалистов. За деньги стали подделывать резюме, накручивать опыт, готовить к прохождению собеседований, а в некоторых случаях даже помогать кандидатам во время интервью через голосовые подсказки. При этом после трудоустройства такие специалисты не оказывают поддержки, а система ужесточает проверки ещё больше – тысячи резюме сразу отправляются в мусор. Реальному честному трудяге пробиться стало практически невозможно.
Пострадали даже миддл+ и синьоры, потому что теперь их тоже подозревают, а их резюме тонут в потоке заявок от новичков, выдающих себя за опытных специалистов.
Это как играть в MMORPG, честно выполняя квесты, повышая уровень и зарабатывая золото, когда вокруг все покупают за реальные деньги «паровозы» – когда высокоуровневый персонаж помогает проходить низкоуровневые подземелья, снаряжение и игровую валюту. И вот что происходит: после того как новичок выполнил 1001-е тестовое задание, которое осталось без ответа, он тупо идёт к таким дельцам и проходит этот квест.
Кто виноват? Что делать? Как сломать систему?
Если коротко, никак не сломать. Рынок уже порешал. HR просто ставят фильтры 3+ года опыта, автоматические ассесменты, потому что иначе невозможно обработать 1000 резюме, из которых 90% с накрученным опытом и отправлены автоматически. Через ATS-системы просто не пройти
Выбор небольшой: либо читерить, либо менять стратегию.
1. Заходить не через HR – ищите CTO, разрабов, менеджеров в LinkedIn, Telegram, Discord комьюнити.
2. Участвовать в хакатонах, OpenSource (Awesome GitHub Projects, Open Source Friday, Good First Issues).
3. Pet-проекты, но осмысленные. Автоматизируй что-то полезное: бот, сервис, парсер, мониторинг, дашборд. Заведи портфолио, где проект задеплоен и им можно пользоваться.
4. Фриланс и волонтёрство. Делать не ради денег, а ради опыта. Стартапы, малый бизнес, НКО – им нужны сайты, боты, CRM, API. Варианты поиска: фриланс-биржи, комьюнити фаундеров.
На одной чаше весов — быстрое выгорание, синдром реального самозванца, страх, что тайное станет явным, а на другой — долгий путь, требующий терпения, но дающий уверенность в своих знаниях и реальную ценность как специалиста.
BEARlogin dev — подпишись!
#hr #найм
🔥13👍5💯3
Как найти работу фронтендеру в 2к25 году
1. Изучаешь Ember.js https://emberjs.com/
2. Добавляешь навык на LinkedIn
3. Получаешь оффер x2 к своей текущей з\п React разработчика
4. PROFIT
P.S. основано на реальных событиях...
BEARlogin dev — подпишись!
#frontend #js
1. Изучаешь Ember.js https://emberjs.com/
2. Добавляешь навык на LinkedIn
3. Получаешь оффер x2 к своей текущей з\п React разработчика
4. PROFIT
P.S. основано на реальных событиях...
BEARlogin dev — подпишись!
#frontend #js
🤣6🔥3👍2🗿2
Что такое DevOps
Перефразируя классику, DevOps — это человек и пароход.
Изначально DevOps — это процесс, а не роль. Суть в том, что "кто разрабатывает, тот и деплоит".
Окей, вроде логично: написал сервис, завернул в Docker, задеплоил в Kubernetes или куда-нибудь ещё. Но если разраб сам деплоит, то кто тогда DevOps и что он делает?
А вот тут важно понимать: DevOps — это не просто инженер, а создатель процессов. Его задача — не деплоить код вручную, а сделать так, чтобы разработчик мог деплоить сам, быстро и без боли.
Идеально: поднять DevOps-платформу, где всё — от инструментов разработки и выделения ресурсов до мониторинга и CI/CD — автоматизировано.
Минимально:
- Поднять\настроить GitLab / GitHub Actions / Jenkins для CI/CD.
- Развернуть\купить Kubernetes (например, с FluxCD для GitOps).
- Настроить мониторинг и логи: Grafana, Prometheus, Loki, OpenTelemetry.
- Сделать инфраструктуру предсказуемой и самодостаточной, чтобы DevOps-инженер не был просто "тем, кто деплоит руками".
Так что DevOps — это не человек, который нажимает кнопки, а тот, кто создаёт среду, в которой разработчики могут деплоить и сопровождать код без лишних сложностей.
То есть, если ты просишь задеплоить свой сервис DevOps специалиста, то у вас нет DevOps, а есть админ со скриптами.
#devops
BEARlogin dev — подпишись!
Перефразируя классику, DevOps — это человек и пароход.
Изначально DevOps — это процесс, а не роль. Суть в том, что "кто разрабатывает, тот и деплоит".
Окей, вроде логично: написал сервис, завернул в Docker, задеплоил в Kubernetes или куда-нибудь ещё. Но если разраб сам деплоит, то кто тогда DevOps и что он делает?
А вот тут важно понимать: DevOps — это не просто инженер, а создатель процессов. Его задача — не деплоить код вручную, а сделать так, чтобы разработчик мог деплоить сам, быстро и без боли.
Идеально: поднять DevOps-платформу, где всё — от инструментов разработки и выделения ресурсов до мониторинга и CI/CD — автоматизировано.
Минимально:
- Поднять\настроить GitLab / GitHub Actions / Jenkins для CI/CD.
- Развернуть\купить Kubernetes (например, с FluxCD для GitOps).
- Настроить мониторинг и логи: Grafana, Prometheus, Loki, OpenTelemetry.
- Сделать инфраструктуру предсказуемой и самодостаточной, чтобы DevOps-инженер не был просто "тем, кто деплоит руками".
Так что DevOps — это не человек, который нажимает кнопки, а тот, кто создаёт среду, в которой разработчики могут деплоить и сопровождать код без лишних сложностей.
То есть, если ты просишь задеплоить свой сервис DevOps специалиста, то у вас нет DevOps, а есть админ со скриптами.
#devops
BEARlogin dev — подпишись!
👍8🔥1
Scrum-стройка - АКТ 1
Сцена 1: Утро на стройке
Камера медленно показывает стройку. Недостроенный дом третий год «вот-вот» сдаётся. На фоне — кран, который никто не видел в движении с прошлого сезона. Несколько рабочих в касках и резиновых сапогах пьют чай из алюминиевых кружек. Один задумчиво ковыряет гвоздём кусок хлеба.
Прораб (в новом жилете, с планшетом и в галстуке):
— Так, срочно собираемся! Я тут на курсах был. Нам теперь работать по Scrum!
Рабочий №1 (переставая размешивать чай):
— Это кто? Новый прораб?
Прораб (воодушевлённо):
— Это метод такой погрессивный! Теперь у нас спринты, стендапы и эти, как их (судорожно листает книгу "Скрам для чайников") бэкилоги!
Рабочий №2 (щурится):
— Спринт? Это как футбол? Мы бегать будем?
Прораб (вздыхает):
— Нет, брат, это когда мы короткими этапами работаем. Каждые две недели будем что-то сдавать.
Рабочий №3:
— А деньги тоже каждые две недели будем получать?
Прораб (недовольно поправляет жилет):
— Давайте без провокаций, главное — начать!
Сцена 2: Первый стендап
Рабочие стоят в кругу, как на зарядке в пионерском лагере. Прораб деловито держит планшет и объясняет новый процесс.
Прораб:
— Теперь каждое утро будем делать «стендап». Отвечаем на три вопроса: что сделал вчера, что делаешь сегодня и какие есть проблемы.
Рабочий №1:
— Вчера кирпичи носил. Сегодня носил кирпичи. Проблема — кирпич тяжёлый.
Рабочий №2:
— Вчера мешал бетон. Сегодня мешать бетон. Проблема — бетономешалка не работает.
Рабочий №3:
— Вчера красил забор. Сегодня буду красить забор. Проблема — краска нет.
Прораб (вытирая пот со лба):
— Ну хоть честно. Всё, разбежались!
Сцена 3: Планирование спринта
Рабочие сидят на перевёрнутых вёдрах. Прораб рисует что-то на стене куском кирпича.
Прораб:
— Вот наш бэклог: построить стену, залить фундамент, поставить крышу. Давайте оценим, сколько это займёт.
Рабочий №1:
— Стена — два дня.
Рабочий №2:
— Фундамент — неделя.
Рабочий №3:
— Крыша... Если материалы будут, три дня.
Прораб (радостно):
— Отлично! Спринт на две недели! Погнали!
Через две недели: стена кривая, фундамент никто не заливал, а крышу в смету не внесли на этапе проектирования.
Сцена 4: Ретроспектива
Рабочие снова сидят на перевёрнутых вёдрах, пьют чай. Прораб пытается провести ретроспективу.
Прораб:
— Итак, что у нас прошло хорошо?
Рабочий №1:
— Чай вкусный был.
Прораб (пауза):
— А что можно улучшить?
Рабочий №2:
— Кирпичи сделать легче.
Прораб (прикрывает лицо руками):
— Ладно... Что мы сделаем по-другому в следующем спринте?
Рабочий №4: (отхлёбывая чай, задумчиво):
— Работать без Scrum... но с зарплатой!
Все одобрительно кивают и чокаются кружками чая.
—
Сцена 5: Финал
Камера показывает стройку. Рабочие снова пьют чай, лениво переговариваются. Прораб сидит в стороне, хмуро листает книгу «Scrum для чайников».
Прораб (читающий вслух):
— «Ключевая роль в Scrum — Scrum-мастер...»
Прораб медленно поднимает глаза, его лицо озаряет надежда.
Прораб (воодушевлённо, в камеру):
— Так вот в чём проблема! Нам нужен Scrum-мастер!
Камера медленно отъезжает, показывая табличку: «Сдача в 2021 году»
Продолжение следует...
BEARlogin dev — подпишись!
#юмор #scrum
Сцена 1: Утро на стройке
Камера медленно показывает стройку. Недостроенный дом третий год «вот-вот» сдаётся. На фоне — кран, который никто не видел в движении с прошлого сезона. Несколько рабочих в касках и резиновых сапогах пьют чай из алюминиевых кружек. Один задумчиво ковыряет гвоздём кусок хлеба.
Прораб (в новом жилете, с планшетом и в галстуке):
— Так, срочно собираемся! Я тут на курсах был. Нам теперь работать по Scrum!
Рабочий №1 (переставая размешивать чай):
— Это кто? Новый прораб?
Прораб (воодушевлённо):
— Это метод такой погрессивный! Теперь у нас спринты, стендапы и эти, как их (судорожно листает книгу "Скрам для чайников") бэкилоги!
Рабочий №2 (щурится):
— Спринт? Это как футбол? Мы бегать будем?
Прораб (вздыхает):
— Нет, брат, это когда мы короткими этапами работаем. Каждые две недели будем что-то сдавать.
Рабочий №3:
— А деньги тоже каждые две недели будем получать?
Прораб (недовольно поправляет жилет):
— Давайте без провокаций, главное — начать!
Сцена 2: Первый стендап
Рабочие стоят в кругу, как на зарядке в пионерском лагере. Прораб деловито держит планшет и объясняет новый процесс.
Прораб:
— Теперь каждое утро будем делать «стендап». Отвечаем на три вопроса: что сделал вчера, что делаешь сегодня и какие есть проблемы.
Рабочий №1:
— Вчера кирпичи носил. Сегодня носил кирпичи. Проблема — кирпич тяжёлый.
Рабочий №2:
— Вчера мешал бетон. Сегодня мешать бетон. Проблема — бетономешалка не работает.
Рабочий №3:
— Вчера красил забор. Сегодня буду красить забор. Проблема — краска нет.
Прораб (вытирая пот со лба):
— Ну хоть честно. Всё, разбежались!
Сцена 3: Планирование спринта
Рабочие сидят на перевёрнутых вёдрах. Прораб рисует что-то на стене куском кирпича.
Прораб:
— Вот наш бэклог: построить стену, залить фундамент, поставить крышу. Давайте оценим, сколько это займёт.
Рабочий №1:
— Стена — два дня.
Рабочий №2:
— Фундамент — неделя.
Рабочий №3:
— Крыша... Если материалы будут, три дня.
Прораб (радостно):
— Отлично! Спринт на две недели! Погнали!
Через две недели: стена кривая, фундамент никто не заливал, а крышу в смету не внесли на этапе проектирования.
Сцена 4: Ретроспектива
Рабочие снова сидят на перевёрнутых вёдрах, пьют чай. Прораб пытается провести ретроспективу.
Прораб:
— Итак, что у нас прошло хорошо?
Рабочий №1:
— Чай вкусный был.
Прораб (пауза):
— А что можно улучшить?
Рабочий №2:
— Кирпичи сделать легче.
Прораб (прикрывает лицо руками):
— Ладно... Что мы сделаем по-другому в следующем спринте?
Рабочий №4: (отхлёбывая чай, задумчиво):
— Работать без Scrum... но с зарплатой!
Все одобрительно кивают и чокаются кружками чая.
—
Сцена 5: Финал
Камера показывает стройку. Рабочие снова пьют чай, лениво переговариваются. Прораб сидит в стороне, хмуро листает книгу «Scrum для чайников».
Прораб (читающий вслух):
— «Ключевая роль в Scrum — Scrum-мастер...»
Прораб медленно поднимает глаза, его лицо озаряет надежда.
Прораб (воодушевлённо, в камеру):
— Так вот в чём проблема! Нам нужен Scrum-мастер!
Камера медленно отъезжает, показывая табличку: «Сдача в 2021 году»
Продолжение следует...
BEARlogin dev — подпишись!
#юмор #scrum
🤣8🔥2😁2😢1
This media is not supported in your browser
VIEW IN TELEGRAM
Jira сломана от рождения, как этим куском говна вообще можно пользоваться?
Ну то есть даже обоссаный котами блокнот лучше и функциональней, чем Jira.
#хуевыйux
BEARlogin dev — подпишись!
Ну то есть даже обоссаный котами блокнот лучше и функциональней, чем Jira.
#хуевыйux
BEARlogin dev — подпишись!
👍11😁6💯3😢1
В общем, комрад в комментах пояснил, что такое поведение, это из-за "мягкого переноса" — shift + enter. Собственно, AI сделала список почему то с таким переносом, я его вставил, и такая мутотень произошла. В гугл доках такая же фигня. Но это не отменяет тот факт, что жира та еще всрань по куче других причин.
👍5😁4
Видео резюме
Проблематика: в кучах резюме очень сложно сейчас выделяться, особенно в текущих условиях, когда резюме генерируются AI и т.д.
Решение - видео резюме.
Вот пример такого резюме, созданного в нашем продукте Klipovich https://designer.klipovich.com/.
Результаты
- Конверсия в просмотр - 96%
- Конверсия в переход на следующий шаг - 88.7%
- Конверсия в собеседование 11,7%.
Собсно, что по теме, мы сейчас проверяем данную гипотезу, и ищем людей, кто сейчас ищет работу, но не может найти, и не получает приглашения. Наша гипотеза, что создание такого интерактивого видео-резюме, позволит увеличить шансы на приглашение на собеседование. Если кто хочет, то напишите мне @bearlogin, я расскажу что и как сделать.
Проблематика: в кучах резюме очень сложно сейчас выделяться, особенно в текущих условиях, когда резюме генерируются AI и т.д.
Решение - видео резюме.
Вот пример такого резюме, созданного в нашем продукте Klipovich https://designer.klipovich.com/.
Результаты
- Конверсия в просмотр - 96%
- Конверсия в переход на следующий шаг - 88.7%
- Конверсия в собеседование 11,7%.
Собсно, что по теме, мы сейчас проверяем данную гипотезу, и ищем людей, кто сейчас ищет работу, но не может найти, и не получает приглашения. Наша гипотеза, что создание такого интерактивого видео-резюме, позволит увеличить шансы на приглашение на собеседование. Если кто хочет, то напишите мне @bearlogin, я расскажу что и как сделать.
👍6🔥3🗿1
А вы знали, что функция, возвращаемая из useEffect вызывается не только про unmount, но и при любом обновлении, то есть перед следующим вызовом эффекта?
Anonymous Poll
57%
Конечно, знал, с молоком матери впитал
19%
Ничосе, не знал,, думал только при анмаунте
24%
Кто здесь??
👏3
BEARlogin
А вы знали, что функция, возвращаемая из useEffect вызывается не только про unmount, но и при любом обновлении, то есть перед следующим вызовом эффекта?
Спасибо вам, я думал что я только один такой долбоеб...
😁6✍5
Артем с моей подачи запилил пост-задачку) Которую мы обсуждали на сегодняшнем курсе, с подачи комрада. Ответ не интуитивно понятный, викторина тут https://news.1rj.ru/str/artalog/1587
👍3
Знаете, у Артема есть какие то хейтеры в канале, которые по всем его каналам таскаются и лепят говняшки, дизлайки. ДАЖЕ БЛЯТЬ В КАНАЛ С ФОТОГРАФИЯМИ НА ПЛЕНКУ sic! У меня вопрос, вот чел, который поставил дизлайк, ты тот самый ебанат, оттудова?
Слуште, а может это боты?
Блин, @artalar, забери уже своих хейтеров, они за мной прибежали
Слуште, а может это боты?
Блин, @artalar, забери уже своих хейтеров, они за мной прибежали
👎15😁8🤣7😨1🗿1
Msw автомоки
Такая вот кароче либа https://github.com/zoubingwu/msw-auto-mock, позволяет генерить моки\хендлеры на основе openapi спецификации
Бахаешь команду
И больше не надо руками пилить хендлеры
#msw #mocks #testing
Такая вот кароче либа https://github.com/zoubingwu/msw-auto-mock, позволяет генерить моки\хендлеры на основе openapi спецификации
Бахаешь команду
npx msw-auto-mock https://petstore.swagger.io/v2/swagger.json -o ./mock
И больше не надо руками пилить хендлеры
#msw #mocks #testing
GitHub
GitHub - zoubingwu/msw-auto-mock: A cli tool to generate random mock data from OpenAPI definition for msw.
A cli tool to generate random mock data from OpenAPI definition for msw. - zoubingwu/msw-auto-mock
🔥12👍1👎1
Как подключить @tabler/icons-react к React на Vite
1. Подключаешь значит такой @tabler/icons-react к React на Vite
2. Немного погодя замечаешь что чот стало все тормозить
3. Открываешь devtoools наблюдаешь over 100500 запросов на react компоненты @tabler/icons-react
4. WTF?!!!!
5. Находишь на reddit решение https://www.reddit.com/r/reactjs/comments/1g3tsiy/trouble_with_vite_tablericons_5600_requests/
6. Слава Reddit!
#react #vite #tablericons #приколы
1. Подключаешь значит такой @tabler/icons-react к React на Vite
2. Немного погодя замечаешь что чот стало все тормозить
3. Открываешь devtoools наблюдаешь over 100500 запросов на react компоненты @tabler/icons-react
4. WTF?!!!!
5. Находишь на reddit решение https://www.reddit.com/r/reactjs/comments/1g3tsiy/trouble_with_vite_tablericons_5600_requests/
6. Слава Reddit!
#react #vite #tablericons #приколы
👍5😁4😨2