Казалось бы, IT-индустрия бесконечно далека от сборочных цехов Генри Форда. Однако даже труженики нуля и единицы порой чувствуют себя пойманными в порочный круг. День за днём одни и те же таски, каждый обеденный перерыв — одни и те же статьи на Хабре…

Давно пора положить этому конец. Сегодня, дорогие хабровчане, мы приветствуем вас в самой нерутинной статье про рутину. Четверо сотрудников компании «Контур» в четырёх разных форматах поделятся своими историями про борьбу с рутиной. Пристегните ремни и добро пожаловать под кат.

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

Но у этих парней есть тайна. Нет, у них Тайна. Вскрывается, как теперь выяснилось, элементарно – задним умом и я крепок. Но то ли я какой-то не такой, то ли явление действительно из ряда вон… Распознать именно тенденцию смог лишь с третьего раза.

История будет короткой, чай не успеете допить.

У каждого клиента – свои предпочтения. Не только в выборе автомобиля, блюда на обед или корпоративной информационной системы. Клиенты любят выбирать программистов.

Ну, что программисты разные – ежу понятно. Считается, что клиенты предпочитают профессионалов. Мы тоже так думали, и искренне стремились сделать каждого своего программиста этим самым профессионалом.

Однако, несколько клиентов, ставя нам задачи, упорно твердили: пусть программирует Серёжа. Хотя Серёжа – лютейший говнокодер, объект всеобщей жалости и главный поставщик материалов для конференций на тему «Как не надо программировать».

Два года назад я написал на хабре статью Как живется в США «неайтишникам», которая собрала 194 000 просмотров, 561 комментарий и вошла в список лучших статей 2020 года. И вот, два года спустя я решил пробежаться по тем же тезисам, чтобы провести некий срез, как изменилась обстановка в США и мое место в ней, особенно в свете последних событий.

Про жизнь, траты, поиск и смены работы и перспективы. Мне 38, я по образованию биотехнолог, семья — два человека, английский язык — так себе. Живу в Северной Каролине почти два года. Обещаю без политики и максимально объективно.

В свете исследования "Веб-разработчики пишут небезопасный код по умолчанию" мне подумалось, что именно так может звучать один из базовых вопросов на собеседовании с точки зрения проверки знания web-разработчика от уровня Junior до Senior.

Тема с одной стороны в общем-то простая, а с другой - многогранная. Можно сделать “на коленке”, а можно и “по-взрослому” -  зависит от знаний конкретного девелопера и технического задания. Ну и не привязывается к конкретному языку. Что nodejs, что .net, что PHP - на ответы это не влияет. Ну и отлично же! Давайте попробуем.

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

Как бы вы ответили на конкретный вопрос? Попробуйте проверить себя и потратить пару минут на обдумывание прежде чем читать ответ.

Восклицательным знаком ⚠ помечены вопросы, на которых можно "засыпаться" и оставить плохое впечатление о себе у интервьюера. Так же я позволил себе добавить еще пункты, которые подразумевают "Регистрацию", но по касательной. Многие ответы обрамил ссылками, которые помогут разобраться чуть глубже в конкретном вопросе, думаю будет полезно.

Итак, за вёсла!

Когда мы имеем дело с большим проектом, в репозитории которого накопились десятки тысяч строк кода, иногда единственным здравым решением кажется все переписать с нуля, а не оптимизировать. С точки зрения бизнеса может возникнуть вопрос: а почему вообще нужно оптимизировать или даже переписывать приложение, если оно работает? Дело в том, что по мере роста кодовой базы есть вероятность увеличения дублирующихся компонентов/фрагментов кода, появления устаревших участков, которые тормозят сборку, но полезной нагрузки уже не несут. Это негативно влияет на скорость работы приложения и увеличивает срок разработки.

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

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

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

Интро: почему я написал эту статью

Меня зовут Виктор, я разрабатываю страницу результатов поиска Яндекса. Несмотря на внешнюю простоту, поисковая выдача — сложная штука: на каждый запрос генерируется своя уникальная страница, на которой в зависимости от запроса может присутствовать блок Картинок, Карты, Переводчик, видеоплеер и многие другие компоненты. Все они должны запускаться и работать в памяти обычных бюджетных телефонов, которые использует большинство наших пользователей. Браузерам должно хватать ресурсов, чтобы пользователь не видел вот такого:

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

Разрабатывая проект на JavaScript (TypeScript, ClojureScript или каком-то другом языке, транслируемом в JavaScript), мы привыкли создавать объекты, массивы, строки и вообще писать код, как будто память бесконечна. Это не так. Я расскажу о видах проблем с памятью, о том, какие ограничения мы часто забываем и как их можно преодолеть. В ответ браузеры и пользователи скажут вам спасибо.

• Категории проблем с памятью
• Ограничения по памяти для разных типов данных
  　Heap
  　Buffer, TypedArray
  　String
  　Map, Set
  　Call stack
  　Типичные задачи, в которых можно наткнуться на ограничения по памяти
• Soft-утечки
  　Пример из продакшена
  　Как получаются soft-утечки
  　Как их обнаружить
  　Как найти причину
  　　1. Memory Allocation Timeline
  　　2. Техника трёх снапшотов
  　　3. queryObjects
  　　Тренируемся находить утечки
• Hard-утечки
  　Пример из продакшена
  　Как бороться
• Нестандартные оптимизации памяти в Node.js
  　Исходный код
  　Module._pathCache
  　Несколько версий пакета в node_modules
  　require('./data.json')
• Заключение

Добрый день всем, дорогие читатели!

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

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

Как сказал мой добрый друг-программист про Factorio: "Эту игру создали программисты для программистов" и эти слова плотно въелись в мою память. И реально игра в эту игру очень сильно напоминает процесс разработки ПО: можно просто строить как попало и прийти к полностью запутанной и сложнообслуживаемой системе, а можно подойти к вопросу с умом изначально и в итоге получить производительную и легкую в обслуживании систему (Прям как в жизни!)

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

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

На все эти вопросы ответил frontend-разработчик Виталий Старов на конференции FrontendConf 2021. Он рассказал о серверном рендеринге на примере приложения SuperJob. Читайте под катом, как SuperJob пришли к своей реализации серверного рендеринга, узнав по пути много интересного. Узнаете, когда хорош SSR и как он работает, из чего он устроен, чем может быть полезен и кому.  

Меня зовут Николай, я Frontend-разработчик IT-компании Relog. Хочу рассказать о самых распространённых ошибках в вёрстке современных проектов.

Дело в том, что лишь малая часть современных фронтендеров обращает внимание на работу с HTML и CSS, предпочитая готовые решения, вроде UI-библиотек и систем сеток. Но эти решения неидеальные и приходится дописывать обёртки вокруг них, видоизменять код, переписывать стили и совершать прочие действия для соответствия требованиям проекта. Тут-то и начинаются проблемы: вёрстка местами становится избыточной, стили переназначются через important и с каждым релизом проект всё сложней поддерживать. Я уже не говорю об удобстве использования и доступности. Об этом думают вообще в последнюю очередь.

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

Всем привет! Меня зовут Игорь Савин, я frontend-разработчик в компании Домклик. На текущий момент у нас около 150 различных команд разработки, из которых большая часть связана с разработкой какого-либо фронтенда на HTML, CSS и Javascript. Но когда так много команд, непременно возникают ситуации, при которых в проект одной команды нужно встроить какую-то функциональность, разрабатываемую другой. И не просто встроить, но и потом поддерживать её работу, исправлять ошибки и внедрять новые фичи.

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

Чаще всего дизайнер отрисовывает анимацию в специальной программе, например, After Effects, и присылает верстальщику видео, по которому нужно повторить анимацию. А вот как реализовать эту идею — решать разработчику. Он может использовать три вида анимаций: CSS-анимации, SVG-анимации или JavaScript-анимации.

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

Анимация на КПДВ: Дилан Баунманн, codepen.

Это статья о Styled Components будет полезна новичкам и старичкам. Для понимания материала нужны базовые навыки работы с React и TypeScript.

Styled Components — одно из популярных решений написания кода методом CSS in JS. Гибкое, простое и, главное, идеально вписывается в архитектуру React приложения.

Разберём данную библиотеку на базовых примерах в связке с TypeScript. Также поделюсь своими лучшими практиками при написание кода.

Эта статья для тех, кто только начинает свой путь в написании больших React приложений, но все еще использует только console.log для их дебага. Мы с вами рассмотрим работу с расширением для браузера "React Developer Tools" на простом примере, который в дальнейшем вы сможете применить в своих проектах. Это расширение дает возможность просмотра дерева компонентов, их props, состояния и контекста. Также достаточно просто отловить неэффективные компоненты, которые подвергаются повторному рендерингу, посмотреть сколько на это уходит времени и построить графики для визуализации эффективности компонентов. Благодаря этой информации вы не только сможете оптимизировать ваше приложение, но и более глубоко изучить React и понять все тонкости работы с ним.

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

В этой статье я хочу показать вам, как создать шаблон React.js + Express.js + TypeScript приложения.

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

• React — далеко не идеальный, но лучший на сегодняшний день фреймворк для фронтенда (или, согласно официальной документации, "для создания пользовательских интерфейсов");
• Express — несмотря на наличие большого количества альтернативных решений, по-прежнему лучший Node.js-фреймворк для разработки веб-серверов;
• TypeScript — система типов для JavaScript (и еще кое-что), фактический стандарт современной веб-разработки.

Исходный код проекта.

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

Привет! Меня зовут Сергей, я управляющий партнер в KTS

Совсем недавно состоялся релиз 6-ой версии react-router. Вообще создатели react-router часто меняют подходы, используемые в библиотеке, но в этот раз они объединили лучшее, что было в прошлых версиях.

В статье приведен краткий обзор того, что поменялось.

Сегодня я хочу рассказать про один не очень популярный но очень классный паттерн в написании React приложений - Compound components.

Что это вообще такое

Compound components это подход, в котором вы объединяете несколько компонентов одной общей сущностью и общим состоянием. Отдельно от этой сущности вы их использовать не можете, тк они являются единым целым. Это как в BEM нельзя использовать E - элемент, отдельно от B - блока.

Самый наглядный пример такого подхода, который знают все фронты - это select с его option в обычном HTML.