CSS не отстаёт от JavaScript. Постоянно развивается. Классно же. Мне особенно радостно видеть, как старые задачи, которые я решал при помощи костылей, теперь можно сделать при помощи одного свойства.

Только многие фишки неизвестны широкому кругу разработчиков. Честно говоря, некоторые я сам узнал недавно. В любом случае так дальше нельзя. Надо исправлять ситуацию!

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

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

Согласно статье Ивана Покровского «Возможности и проблемы отечественной микроэлектроники», в России всего две тысячи разработчиков микросхем. Для сравнения: в каждой крупной международной электронной компании есть несколько команд, работающих над чипом или над IP, в каждой по паре сотен разработчиков (хотя бывает и меньше ста, и больше тысячи).

Две тысячи человек — это мало для любого сценария развитии России:

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

2. Так и для сценария, в котором российские разработчики будут строить экосистему проектирования в условиях изоляции, ориентироваться на производство микроконтроллеров и встроенных микросхем на зеленоградском Микроне, а также на сотрудничество в разработке semiconductor IP с китайскими производителями.

В других стран бывшего СССР ситуация еще хуже.

Что же делать? Для ответа на этот вопрос мы привлекли Машу Горчичко — выпускницу МИФИ, которая защитила диссертацию в Университете Вандербильда в Теннесси. Маша работала инженером в Роскосмосе, а сейчас работает в Кремниевой Долине, разработчиком в компании Applied Materials — одного из лидеров в оборудовании для производства микросхем.

Представим Машу, которая будет пояснять и иллюстрировать наши тезисы на видео. От себя прибавлю, что МИФИ — крутой вуз, в нем внутри есть ядерный реактор, а на входе стоит автоматчик:

Привет, Хабр! Представляю вашему вниманию перевод статьи "Long Names Are Long" автора Bob Nystrom.

Одна из умных вещей, которые делает Google — это строгие code review. Каждое изменение, прежде чем вам разрешат его внести в основную ветку, рассматривается как минимум в двух направлениях. Во-первых, кто-то в команде делает обычную проверку, чтобы убедиться, что код выполняет то, что должен.

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

Использование языка Dart в Google постепенно набирает обороты, и я много занимался подобными code review. Для разработчика языка это очень увлекательный процесс. Я получаю из первых рук представление о том, как люди используют Dart, что действительно полезно для его развития. У меня есть более четкое представление о том, какие ошибки являются общими, и какие функции интенсивно используются. Я чувствую себя как этнограф, ведущий дневник о жизни туземцев.

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

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

Уже несколько месяцев мы ведём разработку DevExtreme в открытом репозитории на GitHub. Непрерывная интеграция у нас с самого начала была построена на базе Docker, чтобы не зависеть от CI-платформы (будь то Travis, Shippable или что-то другое), но с момента публикации репозитория мы не выделялись и использовали для прогона тестов хорошо знакомый Travis CI. На GitHub у нас "бегает" только небольшая часть автоматических тестов, так сказать, первая линия, и возможностей Travis для техники Fork and Pull Request хватало.

Со временем коллеги начали сетовать на очередь из пулл-реквестов (но терпели). Мысль о том, что пора уже что-то предпринять, возникла в конце октября, когда на два дня Travis потерял связь с Docker Hub, а мы как раз готовились к beta-релизу DevExtreme 17.2.

Получив добро на эксперименты в корпоративном AWS-аккаунте, я решил дать второй шанс проекту Drone. Почему второй? Потому что мы его уже пробовали в процессе "обкатки выхода на GitHub". Тогда наш репозиторий был приватным, Drone был ещё более сырым, чем сегодня, и запускали мы его на временной наколеночной инфраструктуре, точнее на старых рабочих станциях, оставшихся после апгрейда рабочих мест (наш IT-отдел обещал их вот-вот забрать, но не торопился).

У нас сразу две отличные новости. DevExtreme, наш набор компонентов для фронтенд-разработки, переехал на GitHub и стал доступен бесплатно для некоммерческого использования!

Наш репозиторий — это не форк и не обрезанная версия. Это новый дом для DevExtreme, и там всё по-настоящему — от исходников до систем тестирования и сборки. Каждый желающий сможет наблюдать за тем, как мы фиксим баги (куда же без них) и добавляем новый функционал, а также поучаствовать в обсуждениях.

Вести разработку на GitHub — одно удовольствие. Механизм pull-реквестов с удобным code review — то, чего нам не хватало, пока мы жили во внутреннем Mercurial-репозитории. Теперь каждое изменение видят несколько пар глаз, что обеспечивает больший уровень прозрачности и позволяет процессам разработки плавно интегрироваться в методологии, принятые в команде (© SeOd).

В первые дни репозиторий выглядит пустовато, так как при импорте кода мы схлопнули историю коммитов. Но это продлится недолго! В дополнение к традиционным релизам, которые никуда не денутся, мы будем также оформлять Releases на GitHub и там же выпускать промежуточные pre-release и hotfix версии. Подписавшись на DevExpress/DevExtreme, например, с помощью сервиса Sibbell вы всегда будете в курсе наших последних новостей.

Эта статья о том, как написать универсальный JavaScript-компонент, который можно будет использовать

• как React-компонент;
• как Preact-компонент;
• как Angular-компонент;
• как Web Component;
• как jQuery функцию для рендеринга в DOMElement;
• как нативную функцию для рендеринга в DOMElement.

Зачем и кому это нужно

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

Лицо моей жены, когда она вычитывала эту статью

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

Я хочу с нуля реализовать, пожалуй, наиболее востребованный сценарий: у нас есть серверная часть, которая предоставляет REST API. Часть его методов требует, чтобы пользователь веб-приложения был авторизован.

1. История первая: воспоминание

• А как вы поддерживаете справку по API в актуальном состоянии?
• Как можно организовать и хранить локализованные версии?
• Вы проверяете текст на наличие недопустимых символов и на валидность разметки?
• Как организовать проверку (вычитку) топиков?

Что такое иммутабельность

Неизменяемым (англ. immutable) называется объект, состояние которого не может быть изменено после создания. Результатом любой модификации такого объекта всегда будет новый объект, при этом старый объект не изменится.

Немного о розетках