Состоялся релиз Lerna 6!!! В статье собрано все, что вы должны знать о новом опыте, который предлагает Lerna!

Lerna продолжает развиваться. Если вы и так это знаете, то можете не читать дальше. Но многие все еще не слышали, что Lerna вернулась, не устарела и даже получает новые фичи. Мы из Nrwl являемся создателями Nx, и, учитывая нашу экспертизу в монорепозиториях, мы предложили взять на себя развитие Lerna, когда она была объявлена "мертвой" в апреле 2022 года.

Когда мы получили управление над Lerna начались настоящие американские горки. Мы запустили совершенно новый сайт, обновили документацию и сделали Lerna в 10 раз быстрее. И вот, Lerna 6 вышла!

Согласно статистике, в РФ работу меняют в среднем раз в 3,5 года, а в США — раз в 4,1 года. Но статистика — всего лишь цифры, в неё попадают и те, кто меняет работу каждые 3-6 месяцев, и те, кто остается с компанией по 10-15 лет. Если прямо сейчас вы уже занесли ручку над заявлением об увольнении, предлагаю подумать, подышать и еще раз проверить все причины своего решения. 

Я выделила несколько причин, которые могут привести к решению уволиться. На самом деле, их намного больше, но я постаралась перечислить основные.

Привет, Хабр! Меня зовут Рушана Каюмова, я — Lead HR в Экспресс 42. Эта статья посвящена скользкой и неприятной теме увольнения. Это только кажется, что уволиться — просто. На деле во всех историях, которые я слышала о смене работы, возникали какие-то шероховатости. Предлагаю пройтись по процедуре. Эта информация будет полезна всем, у кого есть работа, а также лидам и руководителям. Ведь каждый рано или поздно сталкивается с необходимостью уволиться самому или с увольнением сотрудника.

Недавно опять разгорелась дискуссия, как можно похудеть, работая в IT. Так вот, хороший (и научный) способ есть, и он на самом деле проще, чем можно было бы ожидать.

Конечно, если ничего не делать, то будешь только толстеть. Средний офисный сотрудник сегодня сидит больше 10 часов в день. Мы с вами, чувствую, ещё больше, особенно если на досуге играем, читаем Хабр или смотрим ютуб. Лично меня от компьютера вообще не оттащить. Хотя читал полно исследований, говорящих о больших проблемах со здоровьем, возникающих из-за малоподвижного образа жизни.

Например, было доказано, что независимо от уровня физической активности слишком много сидения увеличивает риск сердечных заболеваний, диабета, деменции и серьезных проблем со спиной. Более половины всех людей в мире сегодня уже страдают от этих проблем, и больше 80% людей в возрасте 60+.

Решение, конечно, простое — упражнения, в любой возможной форме. Но если вы такие как я, то тренироваться скучно и тяжело, правда? Большинство из нас ненавидят физкультуру. К тому же, на это нет лишнего времени. Бонусные часы каждый день магически не появятся.

Но похоже, есть способ ускорить обмен веществ в организме, даже сидя за ПК. И точно избежать проблем с метаболизмом и ожирением. Несколько недель назад вышла работа ученых под руководством Марка Гамильтона из Хьюстонского университета. Они разработали технику, позволяющую задействовать неожиданное свойство икроножных мышц, и делать для своего организма полноценную тренировку, не вставая со стула. Оказывается, похудеть, работая в IT, — это не так уж и сложно. Испытываю на себе, полёт нормальный. А какие у вас ноги будут прокачанные!

Микросервисная архитектура – одна из самых полезных архитектур в индустрии программного обеспечения. При правильном подходе она может помочь в создании лучших программных приложений. Из этой статьи вы узнаете, что такое микросервисная архитектура, какие шаблоны проектирования необходимы для ее реализации, а также почему стоит и почему не стоит использовать эту архитектуру для вашего нового программного обеспечения.

Можно ли с помощью GitHub анализировать работу, не заглядывая в монитор сотрудника — без скриншотов и тайм-трекеров?

Я Александр Кириллов, технический директор компании Evrone. Больше 20 лет я посвятил разработке. В этой статье поделюсь с вами опытом, который собрал за время работы с распределенными командами. Расскажу о том, как, не нарушая приватность разработчиков, следить за качеством работы на проектах и отслеживать нежелательные паттерны с помощью метрик в Jira и Git.

Если у вас есть компьютер и вы используете его по назначению, то скорее всего вы так или иначе работали с приложениями на Electron (даже если об этом не знали).

Меня зовут Сергей Володин, я руковожу командой разработки VK WorkMail. В этой статье я расскажу, как на основе Electron мы за две недели создали PoC кроссплатформенного настольного приложения Почты, что узнали о технологии и к каким выводам пришли.

Первое мое знакомство с Mobx началось с удивления. Я не понимал всю магию библиотеки и задавал себе вопрос: “А как это возможно?”. Кажется, в ней используются какие-то подкапотные возможности JS или Mobx вообще написан на другом языке. 

И вот, потратив 3 месяца в исходниках, я развеял для себя магию. Mobx все таки написан на JS и даже имеет множественные ограничения, которые нужно соблюдать, чтобы ваш браузер не взорвался.

В этой статье мы создадим свой Mobx с нуля, а так же свяжем его с React, через собственно написанный HOC observer. В конце у вас будет общее понимание реактивности, которое поможет в самостоятельном осмыслении не только Mobx, но и других реактивных библиотек и фреймворков.

Часто на собеседовании опытный разработчик может спросить у начинающего: «Что такое __proto__ и prototype, и чем они отличаются?». Обычно этот вопрос либо ставит в тупик, либо на него отвечают заученной мантрой из видео «50 вопросов на собеседовании»: « __proto__ — это ссылка на prototype, а prototype — это собственно свойство». И этот ответ правильный, только большинство недавно пришедших в профессию разработчиков не понимают, что это значит на самом деле. Причина проста — они не встречают в разработке ни __proto__, ни prototype, потому что современные стандарты JS прячут от него работу с этими свойствами за синтаксический сахар. Эта статья для таких, как я — разработчиков, которые столкнулись с JS в то время, когда никаких __proto__ и prototype на поверхности уже нет, а желание понять, как это устроено "под капотом" остается.

За последнее время в CSS появилось достаточно новых возможностей, которые позволяют нам создавать новые решения для старых задач. Мне захотелось рассказать вам о тех, которые работают в современных браузерах, и их можно использовать прямо сейчас.

Я подобрал, как мне кажется, наиболее распространенные задачи и покажу вам, как они решаются с помощью современного CSS. Надеюсь, вам будет интересно, и вы узнаете что-то новое. Так что не буду задерживаться, давайте начнем.

Представьте идеальный мир с бесконечными ресурсами, в котором можно сколько угодно линейно масштабироваться под нагрузку: просто доставлять серверы, диски, видеокарты, как только потребуется больше мощностей. Звучит хорошо? Только оказывается, что когда серверов 5 000 и дисков 100 000, то несколько из них обязательно находятся в состоянии maintenance или repair, куда их привели обстоятельства непреодолимой силы. И главная задача здесь — обеспечить доступность сервиса в условиях постоянных сбоев. 

В статье разберём, как построить отказоустойчивую платформу, с какими неочевидными corner cases может столкнуться сервис с UGC-контентом, а ещё — как жить в реальном, а не идеальном мире и оптимизировать железо. Чтобы раздавать 4 Тбит/с можно, конечно, использовать 400 серверов по 10 Гбит/с, но гораздо интереснее грамотно всё потюнить и выжать 100 Гбит/с с Java-сервера.  

Соглашения — важная часть процесса разработки. Они призваны снижать затраты и упрощать жизнь сотрудников. Проблема в том, что часто соглашения, наоборот, только всё усложняют, поскольку они толком не зафиксированы и передаются исключительно из уст в уста, как старые сказки. В процессе передачи они обрастают новыми подробностями, а прежние подробности упускаются. В итоге у каждого участника команды в голове свой набор соглашений, которые он периодически забывает.

Ещё хуже, когда соглашения начинают-таки фиксировать, но делают это как попало — и вы получаете свалку непонятно связанных между собой текстов, половина которых неактуальна.

В этой статье я расскажу, как фиксировать соглашения правильно, чтобы они приносили вам пользу. 

Думаю, многие знают изобретение Codex от OpenAI. Это мощная нейронная сеть, которая может делать любые операции с программным кодом. Она бесплатна, но доступна ограниченному кругу лиц.

Мне удалось получить доступ к сие чуду. Я, как любитель всего открытого, решил косвенно дать людям доступ к Codex, поэтому я разработал сервис - CodeTools. С помощью него можно перевести код с одного языка на другой, упростить код, задокументировать код, дополнить код и многое другое...

Перед нами часто возникает задача, сделать текст отзывчивым в зависимости от размера экрана устройства. Казалось бы, задача вполне тривиальна, и сходу можно назвать несколько вариантов её решения, не ломая голову, но всегда есть дополнительные условия, которые усложняют выполнение простых задач. В данной статье мы будем рассматривать решение небольшой задачи: как сделать максимально возможный размер шрифта динамического текста в его родительском контейнере. Или же, как впихнуть невпихуемое.

Если вы уже тестировали API с помощью Postman или какого-либо другого инструмента, никаких особых трудностей возникнуть не должно. Cypress — отличный инструмент для тестирования, который в том числе очень полезен при тестировании API. В этой статье я расскажу о том, как написать тест API в Cypress. 

Речь пойдёт про мощный инструмент, реализующий собой подход реактивного программирования и в разы упрощающий разработку — RxJS. В частности разберём один момент, про который нужно не забывать при использовании этой библиотеки, а именно — отписки.

Да, да, этот базовый момент может упускаться разработчиком, и это в свою очередь может привести к утечке памяти — об этом далее.

Привет, Хабр. Меня зовут Мария, я работаю в вебе с начала нулевых, то есть с засилья статичных HTML-страниц. С тех пор я освоила много новых технологий и прошла массу собеседований. Сегодня хочу поделиться опытом: что спрашивают у JS-джунов и какие тестовые дают при приёме на работу.

Module Federation — это подход, при котором можно разделить приложение на небольшие отдельные модули и в рантайме объединять в единое приложение. Это одно из немногих рабочих решений для разработки микрофронтендов. Почему оно лучше, чем остальные, какие еще решения для микрофронтендов существуют, что вообще такое микрофронтенды и зачем они нам нужны, расскажу в статье. В конце поделюсь полезными ссылками на статьи, видео и документацию, которые помогут углубиться в тематику Module Federation.

Так же будет немного практики. Настоятельно рекомендую самостоятельно опробовать технологию чтобы материал хорошо закрепился в памяти. Практика наше все!

Как социолог в IT, я регулярно провожу исследования среди тимлидов. И часто слышу от новоиспеченных лидов, что им была бы очень полезна подготовка к их новой роли. А более опытные для прокачки софт-скиллов хотят понятную систему инструментов. Подведя некоторые итоги, я составила топ-3 самых частых трудностей:

Подозреваю, что есть инструменты, чтобы делать мою работу лучше, но я о них не знаю и не очень понимаю, где их достать;

Нелегко применять софты: быть открытым, уверенным, проявлять эмпатию.

Тяжело даются one-on-one, фидбек и общение, особенно когда надо поговорить не про работу, а про что-то еще.

То есть многие просто не знают, что делать, когда становятся тимлидами: сначала им сложно и некомфортно, у них не получается или получается не то, а ожидания бизнеса и команды не очень понятны. А потом им непонятно, как можно те самые sotf skills развивать, если каждый one-on-one отнимает массу сил. 

Меня зовут Сандра Урядова, и сегодня я хочу рассказать, как на этом пути тимлиду может помочь его собственная уязвимость, в которой, как ни парадоксально, лежит сила быть человеком. Да, иногда это очень сложно сделать, но эта сила позволит вам не только выйти из стрессового состояния, но и создать благоприятный фон в команде — вы покажете другим, что так можно: быть человеком, а не машиной.