Рубрика «кодогенерация» - 3

Суперскалярный стековый процессор: подробности - 1
Продолжение серии статей, разбирающих идею суперскалярного процессора с
OoO и фронтендом стековой машины.
Тема данной статьи — вызов функций, вид изнутри.
Читать полностью »

Суперскалярный стековый процессор: продолжаем скрещивать ужа и ежа - 1
Продолжение статьи, где удалось продемонстрировать, что фронтенд стековой машины вполне позволяет спрятать за ним суперскалярный процессор с OoO.
Тема данной статьи — вызов функций.
Читать полностью »

Суперскалярный стековый процессор: скрещиваем ужа и ежа - 1
В данной статье мы будем разрабатывать (программную) модель суперскалярного процессора с OOO и фронтендом стековой машины.
Читать полностью »

В этой статье я расскажу о решении проблемы кодогенерации при разработке приложений для СУБД Oracle. Хотя написанное ниже можно частично применить и к другим СУБД, и для генерации не только кода.

Проблема

При разработке приложений иногда возникают ситуации, когда требуется написать много похожих кусков кода, которые в силу различных ограничений нельзя заменить одной универсальной программной единицей. Следуя принципу DRY, вместо того чтобы копировать похожие фрагменты кода вручную с заменой отличающихся частей, лучше воспользоваться техникой кодогенерации из статичных заготовок на основе метаданных, вносящих разнообразие в получившиеся экземпляры кода. К кодогенерации приходится прибегать как в develop/deploy-time (когда все вариации известны заранее и есть возможность создать весь спектр экземпляров кода в статичном виде), так и в runtime, когда код генерируется на основе неизвестных заранее данных и сразу же исполняется.

Специфика кодогенерации при разработке приложений для СУБД состоит в том, что метаданные, как правило, хранятся в ней же.

Приведу несколько примеров задач, в которых востребована кодогенерация:

  • формирование SQL/DML/DDL-выражений на основе пользовательского выбора;
  • создание процедуры загрузки в систему-приемник очередного источника данных по его метаописанию в удаленной (remote) системе-источнике;
  • разворачивание системы в разных окружениях, версиях и редакциях СУБД, где необходимо (де)активировать некоторые опции или создать вспомогательные объекты: например, при разворачивании Oracle-приложения на редакции EE секционировать таблицы и строить локальные индексы; или при разворачивании на версии Oracle ниже 11 вместо виртуальных колонок и индексов по ним создавать представления-обертки с дополнительными вычислимыми колонками и строить function-based-индексы.

Читать полностью »

Как получить удобный доступ к XAML-ресурсам из Code-Behind - 1

Хочу рассказать, как максимально удобно работать с XAML-ресурсами из Code-Behind. В этой статье мы разберемся, как работают пространства имен XAML, узнаем о XmlnsDefinitionAttribute, используем Т4-шаблоны и сгенерируем статичный класс для доступа к XAML-ресурсам.
Читать полностью »

Многие наверняка знают, что для HTML & CSS существует великолепный инструмент ZenCoding(emmet), который позволяет очень сильно упростить ввод рутинных конструкций языка, определяя специальный язык мнемоник. C# менее многословный язык, чем Html, но тем не менее, ввод его конструкций можно здорово оптимизировать.
Я предлагаю динамическое расширение идеи мнемоник, впервые услышанное мною от Дмитрия Нестерука [1].

proto

sample

Получился небольшой плагин для ReSharper, мнемоники для которого можно настраивать через специальный язык, похожий на формальную грамматику.
Плагин для ReSharper доступен в галерее расширениий. Исходный код на GitHub

Читать полностью »

О чем вообще речь

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

Игра в прятки: кодогенерация против JSON Страшно подумать, но ещё каких-то десять лет назад разработка системы самого заштатного RPC была целым праздником в жизни разработчика. Болезненным и длительным праздником, как свадьба для лошади: голова в цветах, зад в мыле. Это было страшно увлекательно и одновременно невероятно запарно. Один выбор протокола чего стоил. Я уж не говорю о борьбе с могучими и чудовищными фреймворками, типа DCOM или CORBA. Реализация транспортного уровня вообще была уделом людей с длинными бородами.

В наше счастливое время жизнь программиста под iOS должна быть легка и приятна. Транспорт давно перестал быть проблемой. А RPC? Легко: достаём из кобуры Apache Thrift или на худой конец Google Protocol Buffers и пожалуйста, с минимальным напряжением головного мозга готов и протокол, и сервер, и клиент. Подавляющему количеству приложений в AppStore только это и нужно: простой и понятный интерфейс к удаленным процедурам, желательно в приятных обертках из нативных классов, и такая же простая и понятная обработка ошибок. Всё.

Но. К сожалению, и Thrift, и Protobuf заточены под одновременную разработку клиента и сервера. А такая удача случается в карьере программиста не часто. Читать полностью »

Это НЕ очередная статья о том что такое P/Invoke.

Итак, допустим в сферическом C# проекте необходимо использовать какую-либо технологию, отсутствующую в .NET, и все что у нас есть это Windows SDK 8.1 в котором имеется лишь набор заголовочных файлов для C/С++. Придется объявлять кучу типов, проверять корректность выравнивания структур и писать различные обертки. Это большое количество рутинной работы, и риск допустить ошибку. Можно конечно написать парсер заголовочных файлов… Тут просто и понятно все кроме количества требуемых на это человекочасов. Поэтому этот вариант отбрасываем и постараемся как либо иначе свести к минимуму количество необходимых действий для взаимодействия с unmanaged кодом.

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

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

Инструментирование JavaScript кода может понадобиться по целому ряду причин. Наиболее распространные: отладка, профилирование, трассировка, логирование. Как правило, движки в которых выполняется JavaScript предоставляют способы инструментирования кода без его изменения. В своей прошлой статье я описал некоторые средства которыми это осуществляется, а тажке существующие ограничения, в конечном итоге сподвигшие меня на начало описанного в той статье проекта и изучение вопроса инструментирования JavaScript путем автоматического изменения кода. Эта тема на мой взгляд обделена вниманием, но заслуживает раскрытия, тем более в комментариях был выражен интерес к концептуальному подходу модификации кода.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js