Все мы хотим быть продуктивнее и успевать делать больше работы. Но как это реально сделать на практике?

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

И только когда дедлайн уже вовсю маячит на горизонте, и начинает пахнуть жареным, я сажусь наконец за написание кода или анализ пулл-реквестов коллег. Знакомая картина? Увы, в этом я не одинок. Я долго пытался бороться с собой и пробовал разные методики, пока один из коллег не порекомендовал мне познакомиться с книгой «Глубокая работа».

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

В чем его секрет? В той самой пресловутой глубокой работе. Итак, вдохновившись примером Кэла Ньюпорта (а кто не хочет тоже стать монстром продуктивности?), я решил попробовать работать глубоко по его системе.

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

Сегодня мы рады представить новую версию сервера Centrifugo — Centrifugo v4. Релиз выводит Centrifugo на новый уровень с точки зрения эффективности клиентского протокола, простоты фоллбеков для WebSocket, экосистемы клиентских SDK и модели безопасности каналов. Также релиз включает в себя экспериментальную поддержку HTTP/3 и WebTransport.

Сколько раз вы замечали код, который, казалось, был написан наспех? Думаю, много. Иногда он написан кем-то другим, но довольно часто ваши собственные творения, по прошествии достаточного времени, заставляют вас задуматься: «Кто, черт возьми, написал эту чушь?» Поддерживать чистоту кода нелегко, поэтому я решил представить вам несколько инструментов, которые смогут вам в этом помочь. Пришло время освежить свои знания по статическому анализу кода в PHP.

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

В данной статье мы разработаем простую, но относительно полноценную дизайн-систему для веб-приложения средствами Sass.

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

При разработке дизайн-системы в части терминологии, названий, значений переменных и т.п. я буду ориентироваться, в основном, на Bootstrap и немного на Tailwind.

Код проекта на GitHub.

Если вам это интересно, прошу под кат.

⚛ Проектируем DataGrid на React так, чтобы сэкономить Boilerplate

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

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

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

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

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

Для лучшего понимания данного материала рекомендуется ознакомиться с разделом о разработке пакетов в официальной документации Laravel. А для более детального изучения темы будет полезен данный ресурс.

Данная статья в большей мере ориентирована на начинающих разработчиков.

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

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

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

В этом руководстве рассмотрен простейший алгоритм поиска пути, основанный на алгоритме Дейкстры. Этот алгоритм также известен под названием поиск по первому наилучшему совпадению, ключевая логика у него общая со многими другими алгоритмами, например, A*, заливка методом наводнения и диаграммы Вороного.

Здесь мы рассмотрим практическое применение этого алгоритма. Вам понадобятся базовые знания программирования и языка Python.

В этой статье мы расскажем, что такое UI KIT, для чего он нужен, и как он сэкономит время и деньги.

В статье мы подойдем к китам, которые сделаны не только дизайнерами, но также переведены в компоненты фронтенд-разработчиками.

Work on Stuff that Matters: First Principles

Доброго времени суток, друзья!

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

ReactJS по умолчанию обладает высокой производительностью. Но время от времени у вас появляется шанс сделать его еще лучше. И замечательное сообщество React придумало для этого несколько фантастических библиотек.

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

Давайте начнем.   

.     .     .

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

Привет!

Саша Инкин и я регулярно пишем на Хабр статьи по Angular. Почти все они основаны на нашем опыте разработки большой библиотеки компонентов.

Эту библиотеку мы развиваем, перерабатываем и дополняем уже несколько лет, а свои идеи проверяем на нескольких десятках проектов Тинькофф Бизнеса и внутренних систем компании. Мы рады сообщить: выложили нашу библиотеку в открытый доступ!

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

Явление деления разработчиков на уровни очень распространено. Даже в вакансиях чаще всего пишут не просто "Frontend-разработчик", а более развернуто - "Junior/Middle/Senior/${место для вашей должности} Frontend-разработчик". Для чего? С помощью такого деления легче делегировать задачи в команде. У каждого разработчика своя особая матрица компетенций, свои навыки, которые он оттачивал месяцами, а то и годами. С помощью такого деления процесс разработки ускоряется в разы.

Вообще на рынке (я смотрю на рынок стран СНГ) по состоянию на начало 2021 года среди Frontend-разработчиков имеют место быть такие должности (от низкого уровня, к наивысшему и без привязки к инструментам/библиотекам)

2020-й миновал. Это был нестабильный год и многие выдохлись. Социальная дистанция, локдаун, удаленная работа, а для многих – сокращения: все это стало новой реальностью.

Но несмотря на нестабильность, мировая сцена UI/UX и продуктового дизайна не стояла на месте. Ведь с новыми проблемами появились и новые решения. Компании выпускали новые продукты, а также обновляли существующие.