BEARlogin Dev

Там вот вопрос был, типа, а вот ты проверял, что ты рекламируешь... Как оказалось, Артем проверил, и даже купил занятия :)

Есть дофига всяких курсов по английскому языку, где обещают все и сразу, и туда имеет смысл идти, если учишься с нуля или низкого уровня, но мы как разрабы уже умеем читать (ведь умеем же да?), но когда доходит до разговора, максимум что можем выдавить - Ландан из зе капитал оф грейтбритан. Ко мне обратились ребята из онлайн-школы Authentic Pigeon, с просьбой рассказать о них. Они как раз специализируются на обучению разговору. Поэтому если у вас с этим проблемы, то заходите к ним в канал @authenticpigeon, у них много полезной инфы, а так же есть возможность заехать на индивидуальные занятия. Реклама. Моисеев Кирилл Владимирович. ERID: 2VtzqvFunZL

В общем, комрад в комментах пояснил, что такое поведение, это из-за "мягкого переноса" — shift + enter. Собственно, AI сделала список почему то с таким переносом, я его вставил, и такая мутотень произошла. В гугл доках такая же фигня. Но это не отменяет тот факт, что жира та еще всрань.

В общем, комрад в комментах пояснил, что такое поведение, это из-за "мягкого переноса" — shift + enter. Собственно, AI сделала список почему то с таким переносом, я его вставил, и такая мутотень произошла. В гугл доках такая же фигня. Но это не отменяет тот факт, что жира та еще всрань.

В общем, комрад в комментах пояснил, что

Jira сломана от рождения, как этим куском говна вообще можно пользоваться? #хуевыйux BEARlogin dev — подпишись!

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

Что такое 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 — подпишись!

Как найти работу фронтендеру в 2к25 году 1. Изучаешь Ember.js https://emberjs.com/ 2. Добавляешь навык на LinkedIn 3. Получаешь оффер x2 к своей текущей з\п React разработчика 4. PROFIT P.S. основано на реальных событиях... BEARlogin dev — подпишись! #frontend #js

Как найти работу фронтендеру в 2к25 году 1. Изучаешь Ember.js https://emberjs.com/ 2. Добавляешь навык на LinkedIn 3. Получаешь оффер x2 к своей текущей з\п React разработчика 4. PROFIT P.S. основано на реальных событиях... BEARlogin dev — подпишись! #frontend #js

Этот 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-найм сломался, несите следующий! У нас большая проблема. Быстрый рост зарплат в 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 #найм

Ну лан, ок, вот да

Кароче, само видео еще смешней, чем его описание https://www.youtube.com/watch?v=x6x2h4kWx2c "Это абстракция"(с)

Принципы ООП в React с хуками, вот, да, в функциональном программировании(лан пох, не совсем в функциональном), принципы ООП, да. (Это скриншот из канала, не жмите на него, не видео)

Подписчик попросил разместить вакансию. Вакансия: https://hh.ru/vacancy/116796914?from=share_android Как я понял, надо пилить плагины под Jetbrains IDEхи Попросил для вас прямой контакт HR - вот он @max_toky Что это значит? Значит можете резюмехи свои кидать прям ему. (и не только на джаву :)) P.S. Только не волки, волки идут сразу нахуй.

Так, давайте покажу пример из книги, возможно я как то не так подал его, когда переводил контекст в js окружение, более привычное Книга — Влад Хононов "Изучаем DDD"

Мышление архитектора и разработчика По поводу вчерашней задачки — интересно, сколько негативной реакции она вызвала. Я порефлексировал на эту тему и понял, что мышление архитектора и разработчика сильно отличается. Разработчик начинает видеть паттерн только когда сталкивается с проблемой напрямую. Но, например, в случае с логированием можно вообще никогда не столкнуться с такой проблемой — и это нормально. Я бы тоже не обратил на это внимание, если бы не читал книги и не проходил/проводил курсы по архитектуре. Архитектор учится видеть паттерны, предугадывать потенциальные проблемы, влияющие на качества системы. Но при этом он может не знать и не замечать специфических сложностей имплементации с точки зрения конкретного языка или фреймворка. Эта разница в подходах и приводит к недопониманию. Разработчик оценивает проблему, исходя из своего опыта и практического столкновения с ней, а архитектор — через призму рисков и долгосрочных последствий. Часто это выглядит как «надуманная» проблема, потому что на уровне кода её ещё нет, но на уровне системы последствия могут оказаться критичными. В итоге хороший архитектор не просто видит потенциальные узкие места, но и умеет донести их значимость до команды. А хороший разработчик, в свою очередь, не просто решает текущие задачи, а способен взглянуть на систему шире, задавая правильные вопросы. BEARlogin dev — подпишись! #рефлексия #архитектура

Гарантированная доставка и очередность событий. Конечно круто что у охранной системы моей машины гарантированная доставка пуш уведомлений. Но не очень круто получать уведомление, что автомобиль снят с охраны «сейчас», после того, как ты его закрыл и ушел на километр…

Как мозг дорисовывает контекст Эксперимент оказался интересным — как только мозг видит код, он сразу начинает достраивать отсутствующий контекст. Кто-то решил, что это контроллер и что он блокирует ответ пользователю. Хотя этот метод мог быть вызван где угодно: — Планировщиком — Консюмером события — Обработчиком джобы — что угодно Кто то искал ошибки в коде :) Но суть не в этом. Настоящая проблема — отсутствие транзакции ⚠️ Если логгер падает, система остаётся в несогласованном состоянии: 1. Данные обновились 2. Логирование не произошло Что делать? Используем транзакцию Если и логгер, и данные пишутся в БД, оборачиваем всё в транзакцию:

...
// это просто пример, показать принцип, воспринимайте как псевдоязык
async function updateUser(id, data) {
    const transaction = await this.db.transaction(); // Начинаем транзакцию
    try {
        await this.user.update(id, data, { transaction });
        await this.logger.log('User updated', data, { transaction });
        await transaction.commit(); // Подтверждаем изменения
    } catch (error) {
        await this.logger.error('User update failed', data);
        await transaction.rollback(); // Откатываем всё, если что-то пошло не так
        throw error;
    }
}
...

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