Несколько дней назад, мы написали пост о приближающихся изменениях в наших lifecycle-методах, где также затронули стратегию постепенной миграции (обновления). В React 16.3.0 мы добавили несколько новых lifecycle-методов для помощи в этой миграции. Мы также предоставили новое API для давно ожидаемых новшеств: официальное context API, ref forwarding API и ergonomic ref API.

Асинхронность. Асинхронность никогда не меняется. Node.js использовал асинхронность, чтобы получить большой rps для io-операций. TC39 добавила промисы в спецификацию для борьбы с адом колбеков. Наконец, мы стандартизировали async/await. Но асинхронность никогда не меняется. Погодите, что это синеет в небе? Похоже bluebird несёт в клюве пояс с инструментами для тех из нас, кто плотно подсел на thenable-объекты и всю эту асинхронную лапшу.

Привет, Хабр! Готовы субтитры к очень простому туториалу по React Native, в котором будет рассмотрена разработка приложения "Секундомер". За основу был взят секундомер на iOS.

В 2020 году библиотека Natasha значительно обновилась, на Хабре опубликована статья про актуальную версию. Чтобы использовать инструменты, описанные в этом тексте, установите старую версию библиотеки pip install natasha<1 yargy<0.13.

Раздел про Yargy-парсер актуален и сейчас.

Natasha — это аналог Томита-парсера для Python (Yargy-парсер) плюс набор готовых правил для извлечения имён, адресов, дат, сумм денег и других сущностей.

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

Введение

Всем привет.

С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.

Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном реляционном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.

У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать сотни тысяч RPS на всю систему.

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

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

Прошлый год закончился регулярной встречей iOS-разработчиков Red Hot Chili Apples. Под катом вы найдете записи докладов об альтернативе VIPER, базовых принципах функционального программирования на iOS, а также о том, как делать качественный проект при ограниченных ресурсах.

Привет, Хабр! Меня зовут Богдан, в Badoo я работаю в мобильной команде iOS-разработчиком. Мы достаточно редко рассказываем что-либо о нашей мобильной разработке, хотя статьи – один из лучших способов документировать хорошие практики. Эта статья статья расскажет о нескольких полезных подходах которые мы используем в нашей работе.

Уже на протяжении нескольких лет iOS-сообщество сражается с UIKit. Кто-то придумывает сложные способы «погребения» внутренностей UIKit под слоями абстракций в своих выдуманных архитектурах, другие команды переписывают его, теша своё эго, но оставляя за собой дикое количество кода, который нужно поддерживать.

Данная публикация является 2-ой частью перевода статьи «Introduction to commonly used ES6 features» под авторством Zell Liew, размещенного здесь. Перевод 1-ой части находится здесь.

Деструктуризация

Деструктуризация — удобный способ извлечения значений из массивов и объектов. Между деструктуризацией массивов и объектов существуют незначительные различия, поэтому рассмотрим их отдельно.

Деструктуризация объектов

Допустим, имеется следующий объект:

const Zell = {
  firstName: 'Zell',
  lastName: 'Liew'
}

Как создать приватный блокчейн Ethereum с нуля?

• Создание приватного блокчейна Ethereum с помощью geth.
• Создание кошелька MetaMask для работы с приватным блокчейном.
• Перевод средств между несколькими аккаунтами.
• Создание, развёртывание и вызов смарт-контракта в приватном блокчейне с помощью remix.
• Создание обозревателя блоков Ethereum поверх приватного блокчейна.

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.