Веб-разработка *

Когда я встречаю очередную историю о том, как «инновационные» стартапы сливают миллионы на создание сервиса, а потом их сайт выглядит как нечто невразумительное, я искренне негодую. А прочитав статью о многозадачности и симбиозе от сооснователя и операционного директора «Тномера», выпал в осадок. €3 млн усвоены, а на сайт, видимо, не хватило.

Конструкция async/await представляет собой сравнительно новый подход к написанию асинхронного кода в JavaScript. Она основана на промисах и, в результате, не блокирует главный поток. Новшество этой конструкции заключается в том, что благодаря ей асинхронный код становится похожим на синхронный и ведёт себя подобным образом. Это открывает перед программистом замечательные возможности.



До появления async/await при разработке асинхронных механизмов программ использовались коллбэки и промисы. Автор материала, перевод которого мы публикуем сегодня, предлагает сначала вспомнить о том, как писать код по-старому, а потом, на реальном примере, изучить применение async/await.

«Если хочешь сделать что-то хорошо — сделай это сам». 5 апреля 2019 года мы проводим 4-ю Moscow Python Conf, и я решил провести странный эксперимент: посмотреть, что будет, если перевернуть подготовку докладов с ног на голову.

Как обычно делается — открывается Call for Papers (вот он, открыт, ничего с ним не случилось), месяца полтора-два организаторы уговаривают топовых спикеров предложить доклады, те отбиваются работой и семьей, а затем из сотни-другой поступивших докладов выбирается несколько десятков в программу, и все выдыхают. Хороший способ, с одним ма-а-а-аленьким недостатком: много случайностей.

Не факт, что даже опытный спикер сможет сделать сильный доклад по предложенной теме. «Активные» спикеры в известных компаниях могут быть заняты или хотеть на другую конференцию. Много интересных тем может пройти мимо просто потому, что десять человек программного комитета не знали про огромный клубок Python в недрах IVI.ru и никто им не написал.

Я решил попробовать пойти по пути Goblin Slayer и не кидать кубиков вообще: сам приходить в гости к компаниям, сам проводить интервью, выбирать темы и с нуля готовить спикеров. Видели бы вы их глаза от такого предложения… Фоток не будет, но под катом расскажу что получилось.

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

Меня зовут Андрей Логвинов, я работаю в группе разработки рендеринг-движка Яндекс.Браузера в Нижнем Новгороде. Сегодня я расскажу читателям Хабра о том, как устроено управление памятью в проекте Chromium на примере одной загадочной проблемы, которая приводила к падению производительности в тесте Speedometer. Этот пост основан на моём докладе с мероприятия Яндекс.Изнутри.

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

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

Существует немало инструментов, позволяющих подготовить среду для React-разработки. Например, в наших материалах учебного курса по React используется средство create-react-app, позволяющее создать шаблонный проект, содержащий всё необходимое для разработки React-приложений. Автор статьи, перевод которой мы публикуем сегодня, хочет рассказать о том, как самостоятельно настроить окружение для разработки React-проектов с использованием Babel и Webpack. Эти инструменты используются и в проектах, создаваемых средствами create-react-app, и мы полагаем, что всем, кто изучает React-разработку, интересно будет познакомиться с ними и с методикой создания React-проектов на более глубоком уровне. А именно, речь пойдёт о том, как сконфигурировать Webpack таким образом, чтобы это средство использовало бы Babel для компиляции JSX-кода в JavaScript-код, и как настроить сервер, используемый при разработке React-проектов.

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



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами
→ Часть 25: практикум по работе с формами
→ Часть 26: архитектура приложений, паттерн Container/Component
→ Часть 27: курсовой проект

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Друзья! Мы продолжаем серию публикаций «без купюр» о проектных процессах, IT-технологиях и о том, как работать эффективно. Сегодня поговорим об очень наболевшей теме, вызывающей изжогу в головном мозге — выборе технологий, языков программирования, роли архитекторов, аналитиков, тимлидов и экстрасенсов для решения эпической задачи: запустить программное решение, если возможно, в разумный срок. И отдельно остановимся, ну чтобы совсем не заскучать, на анализе корреляции размеров частей тела одной части коллектива с производительностью работы мозга другой. Наливайте кофе и поехали!

Недавно в компании SmartSpate решили собрать вопросы, касающиеся JavaScript, и на них ответить. В материале, перевод которого мы публикуем, приведены чуть больше двух десятков вопросов о JavaScript и ответов на них. Спектр затрагиваемых здесь тем достаточно широк. В частности — это особенности языка, проблемы, возникающие у программистов при написании JS-кода, работа в браузере и в среде Node.js.

В сети довольно много введений в основы работы с Three.js, но можно заметить нехватку материалов по более продвинутым темам. И одна из этих тем – это объединение шейдеров и сцены с трехмерными моделями. В глазах многих начинающих разработчиков это как будто несовместимые вещи из разных миров. Сегодня на простом примере “плазменной сферы” мы посмотрим, что такое ShaderMaterial и с чем его едят, а также что такое EffectComposer и как можно быстро сделать постобработку для отрендеренной сцены.

Привет! Я Дима, и я довольно давно и плотно сижу на Python. Сегодня хочу показать вам отличия двух асинхронных фреймворков — Tornado и Aiohttp. Расскажу историю выбора между фреймворками в нашем проекте, чем отличаются корутины в Tornado и в AsyncIO, покажу бенчмарки и дам немного полезных советов, как забраться в дебри фреймворков и успешно оттуда выбраться.

Можно ли, используя HTML, CSS и JavaScript, создавать настольные приложения? Автор статьи, перевод которой мы сегодня публикуем, даёт утвердительный ответ на этот вопрос. Здесь он расскажет о том, как, применяя веб-технологии и пользуясь возможностями фреймворка Electron, создавать кроссплатформенные приложения для настольных операционных систем.

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

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

Вам сюда, если хотите знать, как приручить широкоизвестный в кругах Python-разработчиков фреймворк под названием Сelery. И даже, если в вашем проекте Celery уверенно выполняет базовые команды, то финтех опыт может открыть вам неизведанные стороны. Потому что финтех — это всегда Big Data, а с ней и необходимость фоновых задач, пакетной обработки, асинхронного API и т.д.


Прелесть рассказа Олега Чуркина про Celery на Moscow Python Conf ++ помимо подробных инструкций, как настроить Celery под нагрузку и как его мониторить, в том, что можно позаимствовать полезные наработки.


О спикере и проекте: Олег Чуркин (Bahusss) 8 лет разрабатывает Python-проекты разной сложности, работал в многих известных компаниях: Яндексе, Рамблере, РБК, Лаборатории Касперского. Сейчас техлид в финтех-старапе StatusMoney.

В сегодняшней части перевода учебного курса по React мы поговорим о свойствах компонентов. Это — одна из важнейших концепций, нашедших отражение в данной библиотеке.



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами
→ Часть 25: практикум по работе с формами
→ Часть 26: архитектура приложений, паттерн Container/Component
→ Часть 27: курсовой проект

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

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



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами
→ Часть 25: практикум по работе с формами
→ Часть 26: архитектура приложений, паттерн Container/Component
→ Часть 27: курсовой проект

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

Как быть тому, кто работает один? На что ориентироваться, стремясь выстроить чёткий и эффективный рабочий процесс? Каким принципам и правилам следовать? Предлагаем вместе поискать ответы на эти вопросы.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.