Читал книгу Девятаева в подростковом возрасте, чрезвычайно увлекательно написано (как мне тогда показалось).
Подвиг с большой буквы. И невероятное везение.
Всем книгу рекомендую.
При обычном срезе давность последних значений ничем не ограничена, а часто нужны последние, но не слишком старые данные.
Например, значения телеметрического замера тока электродвигателя, работающего с изменяющейся загрузкой, быстро теряют актуальность (замер суточной давности имеет мало смысла).
Я к тому, что обычно востребовано последнее значение, находящееся между двух заданных дат, а не просто по состоянию на одну дату.
Мне довелось работать с базами замерных данных по объектам (суть те же временные ряды).
Наиболее актуальными видами запросов были следующие (как для одного ряда, так и для группы рядов):
выборка последнего значения по состоянию на момент времени, но не ранее заданного момента времени (фактически, выборка последнего значения в интервале);
выборка значений за временной период + последнего значения по состоянию на начало периода, но не ранее заданной даты.
Упомянутое дополнительное ограничение по времени при выборке последнего значения имеет смысл, когда слишком старые данные не актуальны и не нужны, и помогает базе не делать поиск глубоко в истории, что положительно сказывается на производительности.
У автора есть размышления не сей счёт или таких нюансов пока не касались?
А в чём ненормальность такого программирования?
На некоторых простых микроконтроллерах вытесняющую многозадачность по другому и не реализовать (доводилось такое делать для 80186).
(подумал, что статья в чём-то про меня))
А «это», для «привлечения внимания» — пример скрипта на «компилируемом», поддерживающем «ленивость»/многопоточность/асинхронность псевдоязыке с синтаксисом, как у формул Excel (+небольшое количество «синтаксического сахара»).
Используется как DSL.
Недавно переведён с .Net 2.0 на .Net 4.5 (уж очень захотелось приобщиться к async/await вместо AsyncEnumerator)…
Оно компилируется в «дерево» вызовов функций, вычисляемых в заданном контексте.
Т.е., по факту, никакого нового кода не создаётся, лишь структуры данных, связывающие функции между собой через входы/выходы.
Больше всего похоже на "Шитый код".
А мне довелось делать скриптовый движок в одном проекте на базе .Net Framework 2.0,
синтаксис простейший — как у формул в Excel (собственно, в ячейках xls-документа и предполагалось записывать выражения),
но для удобства написания «невнутриэксельных» скриптов добавлены операторы:
* . (точка, передаёт левое выражение в качестве первого аргумента вызываемой справа функции);
* .. (двоеточие, аналогично, только вторым аргументом);
* а также объявлений массивов "{… }" и выборки по индексу "[n]".
Формируется «шитый» код с вызовом «пользовательских» функций (синхронные/асинхронные, с побочными эффектами и без, макрофункции, всё реализовано через вызовы функций), поддерживается «ленивость», «асинхронность» (на основе собственного «велосипеда» по мотивам шаблона AsyncEnumerator), «прозрачное» применение скалярных функций к IList-векторам (например, "{1,2,3}.sin()"). Язык безтиповый, все значения передаются как Object.
Все именованные значения вычисляются однократно и «лениво», константные выражения вычисляются при «компиляции», имеется базовая поддержка замыканий.
Из недостатков: .Net 2.0 (в 4-м можно было бы использовать встроенные возможности для реализации асинхронности), сложный код писать трудновато без интеллектуального редактора, также приходится ограничивать параллелизм семафорами, иначе память кушается много))
Изначально задумывался «движок» для построения отчётов/организации вычислений на основе шаблонов/алгоритмов, описанных в Excel-документе, без использования ПО Excel по следующему принципу: на основе Excel-шаблона внутрипрограммно формируется скрипт для построения отчёта, после чего «компилируется»/запускается, запрашивает требуемые параметры и делает отчёт/вычисления в фоновом режиме.
У меня в выходные 2 посылки прошли импорт:
одна, 28.02 отправленная из Китая, прошла таможню в Самаре;
другая, отправленная в середине марта из Нидерландов прошла импорт в Мск.
Довелось как-то читать документ «Уровень развития интеллекта супругов и удовлетворенность браком», так там по результатам исследований схожие выводы и сделаны)
AsyncEnumerator — «наше всё» уже 2+ года, тем более, что для его использования достаточно C# 2.0 и .Net Framework 2.0.
А так, конечно, хочется уже и без «костылей» асинхронный код в линейном виде писать.
В старших классах (начале 90-х) у меня была самодельная конструкция следующая:
* черенок хоккейной клюшки;
* кусок нихромовой «утюжной» проволоки, закреплённый вдоль черенка на регулируемой высоте;
* понижающий трансформатор с несколькими выводами вторичной обмотки (из отцовских запасов).
Баловался скорее, чем серьёзные вещи делал.
Например, по сечениям из журнала «Моделист-Конструктор» была собрана летающая(планирующая) моделька Ил-2 полностью из пенопласта длиной порядка 30см (до сих пор где-то картонные «выкройки» лежат).
Технология была следующая: на параллельные торцы куска пенопласта требуемой длины крепились две «выкройки»-сечения (например, секции крыла или фюзеляжа), по выкройкам, как по направляющим, проводилась раскалённая нихромовая нить (сложность только в том, чтобы вести её по обеим выкройкам синхронно, не допуская задержек, из-за которых могли образовываться «ямы» на местах локального перегрева пенопласта).
Доп. прочность деталям придавал тонкий поверхностный оплавившийся слой.
Торцы обрабатывались шкуркой и склеивались столярным клеем, в центроплан для усиления прочности были вставлены тонкие деревянные рейки.
При запусках модельки по квартире страдал нос (плющился)) и передняя кромка крыла. Самолётик был «убит» (обломались кончики крыльев, стабилизатора, киля) и «выпущен на свободу» в начале 2000-х до появления доступной цифровой фотографии и до осознания его дальнейшей ностальгической ценности)).
Фантазия на тему тетраэдра :)
Подвиг с большой буквы. И невероятное везение.
Всем книгу рекомендую.
При обычном срезе давность последних значений ничем не ограничена, а часто нужны последние, но не слишком старые данные.
Например, значения телеметрического замера тока электродвигателя, работающего с изменяющейся загрузкой, быстро теряют актуальность (замер суточной давности имеет мало смысла).
Я к тому, что обычно востребовано последнее значение, находящееся между двух заданных дат, а не просто по состоянию на одну дату.
Наиболее актуальными видами запросов были следующие (как для одного ряда, так и для группы рядов):
- выборка последнего значения по состоянию на момент времени, но не ранее заданного момента времени (фактически, выборка последнего значения в интервале);
- выборка значений за временной период + последнего значения по состоянию на начало периода, но не ранее заданной даты.
Упомянутое дополнительное ограничение по времени при выборке последнего значения имеет смысл, когда слишком старые данные не актуальны и не нужны, и помогает базе не делать поиск глубоко в истории, что положительно сказывается на производительности.У автора есть размышления не сей счёт или таких нюансов пока не касались?
На некоторых простых микроконтроллерах вытесняющую многозадачность по другому и не реализовать (доводилось такое делать для 80186).
Иду обратно и думаю, а вдруг скидка по «Хабрахабр» ещё актуальна была?
А «это», для «привлечения внимания» — пример скрипта на «компилируемом», поддерживающем «ленивость»/многопоточность/асинхронность псевдоязыке с синтаксисом, как у формул Excel (+небольшое количество «синтаксического сахара»).
Используется как DSL.
Недавно переведён с .Net 2.0 на .Net 4.5 (уж очень захотелось приобщиться к async/await вместо AsyncEnumerator)…
Т.е., по факту, никакого нового кода не создаётся, лишь структуры данных, связывающие функции между собой через входы/выходы.
Больше всего похоже на "Шитый код".
синтаксис простейший — как у формул в Excel (собственно, в ячейках xls-документа и предполагалось записывать выражения),
но для удобства написания «невнутриэксельных» скриптов добавлены операторы:
* . (точка, передаёт левое выражение в качестве первого аргумента вызываемой справа функции);
* .. (двоеточие, аналогично, только вторым аргументом);
* а также объявлений массивов "{… }" и выборки по индексу "[n]".
Формируется «шитый» код с вызовом «пользовательских» функций (синхронные/асинхронные, с побочными эффектами и без, макрофункции, всё реализовано через вызовы функций), поддерживается «ленивость», «асинхронность» (на основе собственного «велосипеда» по мотивам шаблона AsyncEnumerator), «прозрачное» применение скалярных функций к IList-векторам (например, "{1,2,3}.sin()"). Язык безтиповый, все значения передаются как Object.
Все именованные значения вычисляются однократно и «лениво», константные выражения вычисляются при «компиляции», имеется базовая поддержка замыканий.
Из недостатков: .Net 2.0 (в 4-м можно было бы использовать встроенные возможности для реализации асинхронности), сложный код писать трудновато без интеллектуального редактора, также приходится ограничивать параллелизм семафорами, иначе память кушается много))
Изначально задумывался «движок» для построения отчётов/организации вычислений на основе шаблонов/алгоритмов, описанных в Excel-документе, без использования ПО Excel по следующему принципу: на основе Excel-шаблона внутрипрограммно формируется скрипт для построения отчёта, после чего «компилируется»/запускается, запрашивает требуемые параметры и делает отчёт/вычисления в фоновом режиме.
Пример «внешнего» скрипта:
одна, 28.02 отправленная из Китая, прошла таможню в Самаре;
другая, отправленная в середине марта из Нидерландов прошла импорт в Мск.
А так, конечно, хочется уже и без «костылей» асинхронный код в линейном виде писать.
* черенок хоккейной клюшки;
* кусок нихромовой «утюжной» проволоки, закреплённый вдоль черенка на регулируемой высоте;
* понижающий трансформатор с несколькими выводами вторичной обмотки (из отцовских запасов).
Баловался скорее, чем серьёзные вещи делал.
Например, по сечениям из журнала «Моделист-Конструктор» была собрана летающая(планирующая) моделька Ил-2 полностью из пенопласта длиной порядка 30см (до сих пор где-то картонные «выкройки» лежат).
Технология была следующая: на параллельные торцы куска пенопласта требуемой длины крепились две «выкройки»-сечения (например, секции крыла или фюзеляжа), по выкройкам, как по направляющим, проводилась раскалённая нихромовая нить (сложность только в том, чтобы вести её по обеим выкройкам синхронно, не допуская задержек, из-за которых могли образовываться «ямы» на местах локального перегрева пенопласта).
Доп. прочность деталям придавал тонкий поверхностный оплавившийся слой.
Торцы обрабатывались шкуркой и склеивались столярным клеем, в центроплан для усиления прочности были вставлены тонкие деревянные рейки.
При запусках модельки по квартире страдал нос (плющился)) и передняя кромка крыла. Самолётик был «убит» (обломались кончики крыльев, стабилизатора, киля) и «выпущен на свободу» в начале 2000-х до появления доступной цифровой фотографии и до осознания его дальнейшей ностальгической ценности)).