В этой статье мы узнаем, что такое GraphQL и сравним его с REST API, проведём аналогии и посмотрим на главные различия. Ну а также, естественно, посмотрим, как работает GraphQL и какие у него возможности.

Я полагаю вы уже знакомы с git. Чтобы не привело вас сюда, добро пожаловать и надеюсь найдете все, что вам необходимо знать.

Привет, Хабр! Меня зовут Екатерина Герт. Вот уже больше 10 лет я работаю системным аналитиком в проектах по заказной разработке ПО для компаний из разных отраслей и госсектора. Это всегда работа над большими проектами. 

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

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

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

Поехали! 

Привет! На связи СберМаркет Tech. Эту подборку книг составили инженерные менеджеры СберМаркета и ведущие подкаста «Для tech и этих» Олег Федоткин, Никита Елагин, Семён Мацепура и Вячеслав Артемьев. Сейчас в подчинении у ребят суммарно более 200 инженеров. Мы попросили их поделиться книгами, которые в своё время помогли им вырасти из разработчиков в управленцев. Эти книги не только про лидерство, но и про найм, стратегическое мышление и коммуникации. Они будут полезны тем, кто уже управляет командой или идёт к такой цели. Поехали!

Привет! Я Дмитрий Теслев, системный аналитик в AGIMA. И сегодня я хочу вам рассказать про гибкие навыки в работе аналитика и о том, как их развивать. 

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

Меня зовут Женя, я все еще фронтенд-разработчик в команде Quick Experiments inDrive. В этой статье буду делиться своим выводами, а также прикладывать дополнительные ссылки, чтобы познакомить вас с материалом более подробно.

Меня зовут Станислав Хрусталёв, я автор сайта hardclient.com. Работаю в управлении клиентским опытом с 2009 года. Пишу на эту тему, собираю лучшие практики из мира Customer Experience и оцениваю сервисные модели компаний.

Некоторое время назад я задался идеей: собрать базу лучших практик UX/UI в области электронной коммерции. Как сделать покупки в интернет-магазине максимально удобными для клиента? Чтобы он возвращался снова и рекомендовал вас друзьям и знакомым?

Время шло, и из небольшой статьи материал стал превращаться в крупнейшую (?) открытую русскоязычную базу с лучшими практиками UX/UI в сфере e-commerce.

Привет, друзья!

Представляю вашему вниманию перевод второй части серии статей, посвященных паттернам проектирования в TypeScript.

Спасибо Денису Улесову за помощь в переводе материала.

Паттерны (или шаблоны) проектирования (design patterns) описывают типичные способы решения часто встречающихся проблем при проектировании программ.

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

Привет, друзья!

Представляю вашему вниманию перевод первой части серии статей, посвященных паттернам проектирования в TypeScript.

Спасибо Денису Улесову за помощь в переводе материала.

Паттерны (или шаблоны) проектирования (design patterns) описывают типичные способы решения часто встречающихся проблем при проектировании программ.

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

«Под поверхностью машины движется программа. Без усилий, она расширяется и сжимается. Находясь в великой гармонии, электроны рассеиваются и собираются. Формы на мониторе — лишь рябь на воде. Суть остаётся скрытой внутри…» Мастер Юан-Ма, Книга программирования.

Под катом собрали 8 книг, которые рекомендуют прочитать наши разработчики. В целом, они все есть на заглавной картинке. Но если хотите почитать разные интересные вырезки из книг, цитаты, пару задач и мнения наших frontend-разработчиков — заходите под кат.

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

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

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

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

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

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

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

Всем известный закон Мёрфи гласит: «Если что-то плохое может случиться, то оно обязательно произойдет». Согласитесь, не самая позитивная установка, особенно когда это касается работы. И тут мне стало любопытно, а есть ли такие законы, которые мне, как ИТ-специалисту, максимально помогут избежать «чего-то плохого». К своему удивлению, я их нашел, и даже не один. Потому делюсь с вами сегодня своими сакральными знаниями в блоге ЛАНИТ. 

Здесь собраны лучшие и самые полезные репозитории Github, которые будут служить вам долгое время.

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

Статья глубоко погружается в тему, поэтому в начале я даю два фрагмента кода для тех, кто уже достаточно настрадался и понимает, что делать. Тем не менее, я всем рекомендую читать статью целиком!

Машины Руба Голдберга «работают». А еще они неэффективные, хрупкие, их сложно изготовить и поддерживать. Поэтому написать код, который «просто работает» — очень низкая планка.

Многие не осознают, что написание кода во многом напоминает написание эссе или книги. Насколько же я был уверен, что умение писать эссе мне «в жизни не пригодится» - но позже я узнал, что писать эссе – значит гораздо больше, чем укладываться в число слов и соответствовать критериям оценки.