Относительно недавно в TC39 предложение с реализацией декораторов в EcmaScript вышло на 3-ю пред финальную стадию. Чуть позже MicroSoft выпустил 5-ю мажорную версию TypeScript, в которой новая реализация декораторов начала работать из коробки без каких-либо экспериментальных флагов. Babel тоже подсуетился, и в своей документации начал рекомендовать использовать новую реализацию декораторов. А это означает лишь то, что декораторы наконец-то начали полноценно входить в жизнь JavaScript разработчиков.

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

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

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

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

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

Однажды я захотел создать небольшую NPM библиотеку по всем “best practices” - с покрытием тестами, написанием документации, ведением нормального версионирования и changelog'а и т.п. Даже написал пару статей, которые в деталях описали, какие вопросы решает библиотека и как её использовать. И одной из интересных для меня меня задач при создании библиотеки была задача по максимальному уменьшению размера выходного NPM пакета - того, что в конечном итоге в теории будет использовать другой программист. И в этой статье я бы хотел описать, к каким методам я прибегал для того, чтобы достигнуть желанной цели.

В своей прошлой статье я рассуждал о том, как использование паттерна MVVM позволяет упростить процесс разработки. Паттерн был реализован с применением библиотеки MobX. Эту библиотеку я считаю в разы удобнее Redux, аргументы в пользу чего я также привел в статье. Однако, у нее имеется серьезный недостаток - излишняя свобода действий, в следствие наличия которой разработчики не всегда знают как писать код "хорошо". Паттерн MVVM же диктует несколько простых правил по использованию MobX, благодаря которым разработчики могут реже наступать на грабли. Однако, он не решает всех проблем. И в этой статье я бы хотел показать, как можно дополнить паттерн MVVM и сделать процесс разработки ещё приятнее.

В этой статье я бы хотел подискутировать о том, насколько хорошо паттерн MVVM подходит для разработки Web приложений на React. Вместе этим, я собираюсь описать какие преимущества могут быть при разработке с использованием MobX с паттерном MVVM в сравнении с Redux. Запаситесь кофе, это будет долгое чтиво.

Стало мне как-то интересно, кто из языков Go или Rust лучше работает с конкурентными задачами. С одной стороны, особый механизм конкурентности в Go является чуть ли основополагающей фичей. С другой стороны сам по себе Rust является более производительным языком, и в глазах некоторых программистов даже является "убийцей" C и C++. Поэтому я решил провести небольшое тестирование и написать собственный бенчмарк для этого.

Для упрощения я буду горутины в Go и асинхронные задачи в Rust называть корутинами. Для проверки различные тесты запускались на количестве корутин 10¹, 10², ..., 10⁶. Смысл тестирования заключается в том, чтобы определить, какой из языков решит задачу наиболее быстро. По затраченному времени на выполнение задачи можно судить не только о скорости работы языка, но и том, насколько он страдает от большого количества конкуретных задач. Также в каждом тесте записывалась потребляемая память.

Содержание

• Основные различия
• Reproducibility crisis
• Система контроля версий
• Data Version Control
• Полезные ссылки

Введение

Несмотря на всю пользу DVC, об этом инструменте знает катастрофически мало разработчиков. Поэтому, думаю, не лишним будет для начала вас познакомить. DVC – это open-source система контроля версий данных, которая отлично подходит для машинного обучения. И основное отличие DVC от Git’a в том, что он: во-первых, имеет более широкий и удобный инструментарий для ML-проектов; во-вторых, создан для контроля версий данных, а не кода. И по большей части здесь их основные различия заканчиваются. А далее я постараюсь описать, чем же так хорош DVC, и почему Git'а не достаточно для ML.