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



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

Материал, перевод которого мы сегодня публикуем, посвящён рассказу о 10 React-компонентах.

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

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

Хотите узнать, как эти алгоритмы реализуются в JS?



Примеры можно посмотреть здесь.

Исходный код находится здесь.

ххх: на чём пишешь фронтенд?
yyy: на костылях и велосипедах
ххх: ммм, хороший фреймворк!
Bash.im

Когда приходит мысль стать программистом, ты вдохновенно открываешь справочник Шилдта по С, заказываешь толстую книгу Страуструпа по С++ и учишься шутить про указатель на указатель на указатель и про рекурсию. Жёсткая романтика первого времени… Но всё меняется, когда в твою жизнь случайно приходит JavaScript. «Какой он простой, понятный, какой классный синтаксис! Всё, решено, буду писать сайты», — думает начинающий программист и решает стать гуру всея веба. Но потом выбранный стек меняет своё дружелюбное лицо, и чем дальше, тем больше. Но ты уже не можешь остановиться, потому что ты один из них — фронтенд-разработчиков. Тех самых, которые «смотрящие за мордой сайта». Ну что, захотелось присоединиться? Тогда для вас 2 серия нашего спецраздела «Профессия:…»

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

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

Надеюсь, эта статья будет полезна как начинающим разработчикам, так и опытным.

В вопросах, которые показались мне сложнее прочих, приведены ссылки на дополнительную литературу.

Буду признателен за развернутые комментарии. Все замечания будут учтены при редактировании статьи.

Итак, поехали.

В статье речь идет о state colocation, то есть о совместном размещении состояний, этот термин можно было бы еще перевести как стейт колокейшн или стейт колокация.

Одной из основных причин замедления работы React приложения является его глобальное состояние (global state). Я покажу это на примере очень простого приложения, после чего приведу более близкий к реальной жизни пример.

Вот простенькое приложение в котором можно ввести имя для собаки (если окно не работает, вот ссылка):

Если вы поиграете с этим приложением то вскоре обнаружите что оно очень медленно работает. При взаимодействии с любым полем ввода возникают заметные проблемы с производительностью. В такой ситуации можно было бы использовать спасательный круг в виде React.memo и обернуть им все компоненты с медленным рендером. Но давайте попробуем решить эту проблему по другому.

Вот код этого приложения:

Дорогие товарищи инженеры, сообщество Метархия представляет вашему вниманию современный курс по Node.js, который включает глубокий разбор всех возможностей и аспектов платформы. Основной упор делается на то, как создавать надежные высоконагруженные сервера приложений и API без привязки к конкретному фреймворку и даже протоколу, т.е. абстрагировать бизнес-логику в отдельный слой. К лекциям прикреплено множество примеров кода, демонстрирующих гибкую структуру приложений и архитектурные приемы, в том числе работу с СУБД через слой доступа к данным, создание интерактивных приложений на вебсокетах, обеспечение безопасности, Graceful shutdown, межпроцессовое взаимодействие, предотвращение утечек памяти, масштабирование и кластеризацию при помощи процессов и потоков. На текущий момент в курсе 38 лекций (около 35 и ½ часов видео), 37 репозиториев с примерами кода, 4 PDF со слайдами. Перед основной частью курса по Node.js нужно сначала освоить хоть частично курс по асинхронному программированию.

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



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

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи Protecting Your GraphQL API From Security Vulnerabilities.

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

Это короткая, но достаточно полезная статья для продолжающих разработчиков о итераторах в Javascript.

Я думаю многие не раз слышали про Node js Streams, но так ни разу и не использовали, либо использовали, не задумываясь как же они работают, запайпили (pipe) стрим и норм. Давайте же разберемся что такое стримы, запайпить (pipe), чанки (chunk — часть данных) и все такое))

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

Вернее, не так.

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

• Почему по умолчанию все решают задачу именно так?
• Можно ли сделать лучше?

Буквально пару часов назад у меня завязался спор на тему того, что Node.JS слишком медленная для крупных проектов и ей стоит предпочесть Golang, Rust, PHP, etc. Основным аргументом противоположной стороны в этом споре был факт однопоточности JavaScript. Якобы при разработке приложения производительность просто упрётся в эту однопоточность и ничего сделать уже нельзя — только переписать на каком-то другом языке. Однако дела с этим в NodeJS обстоят немного лучше, чем кажется на первый взгляд. Перед тем, как мы углубимся в эту тему хочу заявить, что уважаю право каждого разработчика использовать тот язык программирования, который пришёлся ему по душе и который он считает предпочтительным в той или иной задаче.

Сделав поиск по ключевому слову «PM2» на Хабре я не нашёл ни одной статьи, посвящённой этому process-менеджеру. Лишь одиночные упоминания в статьях других пользователей. Я загорелся (сильно сказано) идеей наверстать упущенное и пролить свет на этот тёмный уголок разработки backend на Node.JS (о котором многие знают, да, я в курсе). Всех заинтересовавшихся прошу под кат.

Сложно представить себе разработку на JS без вывода информации в консоль. Говоря метафорически, console.log() — лекарство от большинства болезней кода.

Отладка — почти как расследование преступления, где главный преступник тоже вы — Филипе Фортес

Но помимо повсеместно используемой функции console.log(), есть ещё много инструментов, позволяющий сильно упростить процесс. Давайте разберём некоторые из них на простых примерах.

Что если взять замечательную математику (а именно линейные уравнения) и наш не менее замечательный JavaScript, а потом наложить одно на другое? То в условиях ограничений и специфики js-среды простая математическая задача может обернуться весьма любопытной и полной подводных js-камней проблемой. На прошедшей конференции HolyJS 19 в Москве одно такое линейное уравнение (среди прочих задач от компании SEMrush) наделало не мало шума.



И да, это снова рубрика Занимательного JavaScript'а: прошу под кат всех неравнодушных.

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

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

Задачка 1 — «BANANA»

Цель данной статьи:

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

Был я как-то на ZeroNights, это очередная конференция по информационной безопасности, которая в этом году была совсем шлаком.

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

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

Как закончилась конференция, все её участники взяли билеты на сапсан, последний сапсан Санкт-Петербург — Москва выезжает в 21:00, и я на него успевал…

Зачем вообще эта статья, для кого и что дает читателю

Для тех, кто не хочет читать много,


После написания статей о bike (раз, два) меня много спрашивали о том, как я попал в IT.
Мне и самому были очень интересны подобные статьи, когда я учился. Хорошо помню, как они придавали мне мотивации двигаться дальше.

Именно эти причины побудили меня написать данную статью.

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

И вот сейчас я уже практически middle в компании — резиденте Сколково.

А начиналось все еще немного раньше, примерно в феврале 2018…. Даже, пожалуй, еще раньше, летом 2017.

После того, как я изложил свою историю «трудоустройства» в Яндекс в комменте к нашумевшей заметке «Как я проработала 3 месяца в Я.Маркете и уволилась», было бы несправедливо утаить и ту пользу, которую я вынес из своего опыта Яндекс.Собеседования.

В мои рабочие обязанности входит техническое интервьюирование кандидатов на позицию Fullstack JavaScript/TypeScript Developer, активно этим делом (стоит ли говорить, что слегка поднадоевшим?) я занимаюсь больше года, за плечами более 30 технических интервью.

Раньше на техническом интервью я задавал кандидату довольно бестолковые вопросы аля «что такое замыкание», «как в JavaScript реализуется наследование», «вот есть такая-то таблица в БД с такими-то индексами, расскажите, пожалуйста, как можно ускорить такой-то запрос», которые хоть и помогали выявить инженерные способности кандидата, но совершенно не позволяли сделать вывод о том, насколько хорошо человек сможет решать задачи и насколько быстро он сможет разобраться в уже существующем коде. Что не могло не привести к печальным последствиям…

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