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

Стандартизация JS перешла на годичный цикл обновлений, а начало года — отличное время для того чтобы узнать, что нас ждёт в юбилейной — уже десятой редакции EcmaScript!

ES9 — актуальная версия спецификации.

ES10 — всё ещё черновик.

На сегодняшний день в Stage 4 ^# — всего несколько предложений.

А в Stage 3 ^# — целая дюжина!

Из них, на мой взгляд, самые интересные — приватные поля классов ^#, шебанг грамматика для скриптов ^#, числа произвольной точности ^#, доступ к глобальному контексту ^# и динамические импорты ^#.

 

        ^{Автор фото: kasper.green; Жёлтый магнит: elfafeya.art & kasper.green}

Сегодня мы публикуем перевод очередного занятия учебного курса по React. Оно посвящено компонентам, основанным на классах. Такие компоненты создают с использованием ключевого слова class.



→ Часть 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: курсовой проект

У нас есть шесть продуктов, которые используют в России и за рубежом. Это значит, что документация к ним должна быть в одном месте, но разделена по продуктам и языкам.

Раньше мы использовали MediaWiki, но со временем она устарела. От платформы мы ожидали так же хорошую вёрстку статей, гибкий поиск и внутренний редактор текстов. В качестве альтернативы выбрали Confluence.

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

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

Последние несколько лет я, по непонятной причине, стараюсь подтолкнуть людей к расширению профессионального кругозора. Я убежден, что в современном мире невозможно занять достойное место, занимаясь узкоспециализированной деятельностью – только узкоспециализированной деятельностью (за редкими исключениями).

Есть, например, ребята, которых называют «кодеры» — они ничего не хотят знать о предметной области, заботятся только о качестве кода, о производительности, о правильной структуре данных.

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

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

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

Но сегодня – не об этом, сегодня – о технологиях.

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

^{Картинка отсюда}

Первыми приходят в голову три способа решить эту задачу:

1. Обойтись средствами браузеров, или написать плагины к ним
2. Организовать обмен данными через backend, выступающий в роли посредника
3. Добавить в программу HTTP-сервис, и обращаться к ней напрямую из браузера

Третий пункт выглядит хорошо, позволяет убрать авторизацию в программе, не требует вообще никакого пользовательского интерфейса. Попробуем его реализовать, написав программу на C# под .NET Framework 4. Так как речь пойдет о .NET, решение будет только для Windows (XP и новее). Веб-приложение сделаем на angular.

18 января было объявлено о выходе платформы Node.js версии 11.7.0. Среди заметных изменений этой версии можно отметить вывод из разряда экспериментальных модуля worker_threads, который появился в Node.js 10.5.0. Теперь для его использования не нужен флаг --experimental-worker. Этот модуль, с момента появления, оставался достаточно стабильным, поэтому и было принято решение, отражённое в Node.js 11.7.0.

Автор материала, перевод которого мы публикуем, предлагает обсудить возможности модуля worker_threads, в частности, он хочет рассказать о том, зачем нужен этот модуль, и о том, как в JavaScript и в Node.js, по историческим причинам, реализована многопоточность. Здесь же речь пойдёт и о том, какие проблемы сопряжены с написанием многопоточных JS-приложений, о существующих способах их решения, и о будущем параллельной обработки данных с использованием так называемых «потоков воркеров» (worker threads), которые иногда называют «рабочими потоками» или просто «воркерами».

Привет, Хабр! Меня зовут Тимур Шагиахметов, я PHP-разработчик в Badoo.

Производительность приложения — один из важнейших критериев качества работы программиста. В вопросах оптимизации PHP-приложений помощником является профайлер.

Недавно мы рассказывали о том, какими инструментами пользуемся для профилирования. Напомню: одним из инструментов для анализа производительности, когда непонятно, какие части кода повлияли больше всего на увеличение времени формирования ответа, является XHProf. Это расширение для PHP, которое позволяет профилировать код на боевом сервере и впоследствии  улучшать его.

Но хотелось бы ещё иметь историю изменения производительности, чтобы можно было отследить, что и когда повлияло на её ухудшение, не так ли? Для этого около года назад мы разработали Liveprof — инструмент для автоматического профилирования всех запросов с интерфейсом для анализа изменения производительности приложения.

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

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

В сегодняшней части перевода курса по React мы предлагаем вам выполнить практическое задание по формированию наборов компонентов средствами JavaScript и продолжить работу над 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: курсовой проект

Недавно мы опубликовали материал, в котором Эрик Эллиот критиковал TypeScript. Сегодня мы представляем вашему вниманию перевод статьи Кента Доддса. Тут он рассказывает о том, почему в PayPal перешли с Flow на TypeScript.

Привет, Хабр! Я Руслан Кокин, UX-дизайнер в компании UXhot, и у меня есть необычная история про лендинг, а также состояние копирайта в России.



Среди созданных нами продуктов есть по-настоящему легендарный лендинг пейдж, ставший донором для зарождающегося в интернете сегмента механизированной штукатурки. За три года работы он не только привлёк много клиентов, но и был скопирован почти 100 раз. Хотите узнать, что такого особенного в нем было?

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

В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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

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

Свежая подборка со ссылками на новости и материалы. В выпуске: взломан репозиторий PEAR, о будущем Xdebug, конференция PHP Russia 2019, свежие релизы, RFC предложения из PHP Internals, порция полезных инструментов, и многое другое.

Приятного чтения!

В последнее время Confluence и sharepoint стали почти безраздельно править на рынке баз знаний. Системы отличные, не спорю, но лично мне не хватает их гибкости да и в целом как-то не срослось: вики-возможности sharepoint остались где-то на уровне 2005 года (про работу с офисными документами молчу, с ними все гуд), а Confluence в силу своих особенностей с ростом числа статей неумолимо превращался в свалку, в которой невозможно найти что-либо нужное (но, может, проблема была во мне).

Не умаляя достоинства этих систем, хотелось бы рассказать о том, какие возможности есть у Mediawiki в роли корпоративной базы знаний. Само собой, mediawiki подойдет не всем — в ней нет модной интеграции с jira/tfs/etc, перенос документов с картинками из пакета Microsoft Office доставляет кучу неудобств, да и сама она написана на PHP, что в последнее время служит отпугивающим фактором для некоторых айтишников. Тем не менее, платформа живее всех живых и над ее развитием работает изрядное количество людей, коль скоро на ней базируется семейство проектов фонда Викимедиа.

В 2017-2019 годах можно было наблюдать серьёзный рост TypeScript. Происходило это по вполне понятным причинам. В этом языке есть много хорошего. Почти половина респондентов исследования State of JavaScript 2018 года уже пробовали TypeScript и собираются писать на нём в будущем. TypeScript весьма популярен, но стоит ли использовать его в крупномасштабных программных проектах?



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

Объектно-ориентированная парадигма — стандарт для прикладного ПО. Реляционные СУБД — стандарт хранения данных в прикладном ПО. Да, можно писать и на Haskell и хранить данные исключительно в ClickHouse. Но речь о мейнстриме.

ORM позволяет натянуть сову на глобус сделать вид, что RDBMS'а нет и данные хранятся в объектной модели, более подходящей для ООП. Остается «маленькая» такая проблемка — эта абстракция, как и многие другие, «течет». Там где в объектной модели ссылка на другой объект в базе данных foreign key и id. В момент материализации сущности мы встаем перед выбором:

1. Загрузить все и упасть с out of memory / timeout
2. Явно указать какие зависимости мы хотим загрузить, а какие — нет и нарушить принцип tell don't ask
3. Загружать зависимости неявно по требованию с помощью Lazy Load и получить проблемы с производительностью где-то в вызываемом коде

Какую-же ногу себе отрезать: левую или правую?

TLDR Lazy Load не так плох, если использовать только для записи и не использовать при чтении. Но все не так просто и есть куча нюансов.

Начнем сразу с дисклеймера: ниже принципиально не будет политических вопросов. Административные и юридические вопросы тоже будем обходить настолько, насколько сможем, чтобы полностью не вырывать техническую часть из остальных плоскостей.

Блокировки интернета в России уже есть — это данность, с которой мы живем и должны жить дальше. А раз так, нужно разбираться, как это устроено технически, что может и не может провайдер. Филипп Кулин (schors) давно начал собирать информацию по этому поводу, участвовал в нормативной работе, ходил на разные совещания. В итоге сейчас больше него о блокировках в России знает только Роскомнадзор, но это не точно. Под катом краткая сводка актуального состояния дел.


О спикере: Филипп Кулин (schors) генеральный директор ООО «Дремучий лес» — небольшого российского хостера, занимающегося в основном shared-хостингом.

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



→ Часть 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: курсовой проект

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

На Хабре уже давно не было статей по Метеору, поэтому хотелось бы поделиться нашей историей.



Расскажу про наш проект, как мы пришли к Meteor и как на нем летаем. Постараюсь не углубляться в детали или очень специфические вещи — их оставлю на обсуждение, либо отдельную статью.