Скажу крамольное: весь ASP Model Binding — тупик (да и потоковый json сериалайзер тоже). Аргументирую: binding property list задается только статически (там есть вроде как теоретический путь создать его и динамически но мой вывод 1) только поверх системного кеширования, 2) массивным переписыванием кода, в общем, будем считать что нет методы, тем более что ее действительно нет как реализации кем-то раз написаной). Последствия: хочешь создавать контроллер из модели не через T4 а через run time генерирование (с исп. Execution trees) — вынужден отказываться от Model Binding'ов, брать HttpRequest и по нему сгенерированной функцией строить класс.
Это работает. Показываешь. Фидбек же будет такой — а как же мои атрибутики модел биндинга?
Есть и правильные вопросы, но из-за атрибутов Asp это такой box — что когда надо out of the box дверь находят немногие. В общем я против атрибутов, слишком часто их выставляют каким-то сверхзнанием, слишком многие люди воспринимают фокус за достижение. А «на самом деле» (простите) атрибут это наведение тумана.
Замену
if (!ModelState.IsValid)
return View(param);
этим
[ValidationFilter]
не считаю достижением, а считаю шагом в сторону. Шагом вперед считал бы поиск регулярного в коде и составление всего метдоа Action динамически (при первом вызове) чему атрибуты не просто мешают — делают не возможным.
Чтобы небыть голословным очевидными примерами приема верстки является понимание и умение пользоваться
1) «col» bootstrap'а ломающиеся от media-type.
2) умение стилизировать jquery plugin'ы
3) умение залезть в Chrome debugger и подгонять стили wyswig
и т.д
4) умение пользоваться тулзами которые загружают картинку и потом выдают названия шрифтов, цвета, гардиенты
5) умения задать вопрос дизайнеру (список вопросов которые можно задавать дизайнеру)
6) тоже программеру
список конечно не звучит — потому что необдумано и сформулировано плохо. и главное он не закончен, ведь система становится «приятной» когда она система, а не ее черновик.
я почему бурчу, сделайте эту работу — большое дело будет. интерес есть.
Вы описываете то что у вас в голове (даже с семантическими связями), и вдруг «в голове держать не надо».
Под раскрытием верстки понимаю именно что приемы верстки, т.е. перелопачивания работы дизайнеров в ХТМЛ. Чтобы их привести — надо их обдумать, сформулировать «чтобы не было просто карты тегов», предложить названия, сгруппировать, отсортировать по сложности — большая работа на самом деле (которая не проделана, хотя сразу этого можно и не понять смотря на масштабы карты).
Не задумывалось? Но вы названием статьи предложили меру которой хотите чтобы было оценено содержание.
Хороший результат — в смысле большая карта получилась. Но сильно искаженный масштаб. Именно верстку надо расскрывать подробней, а тут подробней расскрыто неспецифичное client-side программирование. И в смысле количества подробностей и даже геометрически в центр поставлена переферия.
А можно пример сложного запроса к OneTick? Хочется узнать что значит «совсем не так». Я могу представить и сложные запросы, например если данные «разбиты на фазы», и шаг статистик надо с началом фазы переначинать. Но на сколько я понял, нет потребности такие фичи в язык запросов вставлять, все это делается на мидллейере. А какие есть?
А можно спросить почему замена RTDB должна быть непростым делом? Неопытным взглядом подводные камни не видны: это же сервис, cюда шлешь данные, сюда запросы. Запрос, говорят, всегда прост: выдай данные от и до, возможно с какими-то базовыми статистиками (как понимаю с указанием шага). Время от времени прочищаешься. Переписать адаптеры и вся замена.
А есть ли название у обобщенной задачи: кэширования в TSDB (или в серверной надстройке) подобных аппроксимаций для нужд оптимизации? Т.е. если известно что инженер всегда открывает данные (на графике) с конкретным treshold'ом, и в 80% углубляется до такого-то treshold'а и только в оставшихся 20% идет глубже, возможно имеет смысл постоянно хранить в TSDB 2 постоянные дополнительные аппроксимации?
Спасибо за статью и рассказ о требованиях к TS. Вопрос, а такая возможность языка запросов как «верните мне значения от даты, до даты, апроксимированные до N точек (без сглаживания, т.е. оставляя локальные экстремумы)» у вас реализована или это не то что надо ждать от TS DB вообще?
Т.е. если задача «web dashboard графиков временного ряда c server-side zoom'ом » какой продукт (комбинацию продуктов) использовать?
Интересная святочная история, чувствуется желание обозначить конфликт и вывести мораль. Но пока смазывается чувством «так не бывает»: начинающие как раз делают сразу всё «на чисто», чтобы сконцетрироваться на программировании, а не на минировании своего же пути. Компоновка разных историй в одну не пошла на пользу.
Сразу скажу, что я не уверен в чистоте своих впечатлений, но вообще понимание git мне пришло с пониманием того что никакого чуда нет, в конце концев рекомендуемая модель (GIT_Succinctly стр 58) — Integrator Workflow, когда хоть изменения пулятся в общий паблик репоситорий, мержатся они должны в другом «архитекторском» и только «архитектор» будет мержить изменения в «публичный» паблик.
Правда как они перенаправляются из публичного в архитекторский — до сих пор не понятные мне детали (объясните?)… Но главное, что «по краям» возможности системы очерчены.
«конкретно про биткоин» это когда конретно на бирже позицию закрывают.
«а вообще поговорить» — вопрос про конкретный биткоин не интересен — мало ли что данной реализации угрожает, хоть и квантовые вычисления. интересно наблюдать и гадать: достаточно ли сильно уже объеденил интернет человечество чтобы оно вот так просто взяло и самостоятельно организовало и отстояло независимое от государства денежное обращение.
Делается много не самых надежных предположений: что население будет рости, что товарное производство не будет дешеветь, что на рынке есть место только «для одной криптовалюты» и т.д.
Фактически «поверьте моему честному слову». Если бы институт честного слова был так надежен, биткойн/блокчейн были бы не нужны вовсе.
Вопрос в сторону, поделитесь опытом, а почему вы предпочли оставить autofac когда в Core DI из коробки (который я не использую, правда я ни один стандартный IoC container не использую поскольку мне нужна поддержка экземпляров «per session» и решается это как раз отказом от IoC container'ов и ручным DI)?
Не только «десктопные приложения» неподдерживаются…
System.Diagnostics.PerformanceCounter и System.DirectoryServices только только стали доступны как preview1 (в вашей таблице Coming это и означает). т.е. портировать серверный код (где без данных библиотек не обходится) — удел одиночек. Писать новые проекты — конечно надо под core, осваивая новую МС телеметрию и вынося адапетр к ActiveDirectory в отдельный удаленный сервис, который будет крутится под Classic .NET Framework.
Непонятно. System.Data.SqlClient доступен был с незапамятных времен, отдельным пакетом. Если Microsoft.Windows.Compatibility можно ставить по частям, то так и надо написать.
Спасибо за статью. А можно попросить конкретней рассказать о:
React приложение должно было рендериться поверх чего-то другого, например какого-то сайтика
. Что за приложение/компонент задумывалось и получилось?
встал вопрос того, что возможны конфликты CSS классов моего приложения с уже существующей инфраструктурой
Что-то я не понял, а зачем attributeName тогда кастомизировать? «class он и в Африке класс» хочется сказать, но боюсь я сам в тундре, потому и спрашиваю.
Это работает. Показываешь. Фидбек же будет такой — а как же мои атрибутики модел биндинга?
Есть и правильные вопросы, но из-за атрибутов Asp это такой box — что когда надо out of the box дверь находят немногие. В общем я против атрибутов, слишком часто их выставляют каким-то сверхзнанием, слишком многие люди воспринимают фокус за достижение. А «на самом деле» (простите) атрибут это наведение тумана.
Замену
if (!ModelState.IsValid)return View(param);
этим
[ValidationFilter]не считаю достижением, а считаю шагом в сторону. Шагом вперед считал бы поиск регулярного в коде и составление всего метдоа Action динамически (при первом вызове) чему атрибуты не просто мешают — делают не возможным.
1) «col» bootstrap'а ломающиеся от media-type.
2) умение стилизировать jquery plugin'ы
3) умение залезть в Chrome debugger и подгонять стили wyswig
и т.д
4) умение пользоваться тулзами которые загружают картинку и потом выдают названия шрифтов, цвета, гардиенты
5) умения задать вопрос дизайнеру (список вопросов которые можно задавать дизайнеру)
6) тоже программеру
список конечно не звучит — потому что необдумано и сформулировано плохо. и главное он не закончен, ведь система становится «приятной» когда она система, а не ее черновик.
я почему бурчу, сделайте эту работу — большое дело будет. интерес есть.
Под раскрытием верстки понимаю именно что приемы верстки, т.е. перелопачивания работы дизайнеров в ХТМЛ. Чтобы их привести — надо их обдумать, сформулировать «чтобы не было просто карты тегов», предложить названия, сгруппировать, отсортировать по сложности — большая работа на самом деле (которая не проделана, хотя сразу этого можно и не понять смотря на масштабы карты).
Не задумывалось? Но вы названием статьи предложили меру которой хотите чтобы было оценено содержание.
Т.е. если задача «web dashboard графиков временного ряда c server-side zoom'ом » какой продукт (комбинацию продуктов) использовать?
Правда как они перенаправляются из публичного в архитекторский — до сих пор не понятные мне детали (объясните?)… Но главное, что «по краям» возможности системы очерчены.
«а вообще поговорить» — вопрос про конкретный биткоин не интересен — мало ли что данной реализации угрожает, хоть и квантовые вычисления. интересно наблюдать и гадать: достаточно ли сильно уже объеденил интернет человечество чтобы оно вот так просто взяло и самостоятельно организовало и отстояло независимое от государства денежное обращение.
Вопрос сугубо политический.
Фактически «поверьте моему честному слову». Если бы институт честного слова был так надежен, биткойн/блокчейн были бы не нужны вовсе.
System.Diagnostics.PerformanceCounter и System.DirectoryServices только только стали доступны как preview1 (в вашей таблице Coming это и означает). т.е. портировать серверный код (где без данных библиотек не обходится) — удел одиночек. Писать новые проекты — конечно надо под core, осваивая новую МС телеметрию и вынося адапетр к ActiveDirectory в отдельный удаленный сервис, который будет крутится под Classic .NET Framework.
Что-то я не понял, а зачем attributeName тогда кастомизировать? «class он и в Африке класс» хочется сказать, но боюсь я сам в тундре, потому и спрашиваю.