Здравствуйте, меня зовут Сергей, я работаю JavaScript-программистом, и я - буддист. Но совсем не такой, каким вы меня только что представили. Наверняка, при прочтении слова "буддист", в вашей голове всплывает либо образ улыбчивого азиата в оранжевом одеянии, либо образ безработного хиппи-вегана, путешествующего по Индии, занимающегося йогой и ищущего "просветления" в сомнительных религиозных практиках. Так вот, я ни тот, и ни другой. Так кто же я? Чтобы ответить на этот вопрос, нужно для начала поближе познакомиться с историей буддизма.

Около трех с половиной тысяч лет назад Древняя Индия была завоевана ариями - одним из индоевропейских племен, пришедшем в Индию с предгорий Кавказа через территорию современного Ирана. Немного отклонившись от основной темы поста, скажу, что с этим завоеванием связано много интересных фактов. Именно потому, что кроме Индии эти племена завоевали также территории Европы и Ирана, все европейские, персидский и индийские языки родственны друг другу и входят в одну языковую семью. Вы же понимаете санскритское слово "веды" без перевода, верно? И именно по названию места происхождения этих племен в английском языке европеоидная раса называется caucasian race. А также именно по названию этого племени французский граф Жозев Артюр де Гобино дал имя своей печально известной расовой теории, позже популяризованной и претворенной в жизнь Адольфом Гитлером. Но давайте вернемся назад к нашей теме.

Многие из вас, я уверен, слышали о теории игр в какой-то момент своей жизни. Если вы хотите выглядеть умным и произвести впечатление на свою девушку — просто упомяните «игру с нулевой суммой» или «эволюционную стратегию», и ваши шансы отвести её домой сегодня вечером только что подскочили на 50%. Или вы можете использовать теорию игр, чтобы принимать решения в инвестировании своих денег (чтобы их полностью потерять и разориться) или, например решая, на какой девушке жениться (что также очень вероятно вас разорит). Как видите, это очень полезная теория.

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

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

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

Погнали собирать мусор!

Здравствуйте. Меня зовут Ник, я фронтенд разработчик (жидкие аплодисменты). Кроме того, что я пишу код, я преподаю в Школе программистов hh.ru.

Записи наших лекций от 2018-2019 учебного года можно посмотреть на youtube

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

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

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

1. Зачем думать о производительности
2. FMP, TTI + подробнее в докладе
3. Critical render path, DOM, CSSOM, RenderTree
4. Шаги по улучшению производительности первой загрузки + подробнее в докладе

Браузеру предстоит пройти много шагов, прежде чем HTML-ответ от сервера будет преобразован в пиксели на экране. Последовательность этих шагов, необходимая для первого отображения страницы, называется «Критический путь рендеринга» (ориг. Critical Rendering Path).

На курсе, где я учился frontend-разработке, нас познакомили только с unit тестированием. Но уже на первом месте работы, я столкнулся и с регрессионным тестированием, и с автотестами, и с E2E-тестами. Мне было сложно понять, чем они отличаются, какие еще есть виды тестирования и кто их должен писать. Эта статья для начинающих разработчиков, которые задаются подобными вопросами.

Сегодня ровно 20 лет, как я начал программировать профессионально. За эти годы я:

• Получил одобрение на петицию по грин‑карте за выдающиеся способности в науке.
• Стал Google Developer Expert.
• Стал IEEE Senior Member.
• Был операционным директором в компании со 100 сотрудниками.
• Написал код, который скачали 135 миллионов раз.
• Выступал перед аудиторией в 2000 человек, дважды.
• Стал самым честным человеком в России по версии НТВ.

Но упустил я гораздо больше и делал всё это слишком долго. Думаю, этот путь можно было бы пройти «на скорость» лет за 5 с теми подходами, принципами и приоритетами, которым я научился. Если вы только начинаете свой путь, этот текст может сэкономить вам 15 лет жизни.

Привет! Меня зовут Ивасюта Алексей, я техлид команды Bricks в Авито в кластере Architecture, а это мой цикл статей о протоколе HTTP. В первой части мы уже познакомились с версией протокола 1.0 и поговорили о структуре ответов и запросов. Теперь пришло время узнать, что такое Cookies и для чего нужен CORS.

Проверяя работы студентов на курсе IT рекрутер, я вижу, что тема булевых и x-ray запросов сложная для понимания. Хочу попробовать на примерах рассказать азы так, чтобы стало сильно понятнее.

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

Основными критериями качественного кода являются следующие: простота восприятия, гибкость для модификаций, возможность обновления, понятность, тестируемость. Однако зачастую работа над проектом ведется в спешке, под давлением и код пишется людьми с разным уровнем квалификации (с разным мышлением). И даже опытные разработчики не всегда пишут код самого высокого качества. Поэтому для повышения качества кода проводится процедура code review.

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

Начнем с повторения основ "долгих (долго выполняющихся) задач" (long tasks) и соответствующих метрик производительности.

Тестирование — один из процессов, который может быть автоматизирован в рамках CI/CD. Надёжное и тщательное автоматизированное тестирование позволяет быть уверенным в новых сборках, снижает затраты на производство и повышает качество продукта. Но даже в крупных компаниях на больших проектах оно есть не всегда. 

Обычно в тестирование начинают вкладываться, когда багов становится слишком много, недовольство клиентов растёт, и начинают «гореть» деньги бизнеса. Вместе с Александром Довнаром, Lead DevOps в Naviteq, мы разобрали, что такое непрерывное тестирование и какую роль оно занимает в CI/CD. А ещё рассмотрели кейс, как компании приходят к его внедрению, и что это внедрение даёт. 

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

Погрузитесь глубоко в новую архитектуру React под названием Fiber и узнайте о двух основных фазах нового алгоритма согласования (reconciliation). Мы подробно рассмотрим, как React обновляет состояние и пропсы и обрабатывает дочерние элементы.

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