Может ли в 2024 году фронтенд-разработчик не тратить время сперва на изучение макета, а затем на его реализацию в коде, в условиях быстро меняющихся требований бизнес-задач? Да, если использовать готовую дизайн-систему. 

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

Ранее мы рассказали об общем процессе создания и внедрения нашей дизайн-системы. Сегодня углубимся в технические подробности — поэтапно рассмотрим, что в ходе разработки происходило под капотом. 

Привет, Хабр! Я Артем, тимлид продуктовой команды. Я управляю кросс-функциональной командой, проектирую архитектуру и отвечаю за интеграции корпоративного приложения. 

Сегодня расскажу, как мы выбирали архитектуру, чтобы быстро релизить, несмотря ни на что. Вы узнаете, как красиво интегрировать разные legacy-бэкенды без толпы разработчиков на проекте, и как продолжать доставлять важный функционал до пользователей, даже если вас удаляют из сторов. 

Обсудим плюсы и минусы нативной и кросс-платформенной разработки и подробно разберём WebView, его преимущества и подводные камни.

• Настроить MinIO очень быстро.
• Настроить MinIO чуть менее быстро, но значительно качественней.
• Использовать его в качестве Archive Tier для масштабируемого репозитория Veeam SOBR.

Эту полу-шуточную теорию о проектном управлении я излагал коллегам по ИТ цеху лет 15 назад, и тогда же неоднократно слышал советы загрузить этот текст на Хабр, но руки не дошли. На днях, разгребая старые файлы наткнулся на свои записи и решил все таки поделиться ими с Вами. Частое употребление ключевого слова к сожалению, неизбежно и не отделимо для целостности этого текста, прошу принимать или нет 'as is'. Итак...

Каждая карьера развивается от Жопы к Жопе, и никак иначе. Хочешь повышения - ищи Жопу и принимай, как говорят в Америке, "challenge". Если Вам предлагают возглавить новый проект, либо занять какую то должность, да что угодно - знайте, там Вас ждет Жопа. Иначе не предложили бы, а сами бы справились. Равно как и если Вы ожидаете избавиться от надоевшей Вам сейчас деятельности, надеясь вырваться из "этого ада" и заняться "чем то новеньким" - будьте готовы встретиться с Большой Жопой.

Всем привет! Меня зовут Айрат, я frontend-разработчик IT-компании SimbirSoft. Поговорим о такой теме, как адаптивная верстка. 

ДИСКЛЕЙМЕР: адаптив для сайта как явление на языке мемов уже смело можно назвать «баяном», впервые в России он появился в 2012 году (10 лет назад, Карл!). Даже React – самая популярная на данный момент библиотека для UI-разработки вышла только год спустя. И, наверное, вы подумали: «Да что тут читать? Даже у сайта булочной есть адаптив под мобильные устройства». Справедливое замечание... Мы тоже так думали, но не тут-то было. Представьте наше удивление, когда за последние полгода чуть ли не каждый второй клиент обязательным требованием выставляет наличие адаптивной верстки для сайта. Удивляет нас это потому, что адаптив – опция «из коробки» для каждого нашего проекта, на которой мы даже не акцентируем внимание. Всем же понятно, что он должен быть. Оказывается, нет…

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

Всем привет! Если вы считаете Storybook лишним инструментом, эта статья для вас. Раньше я и сам мог присоединиться к такому мнению, но попробовал Storybook в деле, когда участвовал в разработке сервиса рассрочки для одного из крупнейших маркетплейсов. Разработкой этого проекта занимались две команды, состоящие из 15 человек.

Меня зовут Александр, я frontend-разработчик в Simbirsoft. Хочу поделиться, как этот инструмент может сократить время на разработку и тестирование, улучшить качество конечного продукта, а также сэкономить бюджет на больших проектах.

Советую к прочтению фронтенд-разработчикам и тимлидам, которые хотят упростить процесс тестирования и отладки компонентов интерфейса веб-приложений. Также материал может помочь менеджерам проектов и владельцам бизнеса в поиске новых подходов для ускорения и оптимизации процесса разработки. И даже если вы новичок во frontend-разработке и хотите узнать о новых инструментах и технологиях в этой области — welcome.

Мы рассмотрим такие возможности, как создание документации, тестирование, тестирование доступности, работу с моками, аддоны для имитации API и контекста. Я поделюсь, какие проектные задачи мне удалось решить, и чем может быть полезен Storybook для вас.

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

Чтобы больше не ставить англоязычных коллег в тупик на зум-коллах, мы попросили нашего коллегу Адама Дэйли озвучить произношение терминов, в которых русскоговорящие специалисты часто делают ошибки.

Привет! Хочу поделиться своим мнением об оформлении вакансий по поиску разработчиков. Я сам разработчик, руководитель команд в разных компаниях, составлял вакансии и нанимал. Часто вижу вакансии, которые никогда не будут успешны.

Этот материал посвящён формированию культуры технических собеседований, проводимых с учётом потребностей людей и с уважением к ним.

Привет, Хабр! Я - начальник отдела разработки небольшой IT-компании, и мы - те самые люди, которые не ищут на работу сеньоров, и мы готовы брать не только мидлов, но даже и джуниоров, и готовы растить их до уровня крепких мидлов. Однако 80% приходящих на вакансию frontend-разработчика соискателей, даже называющих себя мидлами, с опытом работы, по сути оказываются не то что джуниорами - вообще не программистами. Что же на самом деле должен знать джун, чтобы попасть в компанию, подобную нашей, и как к этому прийти, если за плечами нет высшего программистского образования или богатого опыта программирования в школе? Я расскажу об этом и о том, как устроен процесс найма в нашей компании.

Базовый уровень программирования

Итак, к нам приходит среднестатистический кандидат, который прошел курсы по JavaScript, сделал там пару проектов. Потом узнал, что во многих местах хотят React, сходил на курсы по нему, тоже сделал пару проектов, выложил их на Github. Приходит к нам, уверенный в себе. И мы его просим написать функцию, которая выбирает из строки все большие буквы, или реализовать "вручную" какой-нибудь метод из array. И половина кандидатов в этом месте выбывают из строя. Кто-то вообще не может это сделать, у кого-то на двухминутную функцию уходит больше получаса. Зачем мы вообще это спрашиваем и почему с этого начинаем?

Как все знают, монорепозиторий - это несколько частей проекта (приложения, сервисы, библиотеки и т.д.), которые хранятся в одном репозитории. Плохо это или хорошо - не тема данной публикации. Но все же упомяну некоторые причины по которым я решил их использовать.

В скриптах деплоймента (или в моем случае еще и в настройках GitLab репозитория), нужно сформировать токены/ключи доступов к докер реджистри, кубернетесу, разным кластерам и т.д. И если у вас пару сервисов, то это не проблема, но если сервисов 15-20, то это весьма болезненный процесс. Особенно, когда настройки кластера меняются и нужно эти изменения вносить во все репозитории.

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

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

И вот мы решили использовать монорепозиторий, но с чего начать и как все организовать?

От переводчика: Привет, Хабр! Да, это очередная статья о преимуществах и недостатках монорепозиториев. Собирался написать свою статью о том, как мы используем монорепозиторий, как мы переходили с maven на bazel и что из этого получилось. Но пока собирался с мыслями, вышла отличная статья от разработчика из Lyft, которую я и решил для вас перевести. Обещаю опубликовать свои дополнения к статье, а также опыт с bazel в виде продолжения.

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

В этой статье я расскажу о своем опыте, но дети и родители уникальные, поэтому не все будут согласны, и не всем это может помочь. Читать данную статью требуется с улыбкой :)

Мы семья системных аналитиков, поэтому к воспитанию ребенка мы подошли "по-айтишному" или системно. Что это значит? Ребенок (система) должна быть правильно спроектирована и настроена, чтобы работать стабильно и штатно. Опустим часть, что природа правильно спроектировала ребёнка с нужным количеством хромосом, рук, ног и тд. Перейдем к части правильной настройки или воспитанию.

Всем привет, это Макс Кравец из Holyweb. Знаю много историй, когда начинающего специалиста с первого дня бросают на задачи, за которые никто не берётся, и ждут, пока новый сотрудник сам «выплывет». А перегорит и уйдёт — значит, просто слабак, который не хочет работать.

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

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