Мне не раз попадались такие проекты, от кода которых берет оторопь. Такое чувство, что сами авторы не смогут объяснить - почему у них все выглядит именно так. В этот момент у меня возникает вопрос: как так получилось? Если вас он тоже волнует, то могу пожелать лишь приятного чтения.

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

До недавнего времени у тех, кто пишет на Go было два пути: копипаста и кодогенерация. Фанатом ни первого, ни второго я не являюсь, однако к моей радости, теперь и в Go есть обобщенные типы. Казалось бы, проблема решена! Но не тут-то было, дженерики Go имеют весьма специфические ограничения, которые, портят всю малину. С одним из них мне и захотелось разобраться.

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

Go многими воспринимается как средство для написания микросервисов, тем не менее, сам он является языком общего назначения и позволяет писать приложения любого рода, в том числе, поддерживающие модули расширения.

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

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

Примерно год назад фронтенд нашего проекта, в качестве фреймворка для которого используется Vue.js 2, дошел до состояния, хорошо описываемого словами "проще сжечь".

К тому времени наш нетипизированный корабль уже трещал по всем швам, и решено было убить сразу нескольких зайцев одним выстрелом: полностью перевести проект на TypeScript, внедрить Vue Composition API и решить проблемы валидации сложных форм.

А проблемы были. Vuelidate - отличная библиотека с массой готовых валидаторов и остается таковой до тех пор, пока мы имеем дело с, так сказать, плоскими формами - формами, не использующими вложенных компонентов, также требующих валидации. Vuelidate работает на уровне компонента, требует наличия миксина, содержит массу правил, которые нам не были нужны, но все равно тянулись в составе пакета, поддержка TypeScript и Composition API на тот момент отсутствовала, и мы не могли более с этим миритьcя.

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

Во многих интерпретируемых языках используется динамическая типизация. Такой подход позволяет хранить в переменной с одним именем значения разных типов. В языке C используется строгая типизация, что, на мой взгляд более, чем правильно. Однако бывают случаи (хоть и не так часто), когда гораздо удобней было бы использовать динамическую типизацию. Зачастую, такая потребность напрямую связана с некачественным проектированием, но не всегда. Не зря же в Qt присутствует тип QVariant.

Здесь мы поговорим про язык C, хотя все, что описано ниже, применимо и к C++.